A Look at the Upcoming GNOME 2.6
unmadindu writes "GNOME 2.6 is just around the corner, and I figured out that many GNOME users would like to know what's in store. So I installed GNOME 2.5 (development version for 2.6) in my box, and came up with a list of the new stuff that are coming up. (and just in case, copies of the article are also available here and here)."
as the Gnome desktop itself is the fact he's using the freedesktop xserver to run it. I had no idea it was so far advanced.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
When will we start to see serious performance improvements? Currently, GNOME doesn't feel much better than Windows XP, and it needs at least 128M to run acceptably with other apps.
Linux is supposed to get us off the upgrade treadmill, but as far as I can see, GNOME just keeps getting bigger, slower and more complex. I've switched to XFce; it's so much faster. KDE is a hog too, but at least they're concerned about performance and efficiency as the 3.2 release shows.
Really, this is something we should think about. When gconfd is eating up 20 megs (resident), just for a configuration back-end, it's evident that we're getting sloppy. A faster Linux could work wonders in terms of corporate and home adoption, but we just seem to be chasing Moore's Law and copying Microsoft for bloat.
I'll try GNOME 2.6 when it arrives, but to give a better impression to newcomers we need to make things noticably faster, more elegant and more efficient than Windows. Companies have to support all this code into the future, after all...
Hmm. I really hope they do have thumbnail and bookmark support, and continue to add features. Xpdf is a nice renderer, but the interface IMHO is not exactly a nice one. If gpdf can become the full equal of Acrobat Reader I'll be one very happy camper.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
The best file selector in my opinion ever, was the ASL file requestor on the Amiga. It just worked (tm). Whilst the old GTK file selector was the worst I have ever had the misfortune to use, none of the others come close - Windows is annoyingly cludgy still (at least it is resizable now). KDE's isn't that bad though, certainly a lot better than a lot of the others.
Then again, I think that the Amiga did a lot of things right for the desktop part of the OS, and in many underlying areas. Not bad for such an old, quickly written system.
They go to all the trouble of creating a decent filer, Nautilus, and then ignore it for opening and saving documents by sticking with stupid file selectors. Again. Do any GUI developers bother challenging tired, illogical concepts? (Check out ROX for true drag and drop opening and saving: here)
I firmly believe the Amiga User Interface Style Guide should be required reading before anyone is allowed to even install a compiler with the ability to create GUIs.
Money for nothing, pix for free
GNOME vs. KDE will perhaps be one of the holy wars of this millennium, and this is certainly another kick in the teeth for the ever-so-slightly clunky KDE (in my opinion). As said in the article, the developers have done some superb work and, well, put it this way, it is almost making me want to lose Mac OS X on one of my iBooks. Do not underestimate the pulling power of eye candy and the HIG!
:)
Liberal inspiration has, of course, been taken from the Apple way of doing things - the spatial navigation is, as noted in the Ars Technica article, based on the pre-OS X MacOS Finder. And that's no bad thing, certainly if FOSS wants to move towards real usability on the desktop.
The file dialogue boxes are also notably similar to Mac OS X's way of doing things, although the puzzling (at least to me) scrollbars that the Mac uses to browse up and down a directory tree are here replaced with arguably simpler tabs. Very nice touch.
Personally I'll keep Mac OS X on this for the moment, if only to avoid kernel recompiles and incompatibilities arising from that, but hell, if I were a Windows user, I'd be sitting here asking myself why the fuck I am waiting till 2006 for Longhorn when I can have this now...
Zealots were quick to criticise the most prominent competition - Mac OS X 10.3 - in terms of eye candy on the desktop when it came to making comparisons with their darling Longorn (which is, rather pointedly, not available for purchase yet). Now that UNIX is offering two superb alternatives, one of them properly FOSS (and, more importantly, runnable on x86), Windows' days should surely be numbered...?
iqu
Some people have the misconception that "spatial navigation" is about having one window per folder, but that's not really the point. In explorer-like navigation, every window is a partial view of the filesystem. Every window can be used to navigate the fs with browser-like controls (forward, backwards, folder up, folder down). Two windows are just two views of the fs, they can point to the same folder.
The defining characteristic of spatial navigation is that a folder window IS the folder. That's why there cannot be two windows on screen that show the same folder, and why there are no navigation controls. The fact that folders open in the same place as when you left them is just a result of the fact that the position is an attribute of the folder itself, not of a windows which is a viewport of a folder. It's a subtle difference that people who have worked with explorer-like browsers for too long may have some difficulty adapting to.
Personally, I feel more comfortable with an explorer-like fs browser, maybe just because I'm used to it. It seems easier to manage large trees this way. But I can easily see why new computer users would be less confused with the spatial model. It's hard for some people to understand (and remember!) that a dozen of shortcuts to "My Documents" in different places all point to the same folder "underneath".
``Not true. GNOME (and KDE!) have only gotten faster and faster. The exceptions are KDE 2.0 (which is slower than 1.0; but 3.0 is faster than 2.0 and 3.2 is even faster than 3.0) and GTK (which has become a little slower but also smoother because of extensive double buffering).''
I can't comment on KDE, but when I upgraded from Gnome 2.2 to 2.4, I noticed significant performance hits. The desktop took longer to load, and in general, were noticably slower.
``On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4. And GTK 2 feels smoother than GTK 1.''
Well, you have a nice system. My primary FreeBSD box has a 500 MHz CPU with 128M RAM. Yes, it sucks, but I was fairly disappointed when I upgraded to Gnome 2.4
(S(SKK)(SKK))(S(SKK)(SKK))
That still has failings: it doesn't guide you to which applications are valid for opening a certain type of file. If your system has many applications (typical result of a "Full" Linux install from commercial cdroms), then it'd be impossible to have an icon for every app without wasting pixels or inducing squinting. (Both of those are points of opinion that would bother some users and not others)
The system in KDE's Konqueror filemanager is better because it recognizes multiple possible associations for each filetype, allowing a user to right-click to select opening something in the non-default handler. (KDE's approach still needs some improvement; the right-click menus need some streamlining, for example)
Focusing on the "dialog vs filemanager" question ignores a more important UI design choice, though: Should each application include its own GUI code to pick files, or reference a centralized GUI system to perform that operation?
Many of the problems you've cited with SaveAs are the result of poor and inconsistent implementations of dialogs, not file-dialogs per se.
Ideally, the application program would be written at a higher conceptual level, where details like dialog boxes and icons are implementation trivia handled by a GUI control process. That way each user could load/save files in exactly the way she prefers, regardless of the biases of any specific application's author.