Slashdot Mirror
Havoc Pennington Answers
Signal 11 asks: There has been a lot of discussion about merging KDE and Gnome together either via a universal toolkit, or by actually merging the two code-bases together.
What are the technical (and legal?) obstacles that need to be overcome for this to succeed? How does the KDE and Gnome developers feel about such a merger? Is there currently any work being done to further this goal at present (by either camp)?
Havoc answers:
Merging the entire code base is completely impossible, both technically and legally - not to mention that it would involve scrapping and rewriting close to a million lines of code, actually more I think, once you count applications. So we can consider that an official Bad Idea.
However there is a lot of room to share code. Some things aren't really desktop-specific; for example, a sound server or my GConf configuration storage library or libxml or libart. These are components the desktops could easily share.
We're making lots of progress on interoperability. For example, the window manager hints spec, so your KDE desktop icons won't show up underneath your GNOME panel, your GNOME panel will work with the K Window Manager, etc.
Some work has been done on "themeballs" which are collections of "matching" themes; we'd have an app that knows how to install the theme collection as a group, so your GNOME app, KDE apps, and window manager would all reflect the same theme. Someone from GNOME has been trying to write a GTK pixmap theme that loads the Qt pixmap theme format, as well. (For proof-of-concept, check out the Sawmill window manager, which automatically "matches" the current GTK theme.)
CORBA is sort of inherently interoperable, modulo some small details. Things are looking pretty good on this front.
BadmanX asks: When do you see Gnome getting some sort of threading capability, like that which makes the Be operating system so integrated?
Havoc answers:
I think GNOME is a bit too high-level for this; I would expect it to be more of an X server or kernel issue. GNOME should be able to take advantage of multimedia speed enhancements almost automatically. Of course the Linux kernel and GNU C library already have a fairly solid threading capability, but it isn't used as pervasively as it could be perhaps.
As an aside, the glib library used in GTK+ provides a nice main loop abstraction that allows us to avoid the need for threads in many cases, which can make writing applications much simpler. There are some cases where threads are necessary (a server that does blocking IO for example), but we try to minimize their use because they are a maintenance and portability problem.
Skeezix asks:
Could you give us a rough timeline of what we can expect to see coming from the GNOME project in the next months, and years? Could you give us an idea of when we can expect to see the 1.0.50 and 2.0.0 releases of GNOME? And what will those releases look like?
Havoc answers:
1.0.50
1.0.50 may have come out by the time you read this. It has lots of small new features; the file manager has been significantly enhanced, the libraries have some new stuff for developers, there are "segfault dialogs" that come up and tell you when apps have crashed, control center fixups, logout animation, gdm2 (the first PAM-compliant X login daemon, someone told me today), gnome-session has no known crashes, removable media is auto-detected, etc. Just incremental enhancements.
Actually this release may not be called 1.0.50, I think we are calling it "September GNOME" or something. In any case; we've been releasing some component or other every week since GNOME 1.0, but this is a synchronized release of all the components and represents the end of our active work on the 1.0 series. (Though there will doubtless be a few small releases for whatever reason.)
I noticed a little flame war in the comments for the first article about "what has GNOME been doing"; basically we have been working on applications and next-generation development infrastructure. GNOME Workshop totals 400,000 lines of code, counting a semicolon as a line; this is close to a million lines if you use the plain "wc -l" method of counting. That's a whole lot of code hidden behind the sucky GNOME Workshop web page. Other GNOME projects over the last few months include the Bonobo component architecture, libglade, and bug fixes. :-)
2.0
It's probably a bad idea to announce a date for 2.0 at this time. Most likely in the first half of next year. Well, we are going to try our damnedest to get it done within 6 months I think.
One thing I'd like to see in 2.0 are multiple releases, not necessarily at the same time. The components as I see them are:
- GNOME Developer Toolkit: Libraries and development tools like Glade
- GNOME Desktop Environment: File manager, window manager, panel, trash can, etc.
- GNOME Application Suite: The 20 or so small utility apps that are distributed with GNOME itself.
- GNOME Workshop: The office suite
Here are some of my thoughts on 2.0, obviously it will evolve a little bit along the way and other GNOME project members will disagree:
- Bonobo component architecture library (already mostly done, has to be released and stabilized)
- New file manager (asynchronous virtual file system layer is done, code such as metadata database will be reused from gmc, but lots of stuff to rewrite).
- Hopefully a default window manager that we know works well with GNOME and we have enough influence over to "sync" with our release and be sure it has an interface we can live with. Of course you will still be able to choose your favorite WM if you want, we're working with KDE on a nice WM spec.
- Mozilla-based help system. The Mozilla build tree already has a GtkMozilla widget in it, and we're standing ready to slap a Bonobo wrapper around Mozilla as soon as the thing shows signs of stabilizing. Dave Mason at RHAD Labs is an expert on online help and SGML/XML (he wrote the 100 page illustrated GNOME User's Guide as well), and Mozilla hacker Chris Blizzard also works at Red Hat though not in the labs. We think that together they can create a sweet system.
- Replacing Imlib. This should result in some small performance gains, and a simpler codebase for us to maintain. The gdk-pixbuf replacement library has already been written.
- libglade integration. libglade is already in use, but we have to integrate it with gnome-libs. This is a library which parses an XML resource file and creates an interface. This makes for some serious rapid application development.
- GConf configuration system. This makes it much easier to deploy the desktop in computer labs or larger offices.
- Enhanced language bindings. We want to flesh out any remaining gaps in the language bindings and be sure these work well.
- Internationalization. Owen Taylor at RHAD Labs is working full-time on internationalization issues in GTK+; we will support Unicode, and all kinds of writing systems (including bidirectional text). Very few (if any) toolkits support internationalization to this extent.
- Printing. We already have a gnome-print library, which needs some polishing up for a stable release. It will be included in GNOME 2.0. Gnumeric and Dia already print using gnome-print, however.
As you can see we have quite a bit of code waiting in the wings ready to go in GNOME 2.0; that's why we hope to finish on a tight schedule. But of course things could go wrong, you never know.
Hackers who want to get involved are encouraged to start lurking on the mailing lists and the #gnome IRC channel, and start reading documentation on our developer's site. There's a lot of stuff to do and the future looks exciting.
Tet asks:
There have been many half hearted explanations for GNOME's poor performance, ranging from Gtk to CORBA to X itself. However, none of those really cut it. Given the responsiveness of standalone Gtk apps, I think Gtk can be ruled out. Orbit is supposedly 3 the fastest CORBA implementation by a factor of 3, even with all the assertions left in. While the X protocol may be somewhat slower than it could be, X is still quite responsive on my old 486.
I now have an AMD K62-450, and GNOME still feels sluggish, about the same speed as Windows 95 on my P75. That has to be wrong. Yes, GNOME probably does more than W95, including things like network transparency, and the like, but even taking that into account, along with Gtk, CORBA and X itself, you shouldn't be looking at more than, say, reducing performance by half, and that's being pessimistic. In reality, you're looking at GNOME being 3 or 4 *times* slower than it ought to be. Simple question: why?
Havoc answers:
This question is really too vague; let me know if my answer is still half-hearted. What is your setup? What theme? What window manager? Is your X server good or is it one of the semi-finished ones? What things are slow for you? Are you actually timing things?
I have a Pentium 166 laptop and GNOME is very fast and responsive. But I do two things:
I use only theme engines, especially the GTK default theme, no pixmap themes. If you use the glitzy themes you pay in speed and memory.
I use WindowMaker or Sawmill, not E.
There are some specific things we know are slow:
- Application startup is slow. This is primarily due to the fact that a GNOME application links to so many separate shared libraries; if we merged all the libraries into one or two giant libraries, you would have many fewer system calls on startup and faster start time. However, there would be some disadvantages from a maintenance/download-size standpoint. We've addressed this problem by changing Imlib to dynamically load libpng, libtiff, etc. on-demand instead of on startup; we'll probably be removing Imlib in the next release. We could probably change things so the sound libraries are also loaded on demand.
- GTK flickers a lot if you have opaque resize turned on. This is a complicated problem that's hard to address; the long term solution is probably to move GTK+ to an architecture like the GNOME Canvas widget instead of the more traditonal toolkit architecture based on X windows. The flicker isn't really slow, but it makes people feel that things are sluggish.
- Some versions of E do some things slowly. For example moving windows around can be slow. WindowMaker is much more consistenly snappy, and Sawmill is nice too. Those are just my preferences, lots of people swear by icewm, fvwm, scwm, etc.
- Some specific applications may be slow for whatever reason - if some particular operation seems too slow, please file a bug on http://bugs.gnome.org.
Anonymous Coward asks:
You are known to be a programmer, and a programmer always has some ideas on languages and tools. What of the currently available languages would be your programming language of choice now? What about two years from now? Why? How would you change it so it becomes the ideal language? What's the worst language you've written something substantial in? How would you change it so it becomes the absolutely most evil language?
Havoc answers:
OK, you are setting me up to be flamed. :-)
I don't think the language is really the primary issue right now. People are interested in the quality of the available implementations, the availability of support and training, the kind and number of useful add-on modules, the documentation, and so on. Basically for any project, you decide whether you need the speed of C/C++, and if you don't you do your best to use a higher-level more reasonable language with a good implementation. "Academic" languages like Haskell and Eiffel, while much nicer languages than Perl or Python or C++ or Java, have implementation issues that often restrict their use.
With the Cygnus/GNU Java compiler, lots of GNOME people are cheering for Java. We even have a good start on the Java bindings for GNOME. Java offers an object oriented environment syntactically similar to C/C++, but has some important safety advantages (no pointers), reduced complexity, and lots of nice libraries.
For rapid application development I like to suggest Python as a sort of "Visual Basic equivalent"; PyGNOME and libglade by GNOME's James Henstridge allow you to write a fairly complex, nice-looking application in a couple days. The Red Hat 6.1 installer is written in PyGNOME.
I've used Guile some as an extension language; the Guile-to-C API is very simple and easy to use. Again, an implementation issue that becomes important.
There's an O'Reilly book coming out about Perl/GTK, I'm told, so I assume those bindings are pretty good. Judging by the list traffic quite a few people are using them.
Anyway I've been playing with Haskell lately and I think there are some practical issues with it, but it's improving and I enjoy it a lot. So if I'm having a language war I like to defend it. But in practice I end up using C to write libraries, if I were writing a high-level tool I'd probably use Python. My largest two projects to date (Guppi and gnome-apt) are in C++. gcj makes me want to have another look at Java. Just use whatever works.
Ian Bicking asks:
There are a ton of preceding and current desktop environments: KDE, CDE, GNUStep, Windows, MacOS, Xerox Star, BeOS, QNX/Photon, and a whole bunch of others.
Are there any ideas from other such environments that you think are really neat? Any ideas that you would like to be part of Gnome, or even plan to try yourself?
Havoc answers:
We do our best to steal shamelessly from all other user interfaces; we have the Mac UI guide and a Windows box at RHAD Labs, as well as KDE installations, and we often look at how these other groups implemented a given dialog or widget. I'm sure the GNOME hackers on the net do the same thing; Miguel is always talking about the latest Excel feature he just cloned in Gnumeric.
In general we want to keep the UI "sufficiently similar to" the windows-mouse-icon model of Windows and Mac, because trying to be revolutionary on this point would be a disaster (read the gnome-gui-list archives if you have any doubts). But we like to add nifty enhancements, such as themes or the GNOME panel. And of course hackers who work on innovative stuff are welcome.
Most of my interface ideas are for particular applications. Having just written a book, I have an elaborate plan for the ultimate document-writing application. But Emacs will have to do until I get some more time. :-)
SEGV asks:
Havoc, how did you find the process of writing a book? Can you tell us more about the process? How long did it take? How did you find the time? What were some of the hurdles you had to overcome? Are you as pleased with the final product as you imagined when you began? Would you do it again?
Havoc answers:
Writing a book involves sitting down for long periods of time and typing. As an activity, that's pretty much what it involves. :-) Well, there's some thought that goes into it.
Seriously. I wrote a "fast book," it took about 4 months. Lots of books are written in well over a year, but I wanted to write a book that people could begin using as soon as possible. If it sells well there may be a second edition sometime after GNOME 2.0 (even without the second edition it will continue to be maintained as part of the GNOME project).
The process is simple. You make an outline and get opinions on it from all your editors and technical advisors, then you revise it a few times. After that you start to write the chapters in the outline; each chapter is reviewed for technical accuracy and writing quality, then sent back to you. You make the suggested changes, then submit the final chapter. After you've done that for all the chapters, you just wait for the book to appear in print. That's about it, modulo some boring details.
I found the time by spending a lot of weekends with my computer instead of doing something fun, and by staying up late some nights. I think in general there is a poor work/pay ratio, so it's important to want to get the information out there, you won't be getting rich on book-writing.
ajs asks:
I hear things about Glade getting sucked into core GNOME libraries as a way of dynamically reconfiguring applications (an ambitious goal!) How much planning has been done for this, and is it expected to impact application performance?
Havoc answers:
Well, we are already using libglade in some applications, such as Gnumeric, and it doesn't seem to be causing a problem. :-)
Glade won't be sucked in, but rather libglade. libglade has about two function calls in the whole library; all it does is load an XML file generated by the Glade GUI builder. It uses the file to create widgets for your user interface. You can avoid writing widget-creation code; you just have to write the callbacks that actually implement the functionality of your application.
There is some amount of performance overhead but it is fairly small and only at application startup time; once you've loaded the widgets, they are just as fast as they would be if hand-coded. There are also some performance advantages:
- You can often halve the number of lines of code in the application itself, thus reducing application size.
- You save tons and tons of programmer time, so hackers can focus on optimizing the truly time-sensitive portions of the application.
If speed becomes a genuine problem we can implement a way to "compile" the XML files into some kind of high-speed binary format I guess. That would be pretty trivial and would avoid the XML parser overhead. But as I said, we're already using libglade in several places and I haven't noticed a speed problem.
Next week: Eric S. Raymond
Let me first of all comment that Slashdot's plenary interviews, if I may coin a phrase, are very-well conceived and produce excellent results.
This, however, I think may have been the best of them. The moderation system forwarded a very even-handed and broad set of questions, and H.P.'s answers were clearly well though-out.
I'd also like to note that H.P. helps give the lie to attempts by some to paint the entire GNOME movement with a broad brush of script-kiddie dilletantism. Miguel has made some unfortunate comments about KDE in the past, and there are several trolls in various GNOME lists, but in my general ovservation, the GNOME developers are smart, focused on GNOME, cognizant of its shortcomings and willing to go to extraordinary lengths to eliminate them, including cooperation with KDE where appropriate.
I've had a chance to look at KDE 1.1.2, and it is an excellent desktop. GNOME is my desktop of choice, but I can see how the competition has improved both. There is no doubt that GNOME has more rough edges than KDE, but as a developer, I find GNOME more interesting and faster-moving than KDE. I am very excited about libglade, Bonobo and libxml. The embryonic Orbit bindings for Python open up endless possibilities in my favorite language. Openparts is the KDE phenomenon that most piques my interest. All I know is that the Linux desktops are implementing what IBM, Motorola, Taligent, Apple, Microsoft, etc. only talked about, fought over and roundly politicized, and I'm very excited to be a part of real progress.
So thanks to Slashdot, H.P., The KDE and GNOME developers. Thanks to the eternally vilified Red Hat and Troll Tech. And let's get on with the work.
--Uche
"What thou lovest well remains, the rest is dross" -- E.P.
"there are "segfault dialogs" that come up and
:)
tell you when apps have crashed"
I'd like these to be full screen and blue if possible. Just for fun.
Greetings,
Ivo
Here is some explanation from Miguel about why Imlib is being replaced: a. refcouting is implemented properly, there is no concept mixing between refcounting and caching which disabled us from activating things like the thumbnail support in the file manager as it would have leaked every single image loaded. b. It keeps the alpha channel in the image and it handles it correctly. This means that we can finally ship an image viewer that shows the alpha channel as well as not breaking the image (the previous ones replaced the alpha above 50% for a magenta color). c. It enables us to use all the power of libart and the image support in the Canvas correctly (because the ArtPixbuf data structure has been there since GNOME 1.0, it is not a recent addition). So, all in all, gdk-pixbuf will actually reuse existing code, while being correct.