Arguably, the new unified UI on Red Hat 8 was the talk of the town for the whole summer since the Limbo betas. Today we talk with two of the leading people behind Red Hat’s enhanced usability and UI found on 8.0-Psyche, Havoc Pennington (also known for his work on the Metacity window manager) and Owen Taylor (lots of cool stuff on XFree’s side). We discuss about XFree and its capabilities, about Linux’s ability to fullfil a modern desktop for every user, about the unification of Qt and GTK+ and more.
1. Red Hat 8 has just been released. How do you feel about the progress Red Hat has made since its last version in the desktop and UI field?
Owen “OWT” Taylor: It’s definitely a big step forward. I think we’ve really gone from a collection of applications to something that looks and feels integrated with this release. And visually, I’m really incredibly impressed by what Garrett Lesage, our new graphic designer, managed to do with this release. I flinch now every time I see a screenshot of an older release.
Havoc “HP” Pennington: I think it’s great. There are so many cool enhancements. Of course lots of work remains, but I’m amazed by how much we got done for 8.0.
2. What kind of changes you did or wanted to do for the RH desktop, but they did not make it to the final release (if any)?
OWT: You never get everything in that you want to, which is good, since then you’d have nothing to do for the next release. Garrett had a lot of visual tweaks that he wanted to do still… he has the real attention to detail of a graphics artist. We thought it looked great, he was upset that an icon was blurry – that text here or there was off by a few pixels.
One thing I’d like to see for future releases is a way for system administrators to be able to easily change the default applications.
HP: Tons and tons of things. Printing and multimedia are at the top of my list for things I want to work on.
3. What is your opinion about offering a single X11 desktop environment with a desktop OS, instead of a plethora of them?
HP: As long as there’s demand for more than one, in my opinion there’s a benefit and not a lot of cost to having choices available. However I do think it’s necessary to hide choices by default in many cases, to avoid confusing new users. “GNOME or KDE?” should not be the first thing a new user sees.
Also, the choice has to be a choice of desktop shell or environment, not a choice of two different sets of applications — thus the Bluecurve integration effort, which is in part about breaking the link between the desktop shell and the applications.
We can’t have a situation where an application only works properly if it’s running in a specific environment. (And for the most part we’ve avoided this problem.) Even if GTK+ or Qt went away tomorrow, we have to deal with VCL (OpenOffice), XUL (Mozilla), WINE, old Motif applications, and so on. The same is true on Windows, where I’m told there are multiple generations of the standard GUI toolkit, plus third-party toolkits such as OWL, Qt, and Swing.
So any time an application is going to have runtime dependencies, those dependencies should be properly expressed in the form of a specification that lays out the protocols, file formats, conventions, and so on that are involved — enabling multiple implementations to interoperate. This is just good engineering, and is pragmatically necessary for us to make sense of the Linux desktop platform.
4. How well integrated Qt and GTK+ are now, after your changes? For example, do shortcuts, copy/paste or drag-n-drop work adequately now between applications created by the two popular toolkits?
OWT: In general, I’d say that interoperability between a Qt application and a GTK+ applications is just about as good as betweeen two Qt applications or between two GTK+ applications. A lot of the remaining work is really stuff like agreeing on file formats and what is on the clipboard when pasting between applications. There is also work to be done in standardizing how toolkits interact with the desktop environment for things like changing the theme.
HP: Copy/paste and drag-and-drop have been fully interoperable on the toolkit level for years now – the protocols are standard. If you see problems there, they are bugs in the specific applications you’re using. A bug should be filed against each application combination that doesn’t work. If people don’t file bugs against the specific application combinations, they won’t get fixed.
Keyboard shortcuts have to be synchronized shortcut-by-shortcut. We’ve started on this, and have a substantial head start because both GTK+ and Qt are using a lot of shortcuts inherited from Windows/Java/Motif. I certainly hope to see more progress there over time, ideally on the upstream level (the GNOME and KDE UI teams seem to be talking about some shared style guide stuff, which is nice).
5. Purely from the UI point of view, what do you think about OSX’s Aqua and XP’s Luna interfaces? Which are their bad and good points?
OWT: I don’t have a lot of experience with OS X personally. For XP, my feeling that it is nicely polished, but just a bit clunky. In many cases the useability improvements in XP are done as another layer on top of the existing familiar windows interface, so navigation from one place to another can take a lot of steps. Also, it doesn’t feel as consistent to me as I’ve come to expect with the work that the usability team has done on GNOME 2. But it has a lot of nice slick little touches, and there is no doubt that they’ve done a good job burying a lot of complexity.
HP: That’s an awfully broad question. 😉 Both of those interfaces are respectable efforts, I think, with lots of attention to detail.
You could make the Jef Raskin criticism, that the whole windows-icons-mouse UI concept is too complex. But if you accept the big picture, OS X and XP are both good implementations of that picture in my opinion. Better than most other attempts, at least.
6. What is the future of UIs? Do you see purely 3D interfaces to come on our way in the future, or something else?
OWT: I think it is worth distinguishing using 3D hardware to draw the desktop from an actual 3D desktop. A lot of transistors are being thrown into the 3D hardware, so it may well make sense to use it to draw the desktop as well.
But I don’t think that means that we’ll have a fundamental shift in the the way that users interact with the desktop – the screen is 2D, the retina is 2D, and the mouse is 2D, so I think the current 2 and half dimensional user interfaces will continue to be the way things are laid out for the forseeable future.
If I had to guess for one trend in desktop user interfaces in the future, it would be that they’ll less hierarchal and less structured, and their will be more emphasis on search-like techniques for bringing the data to the user rather than the the user navigating to the data.
HP: Most noise about 3D UI seems to come from hardware companies. 😉
But in general: say you woke up one day and everyone on earth simultaneously agreed to switch from windows/icons/mouse to some new paradigm. It would still take 20 years, trillions of dollars, and be mind-blowingly difficult.
I don’t have a clue what new UI would be exciting enough to get that to happen. If I did, I might invest in it, and not tell anyone else.
For the present, many applications still fail to live up to the potential of current UI technology. For example, I recently used Quicken for the first time, and was impressed by how difficult it was to use.
7. What is more to be done to bring the Linux desktop closer to the Average Joe User?
OWT: For the average home user, the big stumbling blocks are better hardware support and applications. For the business desktop, the average user is doing something much more constrained — using applications someone else has chosen and configured. I think we are quite usable in that arena already and most of the remaining work is small incremental improvements.
HP: There’s an endless list. In my opinion Joe-average-home-user is not in Linux’s immediate future; we’d need to support a huge quantity of consumer software and hardware. For now, we should concentrate our efforts on desktop users that have a system administrator to help them out and configure their machine.
8. Do you feel that the modularity of the GNU/Linux system is a good thing, or a curse for the desktop purpose? For example, by developing Freetype seperately of XFree86, none of the two work well with each other, neither is easy to install new fonts and be recognized by all toolkits (which are also developed seperately).
OWT: The modularity of free software operating systems is a great thing in general. Huge software projects are an engineering nightmare, and the modularity means that people can really focus on making particular components work well.
FreeType is actually an excellent example of the system working. It has a really well defined purpose – to render fonts. It is pretty much universally used by anybody who wants to render fonts in the open source world (and beyond). It has several devoted maintainers and is actively improved.
We now have another module, fontconfig, that layers on top of FreeType to handle font installation and lookup. I think you’ll shortly see it being used almost as univerally as FreeType for people who need these functions.
HP: Modularity is simply required in order to scale a software development effort, both in terms of people (having more people work on the software), and in terms of keeping the platform stable over time.
Sometimes it seems faster to avoid modularity. Fred Brooks explains the issue very well; modular software is part of a “programming system” and takes longer to write than a plain old program. Three times longer. Robust, tested, documented, maintained software is part of a “programming product” and also takes three times longer than just typing in a “works for me” program.
Something you can support for serious customers over a period of years combines both these qualities into a “programming systems product” and takes _nine_ times as long to create. The gap between “works for me” and “supportable product” is order-of-magnitude.
Ignoring modularity is a false economy, it just keeps you from scaling your system to larger size or higher quality. You can write the small, local bit of code more quickly without modularity, but you slow down the big picture by preventing developers from working in parallel.
In the freetype case specifically, I think the solution we’ve landed on (fontconfig and Xft2) is a very good one. It properly modularizes the font system and the window system, so you can use the same font system for both printing and on the screen. And it’s easy as can be to install fonts; drop them in the fonts directory, and that’s it.
Red Hat Linux 8.0 is incidentally the first distribution to ship with fontconfig/Xft2 as the default font subsystem.
9. How do you feel about XFree’s inability to fully function as a modern graphics subsystem? (e.g. you can’t change real resolutions on the fly, no support for OSX’s and BeOS6’s smooth window moving etc) Do you think that XFree is ok as it is today, or you would prefer to see the whole legacy code go away with modern functionality (in the possible expense that it might break old code)?
OWT: Support for changing resolutions on the fly was just added to XFree86 CVS a couple of days ago :-). The basic design of X is a very strong one, and most of the current limitations can be addressed in an incremental benefits. Could you do better by starting from scratch? Given sufficient resources, time and experienced people, yes. Could you do enough better to be worth breaking all the existing code and throwing away all the accumulated programmer experience? No.
HP: Changing real resolutions on the fly is already working in XFree86 CVS, and was not rocket science to add. Smooth window moving should not be that hard either. It’s just a matter of a smart person getting around to doing it.
If we went back and started over, then we’d need 1000 smart people to get around to doing a whole lot of things we already have with X. While right now we just need one or two smart people to fix a few relatively small problems. Do you want the 2-smart-person deficit or the 1000-smart-person deficit? Seems like a no-brainer decision to me.
10. A lot has been said recently regarding the KDE/Red Hat issue that was raised. Do you feel that there is such an issue, or that is simply a misunderstanding?
OWT: A lot of it was misunderstanding, but there are certainly real issues as well. Red Hat is interested in a desktop that is well integrated into the OS. The KDE project is interested in a desktop that is well integrated with itself. These goals don’t always completely coincide.
HP: Like most situations, it’s complicated. I think there were some real issues and some misunderstandings. Owen’s writeup here is a good summary of how I feel about the matter.
11. If it was one thing that you would like to change/add/remove from the Gnome 2 DE, what that would be?
OWT: Better printing support
HP: Nice multimedia applications and infrastructure. With the infrastructure part at least shared between GNOME and KDE.
HP: Most sound nice. They are on a level of detail that really needs to happen on the upstream level (as part of the GNOME project); we would not add that many patches in Red Hat specific changes, except for the items that can be implemented by changing the theme.
Frankly I think we’ll be all set as a desktop OS once those small pixel tweaks are our biggest problem. 😉
13. Why the nvidia 3D drivers are not included by default in the new Red Hat 8, which is a distribution release that is pitched against the desktop as well?
OWT: Well, aside from free software issues, Red Hat, in general, has a lot of trouble supporting binary-only kernel modules. Having code in the kernel that we haven’t seen and have no control over invalidates all the testing we do.
HP: We don’t include proprietary software with Red Hat Linux 8.0 in general, but in this specific case even more so because the drivers have (at least historically) had flaws that result in lots of bug reports and support headaches. If we ship the drivers, no matter what disclaimer you put on them, people will blame us for those bugs; and without the source code, we can’t fix the bugs.
We also like to support and encourage the open source drivers for nvidia cards.
Remember that the primary target desktop users for Red Hat Linux 8.0 are users with a system administrator that will set things up, and can install the nvidia drivers on users’ behalf, or purchase hardware that’s better supported.