Slashdot Mirror
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
Looks good.
I'm so behind, I'm still using fvwm2.
But then again it's the only wm that works well on a cel500 128mg ram laptop.
I hope gnome 2.6 works as good as fvwm2 on my laptop.
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
I wrote about this yesterday in response to the article about Chris Stone and Novell. Apparently, I didn't hit submit after preview or something because I didn't see it there today. Anyway, what I thought would be interesting is if Novell could do a mini-skunkworks project in which members of the Ximian and Suse teams would be brought together to work on interop issues between Gnome and KDE. Maybe freedesktop is working on these issues.
I wish QT had been released under the LGPL and KDE had become the dominant desktop, but that's history now, and the only thing I can see to do is better interop between the two desktops. KDE seems to have better technology and Gnome seems to have a few killer apps -namely Evolution.
I used GNOME for a while on my laptop, but then a routine Fedora upgrade made it self-destruct. Suddenly no text anywhere. All the non-GNOME applications were fine. I tried the suggested fixes, but they didn't work.
So, I switched to KDE, purely so I could carry on working. And suddenly I noticed everything was a LOT faster. Even simple things like application window redraws were way faster.
So when I rebuilt the machine, I didn't even bother installing GNOME. I'll look at it again when it's about 4x as fast and much more reliable. Until then, I'm sticking with KDE 3.2, even though it's uglier.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The best file selector is no file selector at all. Since there is already a file browser such as Evolution (or its equivalent) that should be used, and made quick and easy enough for simple file selection tasks. To open a file, just view its directory and click on it; the application loads automatically and there is no real need for the two-step 'load application then use the Open menu', which dates from a time when computers didn't have a single GUI and there was no means to just open a file directly. To save a file, why not drag it from the application to the directory window. None of that clicking about with 'parent directory' and other nonsense.
Matthew Thomas pointed out better than I could that the separate file-picker is user interface cruft left over from an earlier age. Let's just have one file browser in the desktop and make it good enough to use for everything.
-- Ed Avis ed@membled.com
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".
So could I middle click paste a fully qualified file name in from my X selection buffer?
It's useful to be able to to do that - e.g. if I'm compiling something and the compiler issues an error message with a filepath in it I can select that, File/Open and middle paste the filename in on the editor I already have open and look at it. Having to navigate the full path by typing what's already on the screen would be a pain.
``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))
About the licensing; You're absolutely right. Trolltech and KDE have worked out an agreement http://www.kde.org/whatiskde/kdefreeqtfoundation.p hp that I think addresses most issues people have with the QT license. Trolltech has developed a great desktop environment and cross OS development toolkit and commercial licensing has paid for much of it (which in turn allowed Kdevelop to become such an incredible tool for linux/windows/osx GPL development). Still I fully understand that the QT license makes it legally difficult to freely commercialise the desktop.
On the other hand a lot of people believe the GPL is the way forward for QT and KDE.
Maybe these differences cannot be bridged; I do hope so but it won't be easy. And perhaps it isn't all that necessary either. Both KDE and Gnome have much better and faster function libraries; computers get faster; apt-get and yum make updating so much easier.. In a few years it won't hurt to have both installed and freedesktop.org will hopefully allow for theme unification.
Of those to whom much is given, much is required.
Microsoft only innovate in ways to manipulate the law.
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.
One thing that sucks about the typeahead lookup or whatever it is, is when I'm attached to a network drive at work over our slow ass Cisco vpn. It reading in the info to do the lookup makes typing anything in a huge struggle and I end up just using the mouse anyway. If it were a checkbox or menu item in the file selector dialog itself, it would better. And maybe it is, if anyone can enlighten me, using KDE btw.
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
Now with redhat gone fedora, how do people pay for all this stuff?
Whenever I bought RedHat, I figured the people at RedHat were shoveling the money around in some logical manner, but now what am I supposed to do?
I love free software, in the sense that it's available to all, even if they can't (or don't want to) pay for it.
Since I can pay, my goal is to drop $50-$100 on gnome.org or something, somewhere...each time a fedora release comes out. I'd like the drop to be managed by reasonable people--that is, the people doing most of the work, or the people contributing the most to the project, get a sizable part of the money brought in.
Any better ideas?
This was discussed some where by the Gnome people before. They said something about this feature being patented. So unless Gnome can find prior art, or reinvent the feature some how; it won't be showing up in Nautilus.
Sorry I can't recall the link.
The whole spatial thing, that is. It looks to me (reading the article and looking at the screenshots) just like the old 'Navagational' method. He's still browsing down to his files, it's just that there's windows open for the parent folder (and I think they're attached somehow to the parent).
/home/me/mymusic the operating system (here meaning all the software that's running my computer) takes care of that for me, storing by object type and letting me look for things based on what it is (an mp3) and it's meta data (artist, song, title, etc). Is this sort of functionality meant to be in Gnome 2.6?
I thought (and admidt I may be wrong) that the point of 'spatial' was to change the way files are stored all together. So that instead of putting an mp3 in
I'd like to see something to replace the file/folder Navigational method. It breaks down once you've got over 1000+ individual files scattered on your hard disk.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
I agree, and this is happening somewhat, especially the standards being set by freedesktop.org.
... it is extremely wasteful.
However I see no sign of them doing some stuff that should not be hard. Some services should be provided by running a seperate program, so that program could be replaced. An obvious one is to make the file chooser be a seperate program. In my sample programs, statically linked with the fltk toolkit, the file chooser is sometimes 1/2 the entire size of the program! And you cannot change it. And every program running the file chooser has to re-read the directories and the icon files and they type assignments, preview images,
Instead a program could popen("filechooser", "-flkajiuv", "oldfilename") and read the stdout to get the filename the user chose (more complex interfacing would be controlled with switches and more piped messages in both directions). The only other work the calling program should do is to detect if the program does not run and pop up a cheap, crude, fallback, such as a box the user can type the literal filename into. Notice that the called program does not have to actually do the file chooser, in most systems it would instead talk to a filechooser service that is already running, so cached information can be instantly reused.
I don't see any sign of KDE or Gnome doing this, but it would help an unbelievable amount.
Here are some specific programs that should be possible:
1. We need a "start" program. It should take an argument and do whatever is supposed to happen when the user double-clicks a file in Nautilus. This removes 90% of the work that a modern file displaying program needs to do! This is absolutely essential, and it is shameful that the command-line oriented Linux does not have this, but Windows does.
2. Even more obvious than the file chooser is programs to pop up error and message boxes, small yes/no questions, and input a text field. These would return the answer after the user hits the ok or cancel button. Maybe a more complex program that builds a simple panel of several questions and returns after the user hits ok/cancel. This would allow shell scripts to have a "gui".
3. Besides the file chooser, a printer chooser (it should return information about the paper size and a command to popen that you send postscript to), a color chooser (returns 3 floating point numbers as text), a font chooser (use fontconfig names), and perhaps several others...
Notice that adding these programs won't break anything. They should be designed so they work simply when you don't give any switches, the calling program can just wait until they exit, the return code indicates ok (0) or cancel (1) and stdout is what the user chose. Obviously a lot of switches will be added and there will be competition and incompatabilty between different implementations, but this has been proven to work out eventually with other command line tools.