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.
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.
> 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.