Slashdot Mirror
Hackers on Linux's Exciting Desktop Future
Gentu writes "OSNews features two interviews with prominent open source developers: Robert Love started working at Ximian this week and he will be leading the 'effort to improve the Linux desktop experience via kernel development'. In this Q&A, he explains what he will be working on hardware integration, freedesktop.org's D-BUS & HAL, low latency optimizations, power management, X & 3D and a 'Linux answer to WinFS'. The second interview is with Red Hat's Owen Taylor. Owen speaks of GTK+ development and where he sees the project going in the Gnome 3 timeframe: freedesktop.org's new X server, Cairo support, GTK#, OpenGL & other widgets and more."
Many people are probably going to say that GUIs are inherently object-oriented, as they attempt to reconcile programmatic constructs with tangible objects. But the fact that GTK+ isn't implemented in, say, C++ isn't necessarily as bad as it sounds -- I don't think extending classes is particularly useful for GUI programming -- by deriving, you're either essentially encapsulating the parent class's functionality along with other functionality, or doing weird stuff to the internals of the parent to extend it. What's really important is that GUIs are concurrent and event-based, and hence the primitives which are reused all over the place need to be as well. Contrast a push-button, which generates an event for the containing program to handle whenever the user decides to click on it, with a square-root function, which only when instructed by the containing program takes a value, performs a finite amount of computation, returns another value, and stops. This is why Qt has its signals and slots. This is why TCL/Tk has been used so much for GUI programming despite its terribly lacking language features. This is why Java uses threads in its GUI frameworks. This is why the failed BeOS focused on highly efficient multi-threading. Although I agree that object-oriented encapsulation is essential for organizing the code of widgets, asynchronous lightweight concurrency is at least as important to make GUIs work. Derived objects, on the other hand, don't seem too useful for GUIs so long as you have interfaces or a good implementation of generic functions and type inference. Unfortunately, popular object oriented languages like C++ and Java don't really add this over C -- C++ is still totally sequential at heart, and Java's threads aren't particularly lightweight, nor is its huge library.
Probably because of idiots like you. Everyone is sending links to their articles to similar publications, it is not an unethical thing to do, it is just business.
Ok, that's fine, but in this case the parent class doesn't have to contain any code, i.e. it can just be an interface. I think that meshes with what I said earlier.
Subclassing with multi-inheritance allows new classes with combined behavior of old ones, without necessarily writing any new code.
Is this necessarily a good thing, considering that interfacing two separately-designed objects, especially those which use the same resource, i.e. a particular window on the screen, almost always requires some consideratin? And in that case, how is multiple inheritance any better than creating an object containing the two other objects? In my experience, multiple inheritance is most used to patch over a lacking type system.
Subclassing reflects disciplined versioning, and is all too often disregarded, at the peril of the application's fate.
That is certainly a valid point, and versioning systems would do well to take into accoutn semantic information.
Just admit it, X is slow compared to Windows on similar systems *every time*. It makes me think "Who the hell is developing these video drivers for X? Must be a guy in his basement, not the company who made the hardware."
Also, I find Redhat 9 to be deadly slow on the desktop. SuSE 8 has proven to be much better (a KDE vs GNOME here?).. but I'm waiting for Fedora Core 2 (with the 2.6.0 kernel) until I make my next foray into trying Linux as a desktop OS.
Lots of people say this, but I still don't get it. At work I run Slackware 8.1 with WindowMaker, and I get better compile performance and a more responsive desktop than my Windows-user coworkers, most of whom have more CPU than I do. I think people who are disappointed by the responsiveness of Linux/X11 are actually disappointed by the bloat of KDE and Gnome. Give WindowMaker or XFCE a try; you might be pleasantly surprised.
> Derived objects, on the other hand, don't seem too useful for GUIs
> so long as you have interfaces or a good implementation of generic
> functions and type inference.
That's where you're wrong, with my apologies for putting it so bluntly.
Derivation is the #1 thing that makes the difference between a good widget set and a bad one, for several reasons.
The major reason is that in any complex application, you'll need custom widgets (entry fields with browsable history, viewing pane with custom repaint, etc). If you have to provide the functionnality by manually appending it to the native widget everywhere it's needed, your LOC (and the potentiality for bugs) explodes. The right way is to derive a self-contained widget from the general case, specialize it for the need once for all, and use it instead of its parent where needed, which only requires adding code in -one- place.
Typical example is KDE's file dialogs, that all derive from a common root, but can be expanded on an as-needed basis (and without even adding bloat since the common logic is in the parent class).
Typical counter-example is the MFC, which are absolutely awful to code against, because they're based on a non-object-oriented framework and have very little extensibility (WinForms is thankfully a major improvement in that regard).
Second important reason is granularity. Derivation allows an API to provide very high-level widgets (text editors, MDI areas...) -and- their lower-level parents, which in turn allows you to use the high-level widget where it's the fitting tool, and derive your own from the parent where it isn't, all the way down to the lower level widgets if they're what you need. Lack of the extensibility derivation offers in an API means your API will either have to remain very low-level, thus requiring you to reinvent higher-level wheels everytime you'll need them, -or- overbloating the API with countless specialized widgets to try to cover most of your needs (that's the MFC approach).
Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.
Third reason is, of course, as you rightfully point out, event handling, which derivation allows to specialize as needed (for instance, tablet XInput events on a drawing widget -- see how Qt does it for a good example) -without- building a dedicated widget from the ground up -or- special-casing against XInput. Once again, Gimp 1.3 and its XInput handling problems are a good example of why it matters.
There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.
Once again, I'm sorry, but while you're right about event handling, that is a -runtime- issue and pretty much orthogonal to widget development. You'll note, by the way, that Qt provides signals and slots -precisely- so that you don't have to think about that orthogonality in the common cases -- its widgets handle events on their own and emit the appropriate signals as required, which allows you to design your code according to WHAT is to be done in response to something, as opposed to HOW that something happened. Best example is the concept of QAction, which can be triggered from a butten, a menu, a context menu, or a key shortcut. You only have one signal to slot against, regardless of which way that action was triggered.
There, that's it for now. I hope I managed to make it a bit clearer why object orientation is primordial to a good GUI toolkit?
Rosegarden developper Guillaume Laurent has a few interesting thoughts about why he switched from a GTK-based backed to some random object-oriented toolkit, if you'd care for a slightly different point of view on the same topic.
-- B.
This sig does in fact not have the property it claims not to have.
CMD.EXE is just a command shell and won't hook into the registration info unless you tell it. Instead of "winword", at the cmd.exe prompt, type "start winword"
start.exe will hook into the subsystem...
As I understand it, what the original poster is proposing would be a layer of virtual directories on top of the hierarchial file system we have now. You'd still have things physically organized into /usr/bin, /etc, /whatever, but then also linking all the files related to a program to an /applications/$APP directory.
So really, you'd be getting the best of both worlds. You'd have everything related to Application X all stored in one place making dealing with it as an individual application far easier, but you'd still have the old filesystem where all your config files, binaries, etc are grouped together as well. Sounds like a rather good idea to me.
Isn't Gnome's own, independent, development near being trifled since Ximian took on? And, then, where does Ximian lead us for Free Desktops?
;)
See this:
The suggested retail price is $99 (U.S.)
In addition to the Bitstream fonts bundled with GNOME 2.2, Ximian Desktop 2 includes MS-Windows compatible fonts from AGFA*, so your applications, documents and web pages look their best. AGFA fonts available only with Ximian Professional Edition - Buy it now!
Access virtually all print, media, audio and video web content with the bundled Adobe Acrobat Reader, Real Audio Real Player, Macromedia Flash Player 6, and Java 2 Run-time Environment. Available only with Ximian Professional Edition - Buy it now!
In my view there are a lot of "By it now"s, being based on a "free desktop". When did a Windows user pay for Acrobat Reader, Real Audio Real Player, or Macromedia Flash Player 6; apart from the fancy versions?
Where is the incentive in opening the gates for Ximian hell here?! Who is duped? Perens?! Aren't Ximian just like any other money drainer?! To me, it sure looks like that. But, as always, I may be wrong again...
Adobe payed for using Qt and they can probably afford it. How many Mexicans can afford Miguel de Icaza's Ximian? 99$ for a desktop(!) with Acrobat Reader, Real Player, and Flash Player?!
How many Mexicans can afford Miguel de Icaza's Ximian, apart from Miguel himself?
Here are some brave words: "Ximian is offering a complete, low-cost productivity solution for Linux." Mike Rogers, VP and General Manager Desktop and Office Productivity Software Sun Microsystems
Hrmmmm... Somehow, my thoughts are in the direction that this LGPL talk is a setup for giving Ximian a get-go start harvesting all the multimillion dollar berries. But, I may be as wrong as many a time before.
Yes, sure: ftp://ftp.ximian.com/pub/xd2/redhat-9-i386. But, the one who has the copyright on the code does set the agenda to a large extent, and that may be what all this is about.
I have no idea who is pushing the LGPL agenda besides Perens, but Ximian seems to me being a likely candidate. Maybe, I should RTFA...
--
make install -not war