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

Comments

Almost as interesting...

[starseeker]

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.

Re:Almost as interesting...

[be-fan]

The FD.O X server runs existing X apps just fine. Since it was based on the already-working kdrive server, it should be working (varying degrees of "working") through most of its development cycle.

Gnome 2.6 beta 1 release

[Anonymous Coward]

If you want to help Gnome 2.6, then you are in luck! The Beta release is here and it needs testing

More details here

Don't forget to report the bugs!

Re:Gnome 2.6 beta 1 release

[Mmm coffee]

Since you seem to be part of the team, I'll bite.

I've been trying to install gnome off and on for the past month and a half. Problem is that it's a major bitch to install, even with neat little shell scripts like CVSGNOME I run into at least a dozen quirky dependencies. Each dependency is hell and a half to get working, and requires at least an hour googling and tweaking to get running.

The first time I tried to install I got up to the point where I needed some XML library, which needed a font library, which needed font config, which needed three other libraries. Got the three libraries working, tried font config. Came up with a build error. Edited the source files myself. Recompile. Came up with another error. Asked about it on the font config mailing list. Was told "get the CVS version". Done. Tried running the shell script that generates the configure and makefiles. It crapped out. Spent a good hour modifying that script trying to get it working. Nada. Finally gave up.

This last time I stopped when it got to the XML DOC DTD so I could install GTK DOC or something of the sort. Spent four hours trying to get it to work, after posting on several boards asking for help when I was done banging my head against the keybard.

My bug report - It's design is based on a virtual clusterfuck of dependencies and is impossible to install, especially in my user space since many of the programs and scripts assume that they'll be installed in /usr. I'm not even argueing that it should be a click and drool install, just that it should be possible. On top of that I find that any good installation documents are non-existant, I'd be more than happy with a simple "install this first, then this, then that, which satisfies X's dependencies..." If I could install it I'd be using GNOME right now, but since I can't I'm using KDE 3.2. Konstruct alone makes KDE kick GNOME's butt.

And please don't mention "just update your distro/use Debian/etc", I'm using Linux from scratch. GNOME is the only program I have found to be totally impossible to install.

Re:Gnome 2.6 beta 1 release

[MenTaLguY]

Having recently done a GNOME build from scratch on HP-UX, I had to work out the dependencies (I just used a makefile rather than figuring out the optimum order by hand).

As far the core GNOME libraries go, though, here's an excerpt from the dependencies section of my top-level makefile. If you start from the bottom of this list and work your way up, installing the dependencies before you install each library/package, you should be OK.

(you may already have some, like xrender, if you have recent XFree86)

GConf: popt glib ORBit2 libxml2 gtk+

libgnomeui: gtk+ libxml2 libgnome libgnomecanvas libbonoboui libbonobo

libgnome: glib gnome-vfs libbonobo GConf

gnome-vfs: glib libxml2 libbonobo ORBit2 GConf gnome-mime-data

libbonoboui: gtk+ libbonobo libgnomecanvas libxml2 GConf

libgnomecanvas: gtk+ libart_lgpl pango

libbonobo: glib libxml2 ORBit2

libgsf: glib libxml2

libglade: libxml2 gtk+ atk

gtk+: glib atk pango

pango: glib freetype fontconfig xft

ORBit2: popt glib libIDL

xft: fontconfig freetype xrender

fonts: fontconfig

fontconfig: freetype expat

atk: glib

xrender: render

render: pkgconfig

glib: pkgconfig

Re:Gnome 2.6 beta 1 release

[Trevin]

When I installed Gnome 2.4, I tried following the installation notes at http://www.gnome.org/start/2.4/notes/rninstallatio n.html. It's mostly correct, but I still found a number of errors -- omissions, items out of order, and items that didn't exist in the distribution. I'm fairly certain that one thing which helped was the fact that I was upgrading from 2.2, which in turn I had installed by piecemeal replacement of the 2.0 RPM's that came bundled with my Linux distro.

A long time ago I tried installing Gnome from scratch, without having any modules pre-installed, and that was much worse. I get the distinct impression that the Gnome installation procedure is designed only for people who already have a previous release of Gnome installed, not for people who are installing from scratch.

Re:Windows Longhorn renders all this obsolete

[grennis]

Did you read the article?

GNOME ... catches the SVG fever ... quite a few of the games have switched to SVG based graphics, which is a really nice thing, and a move towards the right direction

FYI : SVG = Scalable Vector Graphics

New File Selector - WOO HOO

[starseeker]

A new GTK file selector. FINALLY. I can't wait to use the new one - the old one was one of the great warts of the free desktop world, IMHO.

But they have decided to remove the text entry box??? Eeep. I guess having the Ctrl-l shortcut to get one is OK (after all, it will most likely be geeks that want direct text on a file open) but thats one they need to document WELL.

On the whole though, it might be a good thing. I guess we'll have to wait and see. But text box or not, it can hardly be worse than the old one.

Re:New File Selector - WOO HOO

[hattig]

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.

Re:New File Selector - WOO HOO

[richie2000]

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.

Re:New File Selector - WOO HOO

[Anonymous Coward]

It is certainly not just geeks who will want or need to type in file names. Skilled typists will not want to move their hands from the home row to open a file. Making them use the mouse to open a file is a bad idea.

It's important to remember that some users are much more skilled at using some aspects of the computer than are developers, and that "easy to learn" is not the same as "ease of use."

Re:New File Selector - WOO HOO

[Ed Avis]

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.

Re:New File Selector - WOO HOO

[ultranova]

Since there is already a file browser such as Evolution

Isn't Evolution a mail reader and not a file browser ? Or did you mean Nautilus ?

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.

Or you could leave both options open and let people use whichever they want. Like it's done now.

Besides, if I have both mplayer and xine installed, how does the One File Browser know which one to launch ? Or Emacs and Vi ? Or whatever ?

And yes, I realize you can set this in preferences; but suppose you want to use different tools for different tasks, despite the file format being the same ? Or if I just want to try out a new program ?

To save a file, why not drag it from the application to the directory window.

Because that would mean resizing application windows to fit them besides the directory windows, and be a lot more hassle than simply using a selector window ?

Matthew Thomas pointed out better than I could that the separate file-picker is user interface cruft left over from an earlier age.

No, it's a useability feature. Lacking a separate file selector would give users unneccessary grief.

Let's just have one file browser in the desktop and make it good enough to use for everything.

The more features you bundle into a single program, the less likely it performs any of them well, simply because different features (such as useability and low learning curve) conflict with one another.

Re:New File Selector - WOO HOO

[Ed Avis]

I'm not just speculating about what might be cool; I've used both kinds of GUI a lot - those with File->Open and filepickers, and those where you drag from a file browser window to open and drag to the window to close. Personally, I greatly prefer the style without the filepickers. You might find it different but I encourage you to give ROX-desktop a try (although the usability improvement is diluted because not every application supports drag-and-drop loading and saving).

The filepicker dialogue box could be kept for those users who still want to use it, in the same way we still have the command line as well as graphical file managers. But if there are good features in the filepicker, they could be added to the main file manager so they could be used all the time, not just for loading and saving.

When I said drag the file to a directory window to save it, I meant 'to choose where to save it' - later saves to the same location are just a single keypress or click.

The more features you bundle into a single program, the less likely it performs any of them well, simply because different features (such as useability and low learning curve) conflict with one another.

This is kind of my point - the Unix motto, do one thing and do it well. Rather than each application having a cut-down file browser you have to use with Open and Save, use a single file browser program and get applications to talk to it for loading and saving files. Of course it might be a good idea to have a menu item or key shortcut which pops up a file browser window for the location you last used.

Again - although views on what's easiest to use are subjective, I am speaking from experience. I recommend you try ROX-desktop (or at least look at the web site and screenshots).

See also my other reply about how to load files in different applications.

Re:New File Selector - WOO HOO

[be-fan]

That'd suck. I *hate* file browsers. Currently, opening a file involves:

File -> Open -> Select File

With a file browser system, it would be:

Un-maximize word processor -> open browser app -> find folder -> position windows for drag & drop -> drag & drop

There are additional problems. From my experience with Windows users:

1) They don't understand drag & drop
2) They don't understand hierarchical filesystems

They think in terms of applications, not files. They want to open a Word document? They open Word, then open the document from the dialog.

Drag & drop based file selectors is just one of those inefficient holdbacks from when computers needed to model the "real world" by making everything appear to be physical manipulation.

Re:New File Selector - WOO HOO

[Minna Kirai]

1. Indeed, which is why RISC OS and ROX-desktop allow you to drag a file onto an application's window or icon.
   
   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)
2. You've got a little debate going between proponents of a separate filemanager application and those who prefer popup "Save As" boxes. Each way can have it's pros and cons. The big advantage a good SaveAs implementation can have is avoiding clutter (and extraneous actions like repositioning clutter) because the file widgets aren't displayed until they're needed. While a separate filemanager has the advantage that the user is more aware of it's context before needing to save, and thus needs to spend less time re-orienting herself when the window comes back up.
   
   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.

Re:New File Selector - WOO HOO

[SQLz]

A new GTK file selector. FINALLY

I hope they remember to send the KDE team a thank you note.

Re:New File Selector - WOO HOO

[MrLizardo]

It seems that users these days are going more the other way. Most Windows users (no idea about Mac-heads) seem to not realize that they have a file browser. It really comes down to whether the modern GUI is application-centric or file-centric, and I can see that for most basic home users it is heading towards application-centric. Unless people know they need to put something on a floppy disk or usb drive to take with them, it seems that in almost all cases they just save to the default location or a subdirectory thereof. IMHO, this is a good thing: It means all their files are in one place to be backed up, and that if their profile/home directory/whatever is stored on a server that they don't have to worry about saving their files someplace where they can access them from any machine. Unless they need to transfer a file somewhere, in which case they resort to using a floppy or emailing it to themselves. Most of Thomas' points are already dealt with in some manner, or a matter of personal opinion. If he had used Word in the last 7 years he would realize that it already auto-saves after the first time. If he had used a non-Mac computer he would realize that increasingly programs are heading towards an SDI instead of MDI. No more quit to close programs, just close any open windows! As for the issue of copying/moving files around: This is a symptom of another issue. The core issue that needs to be resolved is that you have to move your files around to have access to them everywhere in the first place. Different people have different ideas, one being a portable personal server that has all your files on it. The other idea is Internet connected file storage. Both have their own ups and downs but I believe that soon one or the other will become mainstream.
I think a more progressive model for a user interface is a more verb based one if you will, rather than noun based. With cheap, fast, pervasive Internet connections it's no longer important where your files are (or hopefully it won't be soon). Its more important what you want to do. For example, say you have a JPEG image: What you want to do with it is more important than what the file is named/where it is. When you find the file that you want among an assortment of different files, you still have to choose whether you want to edit it, view it, add it to another document, etc. I would argue that having to know where all your files are is the outdated cruft, not having open/save dialogs.
Personally, though I think that more choices for ways to do things is usually better, as long as one doesn't get in the way of another. There are definitely situations in which I find it easier to use a file browser than to use an open dialog.

Ok, this is kinda fragmented but I have to go to class now.

-Mr Lizard

Re:New File Selector - WOO HOO

[juhaz]

Why is it that drag & drop fanatics are always trying to force their preference to everyone else?

EVERY TIME there's talk about file selectors, someone pops up and seriously suggests an option that not only encourages the need to use mouse, but actually requires it.

Especially for saving... instead of hitting ctrl-s (and quickly typing a name if it's the first time), I'm supposed to a) resize application window, b) locate file manager from open windows, or open one if it isn't running, c) drag icon somewhere? Excuse me, I think I need to puke.

Re:New File Selector - WOO HOO

[Minna Kirai]

Certainly none that matches the convenience of the Filer windows in RISC OS where you would double-click (or drag) a file to open it, and drag from the application to the Filer to save

That's subjective... I could claim that needing to drag an icon from a text editor to a whole other window (which I'd have to find and make visible first) is painfully slow compared to :wresult3.txt, and in many contexts I'd be right.

That points to one big advantage of the dialog box approach: keyboard compatibility. Desktop environments which offer DnD should provide some (optional) way to perform equivalent actions from the keyboard, but I'm not aware of any having done so.

Digressing down that topic:
There have been some small steps made towards keyboard-controlled DnD, but I haven't seen any adequate yet. Of course, some systems let you push a button to steer the mouse from the keypad, but that's too awkward to consider. Some file managers include an abuse of the clipboard metaphor (like a Copy button which makes a "shallow copy", instead of a "deep" one like every other Copy command besides Excel) to provide features that could be better solved by enabling DnD via keyboard. There are assorted taskbar-applets which provide a "shelf" to set down an icon in mid-drag; enhancing one of those to be controllable by keyboard would be the most direct implementation of a solution.

Re:New File Selector - WOO HOO

[mike_sucks]

Which is of course *exactly* what is wrong with KDE. You only need one completion method that works well.

"Well *my* kettle boils water in twelve different ways!"

-mike

Performance

[Anonymous Coward]

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

Re:Performance

[Anonymous Coward]

Part of the problem is that developers, being geeks, tend to have all the latest kit. So the GNOME hackers working on their 512M / 1G 3 GHz box won't be concerned about performance, but the millions of desktop users running lower-spec machines will.

Let's be clear about this: the vast, VAST majority of machines on the planet, in homes and in businesses, have 32M, 64M (and occasionally 128M) RAM. That's nowhere enough to run GNOME/KDE, OpenOffice.org and Mozill at a realistic and usable speed. When did we become just as bloated as Microsoft?

If the GNME developers don't step back, look at the problem and concentrate on efficiency and clean design (rather than flashy features and bloat), it'll lead to long term damage for Linux on the desktop. They're doing a great job bringing Linux to the masses, but the masses are going to be less enthusiastic about Linux when it keeps requiring hardware upgrades...

Re:Performance

[FooBarWidget]

"When will we start to see serious performance improvements?"

With GNOME 2.0 and 2.6. Nautilus 2.0 got a huge speed boost compared to 1.x. Nautilus 2.6 is spatial and has because even faster. Windows appear instantly.

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

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

"When gconfd is eating up 20 megs (resident), just for a configuration back-end, it's evident that we're getting sloppy."

OMG not this again. I will repeat it *again*. Don't trust memory reports! The 20 MB you read includes shared memory! In reality it uses a lot less than 20 MB, somewhere around 6 MB on my system.
People who think software x is bloated by looking at the system monitor's memory report are just deceiving themselves.

And sometimes you need to use more resources in order to make things faster. Low memory usage doesn't always equal fast and high memory usage doesn't always equal slow!

Re:Performance

[murrayc]

Nautilus is much faster in GNOME 2.6. And it was faster in 2.4 than 2.2, and faster in 2.2 than 2.0.

There are also several specific performance improvements in particular GTK+ widgets, and the GNOME Help system has had an incredible speed up.

Linux kernel 2.6 also makes a very noticeable difference, with it's pre-emptive schedule that gives priority to things that the user is doing.

Re:Performance

[MacJedi]

Try Debian. Just do a base install to get a very minimal but bootable system and then apt-get install foo your way to whatever configuration you need.

As for a low resource using window manager, check out XFCE4. It has the look and feel of Gnome but is far more zippy on old hardware. I run it (and occasionally fluxbox) on a P2 300 laptop with 128 MB RAM.

Re:Performance

[Ed Avis]

On this system (Athlon 1.4 Ghz 390 MB RAM) I can definitely say GNOME 2.x is faster than 1.4.

That's the same argument Microsoft used to say that Windows 95 is faster than Windows 3.1. And on a system with plenty of memory, it is. But most people's experience with the hardware available at the time was that Win95 was much much slower, thrashing horribly with less than eight megabytes and still rather uncomfortable with less than sixteen.

Making a program twice as fast in CPU time but at the expense of using twice as much memory may not be a good trade-off. If you start running low on memory then you get a very steep performance drop from paging to disk (or not having enough RAM for disk cache, which is effectively the same thing). The most important benchmark is how it performs on a machine with, say, 64 megabytes of RAM, or whatever minimum level you want to require. Not shaving a few fractions of a second off times on recent hardware.

Re:Performance

[Malc]

According to Google's Zeitgeist", Windows XP represesnts 45% of the market out there (well, of their customers/users). Windows 2000 represents 18%, and although it will run in 64MB, I don't view anything less than 128MB realistic. Therefore, I would guess that the majority of people are already using machines with 128MB or more.

Re:Performance

[maxwell demon]

Some of the features described (the OO behaviour of the file manager, file templates) have been there under OS/2 Warp 3, running in acceptable speed in as little as 8 MB. And that was on a 486DX2/66.

IMHO, a window manager/desktop environment should always try to eat up as little space as possible. After all, the applications you run are getting more memory hungry as well.

BTW, nice to know that OS/2 goodies start to show up in GNOME! Now give me "Arbeitsordner" (don't know what the English name is, it's file manager windows which remember the documents opened from it and closing/reopening them when they are themselves closed/opened; sort of session management for single file manager windows), and I'll no longer miss anything from OS/2 Presentation Manager in Linux.

Re:Performance

[tolan-b]

I run gnome 2.4 on an athlon 800 with 384 meg ram, and it's pretty slow to be honest.

I know that's not a particularly up to date processor, but it's not that uncommon for home users.

Re:Performance

[FooBarWidget]

Did you forget everything else? Antialiased fonts, a configuration system which supports multiple backends (XML or LDAP or anything you want; important for businesses), heavy use of graphics that have millions of colors, bigger screens, more advanced underlying architecture (important for third-party developers!), MIME type sniffing, etc.

Yes OS/2 Warp did some of that but it also looks bad by today's standards and isn't nearly as advanced or polished.

Re:Performance

[Anonymous Coward]

None of the things you mentioned jutify the outrageous memory requirements. Heck, RISC OS had full anti-aliasing on 30 MHz and less machines.

I'd rather see new features being implemented efficiently and carefully, helping to make more of current hardware. If you're happy buying new kit every couple of years for the latest stuff, that's fine, but it's so Microsoft-esque. Some of iuus were hoping that Linux would get us out of this constant treadmill.

Wow...

[unknown_host]

"and now it is much easier to manage one's wallpaper collection".
That does it. I am shifting to GNOME.

Re:Windows Longhorn renders all this obsolete

[Etyenne]

The release of Windows Longhorn ...

...due somewhen in 2006 will render a 2004 software obsolete. Hey Sherlock, here's a cookie for your perspicacity !

Re:File selector!

[Lord of Ironhand]

Site doesn't like /. referrals, just click the URL and press Enter on each 403 Forbidden...

Complete Text

[Anonymous Coward]

Diving Into GNOME 2.5 - A Preview of GNOME 2.6
Sayamindu Dasgupta
The boring intro...
As a part of the Bangla/Bengali GNOME l10n team, I decided to give the GNOME HEAD branch a spin - in order to find out what's new, as well as to get an estimate of how much we would have to translate (I hate that part of the job) to attain supported status. The last time I did this, I also wrote an article about what I saw, but unfortunately, I never learn from my mistakes - so here I go again....
However, before jumping in into this guided tour, please remember that I have been involved with the GNOME community for the past few months as a helper in the GNOME Summaries, and I may not be able totally impartial towards GNOME. Feel free to consider me biased.

The Vital Statistics
Before going into the real stuff, let me give me a brief overview of my system, so that when I mention something as fast or as slow, you would be able to guess how it would crawl in your system.

Processor: AMD Athlon XP 2600+
RAM: 512 MB of PC 2700 DDR RAM (with 875 MB swap)
Motherboard: Nforce 2 based mobo from Leadtek
Storage: A 40 GB Seagate Barracuda HDD
Distro: Mandrake 9.2
Kernel: 2.6.2
The Installation
I had gone through (successfully) the GNOME dependency maze before, and to avoid losing my sanity, I decided to use jhbuild (one can also use GARNOME or cvsGNOME - maybe I'll test one of those with GNOME 2.8) .
Using jhbuild is quite easy - just set some variables in ~/.jhbuildrc, and you are ready to roll. Jhbuild grabs the latest source code from CVS (taking care of the dependencies), compiles them, and installs them in whatever $prefix you want them to be in. OK - there was one major problem - but that was at a later stage, and it got fixed really quickly.

First Impressions

Fig 1. The default GNOME 2.6 desktop
Jhbuild took around 6 hours to get a bare bones GNOME system up and running, and surprisingly, there were very few errors, and I had to manually intervene only thrice.

I logged in as root the first time (yaya - I know security risk and other stuff..), to be greeted by a clean and polished looking GNOME desktop (Fig. 1) . (Note that I am running the Freedesktop.org Xserver here - so don't expect a stock GNOME 2.6 install to have panel shadows).

Seeing an icon named "Computer" right on the desktop - my first reaction was to click on it, expecting Nautilus to pop up with my "/" directory or something like that.

Nautilus goes spatial
However, as soon as I clicked on that icon - my reaction was "Yikes!! What have they done to Nautilus ??". Gone was the old and familiar explorer like interface. In it's place was a really minimalistic window, with no toolbar, just a plain menubar. I was quite confused - I even clicked on "Help" -> "About" to verify that the "thing" was indeed Nautilus. After some head scratching I remembered a post at FootNotes, in which the Nautilus developers announced something about going "Spatial". People had been pretty much excited about this - though I personally had no idea about what this stuff was all about. Now I thought I understood.

Fig 2. Spatial Nautilus - Showing "Computer"
All my disks had been correctly identified by Nautilus, and was showing up in the "Computer" window (Fig. 2). But that was not very important at that point - all my attention was riveted on the new UI. After some Googling and RTFM sessions, I figured out that Nautilus was following a "Object Oriented" metaphor, instead of the normally used "Navigational" metaphor. The most user visible aspect of the OO metaphor is that there is a always a direct, one-to-one relationship between folders and windows, and the window for each folder remembers where you placed it the last time - i.e, the next time it will pop up in the same position. This new interface is partially inspired by the interface described in http://arstechnica.com/paedia/f/finder/finder-1.ht ml.

Fig 3. Viewing a deep folder with spatial Na

gpdf

[starseeker]

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.

File selectors? Why?

[Anonymous Coward]

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)

Re:File selectors? Why?

[DreadSpoon]

Getting rid of file selectors all together is *waaay* too big of a change for a minor version increment. Maybe in GNOME 3.0, sure. But not just jumping from 2.4 to 2.6. That'd be like dropping a new VM in a stable kernel series or something. ;-)

Re:File selectors? Why?

[Stinking Pig]

I would assume it's because nautilus is a lot bigger than a gtk file selector. Anyway, a file selector is still required because people will choose to run your apps while the whole DE is not running. For instance, I run a number of GNOME and KDE apps on XFce4; I may have konqueror installed, but it never runs and I certainly don't have nautilus installed. Even if they were installed, if they were required to do file operations from Cervisia or Gnumeric I'd have to wait for those browsers to come up from a standing start when all I wanted was to open or save a file.

Spatial Nautilus?

[Anonymous Coward]

As much as I like the idea of it being smaller and faster, it's still kind of strange.

The windows take up 1/4 of a 1024x768 screen. I don't want to have a bunch of gigantic nautilus windows filling up my small screen.

Re:Spatial Nautilus?

[hattig]

Not quite, because Windows will happily open two windows pointing to the same location, whereas a spatial interface will only have one window for a certain location in the filesystem. If you open ~/pr0n/, it will open in the same place as the last time you opened it, and if you have it open already, then it will merely be brought to the front and activated.

This makes it a lot more simple. I hope it has a facility for opening the parent window if it isn't open though.

Re:Wow

[q.kontinuum]

But then again it's the only wm that works well on a cel500 128mg ram laptop.

I don't think so. On my laptop (166MhZ, 64MB) I get along with my WindowMaker. (Of course it depends wich applications you want to use.) On my Desktop at work (Win2000 with cygnus) I also run a WindowMaker and I'm so contempted that I switched to WindowMaker at home as well (360MB, 850MhZ). Regards

Gnome and KDE interoperability

[pubjames]

I've always thought that the reason having two (main) desktops (KDE and Gnome) is good is not necessarily because of the competition, but because there is a need to interoperate between the two, so sensible 'generic' programming interfaces need to be created. This should create more modular code, and modular code makes successful open source projects.

However, to what extent is this true? Can I, for instance, use just the Gnome file manager in KDE, and vice-versa? Is it an aim of these projects to make this level of interoperability a goal?

Re:Gnome and KDE interoperability

[IamTheRealMike]

However, to what extent is this true? Can I, for instance, use just the Gnome file manager in KDE, and vice-versa?

Yes, you can. Try nautilus --no-desktop (I think that is the switch).

Expect some stuff to break though. Noticeable KDE uses illegal URI syntax so drag and drop of files etc to/from KDE apps won't work so great I suspect.

Standardisation will allow us to reach these giddy levels of interop but it's not there yet, and to be frank most effort is going on stuff that actually matters (like the new shared mime database that appears in 2.6)

Re:Gnome and KDE interoperability

[dominator]

There's quite a bit of inter-operability work going on at freedesktop.org. There's a lot of shared specifications and software there. Plus there are software libraries that both DEs use that aren't listed on FDO, like libxml2.

The KDE folks have also worked on some Qt-GTK toolkit inter-operability stuff. See also:

GTK-Qt
Ditto
Glib/Qt main loop integration

amongst others.

Re:Gnome and KDE interoperability

[spitzak]

I agree, and this is happening somewhat, especially the standards being set by freedesktop.org.

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, ... it is extremely wasteful.

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.

OS/2 lives again!

[Garg]

From the decription of the 'spatial desktop', it sounds like OS/2 Warp circa 1995.

We only had to wait a decade or so for Moore's Law to make it usable... :-)

Garg

Re:Yuk

[Xpilot]

I guess I'll never be a Gnome user. What is the fascination with muddy colours?

GNOME is quite themable; if you don't like the muddy colours, use another theme.

Re:Wow

[Anonymous Coward]

"I'm so behind, I'm still using fvwm2"

Perfection is achieved not when there is nothing left to add, but when there is nothing left to remove.
-Some Wise Guy

I use fvwm2 and I have an XP2600+ and a gig of RAM. I use a lot of Gnome-ish apps but evey time I use a different wm it lasts about half a day and I'm back to fv.

There is really only one reason you (or I) should stop using it; because you want to. That being said, Gnome sure is purdy.

Re:Its called KDE 3.2.

[sniggly]

It's unwise to say that kde is better than gnome on slashdot. It isn't true either. A lot of people will appreciate the way gnome works, nautilus reminds me of the finder in mac os pre osx - some people love it, some hate it, most don't care.

It'll be interesting to read a decent "neutral" KDE 3.2 vs Gnome 2.6 article though! And it also has to be said that the competition between KDE and Gnome really had driven both communities to excellence. Als competition has not deterred them from cooperating in freedesktop.org - something to be encouraged until hopefully one day somehow the libraries can be unified.........

Re:So good, so dull....

[FePe]

If you don't like the standard look, you can easily apply a diferent theme. Try browsing through this and see if anything could spice the Gnome desktop up.

Nice Job

[ickoonite]

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 :)

Re:Nice Job

[ajagci]

GNOME vs. KDE will perhaps be one of the holy wars of this millennium,

Yes, and like most holy wars, it's about obsolete ideas. Gnome and KDE are both serviceable desktop environments, but let's not kid ourselves: imitating Windows and MacOS should not be the future of computing.

Personally I'll keep Mac OS X on this for the moment, if only to avoid kernel recompiles and incompatibilities arising from that,

Whatever makes you happy, dear. Personally, I dumped Mac OS X because I got tired of the manual upgrades and install hassles; Debian has been much less effort to maintain and has a lot more software available for it. And kernel upgrades just work, with no recompiles, with Debian.

Re:Nice Job

[ickoonite]

I was going to agree with you whole-heartedly, but then I reread your post a couple of times...

Away from the desktop on x86, I'm a Debian man, and it has done a superb job as a router and web server at home. The upgrades are superbly simple for a Linux-based operating system. And, should I be bothered, I'm sure it might make a reasonable desktop...
But you have piqued my curiosity - I am intrigued, what, pray tell, do you mean by "manual upgrades," "install hassles" and "a lot more software available for it"?

Apple's Software Update is automatic. Debian requires that you do at least type the various commands.
The Mac OS X Installer requires that you click Next about 10 times, I Agree once and click a hard disk icon. If you are a geek, then include the Customise button and a few tick boxes. Incidentally, the Installer is also the program used for installing a lot of software on the Mac, providing a unified feel for all installers (obviously apt-get gives you that too, but it's kinda scary for Joe Sixpack). My mum could install Mac OS X; she wouldn't even try Debian - it is hard!
Command line Mac and Linux have exactly the same software. On the desktop/work environment, there is simply no competition - the Mac, though not so "enriched" compared to Windows, wins hands down (Microsoft Office, Photoshop, iDVD, Final Cut Pro, Shake, Maya, the Macromedia apps [soon to change, perhaps], a whole boatload of games)...

So a reread has left me thinking: what on earth are you on about...?

iqu :?

agreatserver?

[WanChan]

You're sure about that?

I tried to use GNOME

[metamatic]

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.

Re:I tried to use GNOME

[sniggly]

I'm a KDE fan mostly because of the immense productivity gains that kioslaves offer. It's wonderful to be able to open a remote file through sftp in kate or konqueror simply by entering its URL and edit it as if it's a local file. Whether it's uglier.. I think that's a matter of taste, gnome is much cleaner but KDE can be adjusted to be much cleaner in appearance as well.

Re:I tried to use GNOME

[I_Love_Pocky!]

Not that I would like to deprive any long time user of the possibility of single click activation, but it should really not be the default.

Why not? Just because it isn't what you would usually use. When I am forced to use a Windows machine the first thing I do is change it to single click activation.

I actually had several people making fun of me because I used Windows in this way. I just can't understand it... Why click twice when you could click once? Your mouse button lasts twice as long. I guess I am just lazy.

On a normal desktop you can pick things up for inspection and manipulaiton. Having single click for activation gives the user no easy way to do this.

Umm... the activation doesn't occur until you release the mouse button, so if you click it and hold it, you can move it as you please. Once you start moving it, when you release the button it drops the icon. How does this make it not easy?

New File Selector with type ahead

[tjwhaynes]

It is certainly not just geeks who will want or need to type in file names. Skilled typists will not want to move their hands from the home row to open a file. Making them use the mouse to open a file is a bad idea.

So ... type in the name of the filename, anywhere in the window. This file selector has type-ahead support so it will search through the files looking for the next file that matches the string you have typed so far. If you've been using this feature extensively in Mozilla, it'll be second nature already.

Cheers,
Toby Haynes

Re:New File Selector with type ahead

[thelexx]

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.

Mirror

[unmadindu]

OK - Here's a mirror that should work properly - sorry for the initial goof up http://www.clai.net/sayamindu/GNOME-2.6/GNOME_2_6. html

Nicely written article!!

[mritunjai]

Have to say it, this was one of the best written personal review article submitted to slashdot in recent past.

It covers the functionality well, does not break the continuity and was fun to read.

If only we had more articles like this, slashdot might gain few more subscribers.

you guys are so mean

[tuggy]

triple slashdotting??
are you trying to break a new record or what? ^_^

twist on an old alaskan joke.

[juggaleaux]

"My Uncle switched Linux Desktops today." "Gnome?" "Know him? He's my uncle!"

About spatial navigation

[mst76]

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

Re:About spatial navigation

[hattig]

Maybe they never used Windows 95 either!

True Spatial Navigation is quite good really. As long as you have options for opening the parent folder, and autoclosing the parent folder when opening a new folder to keep clutter down. ... and of course, the option to disable it completely if you want an explorer like UI.

No pattern match in file-selecter

[TheSunborn]

Did they REALLY make a file requester widtout pattern matching? WHY? Even windows got that feature, and it is so usefull that there are NO reason to leave it out.

I disagree

[bsd4me]

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

Re:I disagree

[bsd4me]

... That doesn't mean these are bad features, they're just features that are only appropriate for modern, mainstream hardware.

I think this is a really the wrong approach. Designing primarilly for new hardware hurts lots of end users, especially in poor countries. You would also be surprised to see what is still being used on the desks of most corporate users.

Core software designed for a broad audience needs to be designed for the middle ground. Not the lowest common denominator, but not brand spanking new. You then need to make it tweakable (either run-time or compile-time) to make it acceptable on low end hardware, and run well on high end hardware. Personally, I think the middle ground is a low lower than most people think.

I expect make buildworld and portupgrade gnome2 to take a long time, but the performance hit with Gnome 2.4 really shocked me.

It's open source. You have the power. Think outside of the proprietary software box!

I find this a little condescending. I started using linux in late 1991 dual-boot and by mid 1992 my machine was linux only. I use FreeBSD now, but I am well aware of how all of this works.

However, I am also a professional developer with a 9-5 (ha!) job, but I also have my own open source project, other extra-curricular professional activities, and a family.

Where do I dedicate my time?

General OS

User-interface

General applications

My project

Developemt enviroment that my project relies on

When I was a college student and single, I was able to dedicate lots of time to the early linux development, but not I have to cut back and focus on my project.

Favorite quote

[doktorstop]

One thing that always bugs me (oops, I mean... "enchants me") about these reviews is the obligatory sentence "slick and polished desktop". Look at the picture... it's an empty grayish uniform square with nothing on it... Now if the Gnome developers could only remove the remaining 1-2 icons and the menubar, add a command prompt right over it (alpha-channel of course)... would be an extra-clen super-polished desktop! Oh the joys of removing everything, and going back to the CLI!

Re:Its called KDE 3.2.

[ajagci]

It'll be interesting to read a decent "neutral" KDE 3.2 vs Gnome 2.6 article though!

About as interesting as a "neutral" Britney Spears vs. Paris Hilton article.

something to be encouraged until hopefully one day somehow the libraries can be unified.........

They could have been unified long ago if the Qt license (GPL) didn't prevent it. You see, ultimately, the difference between KDE and Gnome doesn't come down to technology, it comes down to licenses, and the Qt license just doesn't work for many people.

Hyperbole is fun

[Imperator]

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. [emphasis added]

Isn't this just a tad bit harsh? Imagine someone opening his TiVo box:

TiVo Quick Start Installation Instructions

Step 1: Your TiVo runs the Linux operating system, and if you install development tools you can use it to create graphical user interfaces or GUIs. Therefore, before you finish setting up your new TiVo, please read the Amiga User Interface Style Guide.

Step 2: Unpack the TiVo and the AC adapter (figure 1).

[...]

Step 55: Quick quiz: what do the Amiga User Interface Style Guide say about resizing windows that have widgets in a grid layout? Have the answer ready before you call Technical Support, or you will be put on hold while you reread the Amiga User Interface Style Guide.

[...]

Step 128: Profit!

Watch out for line breaks in article

[palad1]

Firefox was set to 800x300 , here's what I could read:

As a part of the Bangla/Bengali GNOME l10n team, I decided to give the GNOME HEAD

those bengali guys sure are strange...

Spring loaded folders

[unoengborg]

This new spatial apperance of the new Nautilus reminds me of old MacOS finder. I liked it back then and I will probably like it in Nautilus.
But I am a bit worried, some folder hierachies in Unix is quite deep.

Perhaps they should introduce something like the Mac spring loaded folders.I.e. if you want to move a file down in the hierachy you just drag and hold it over a folder, after a short while the window opens, and you hold the file over a folder in that window, until that opens and so on. When you finally reach the right folder you drop the file, and all windows you encountered on the way is closed automatically.

Re:Spring loaded folders

[the_c0de_man]

PATENTED. Us US folk will have to do it another way for the next 20+yr.

Re:Spring loaded folders

[zeasier]

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.

Gnome for the Developer

[0xB00F]

Not trolling or anything, but here goes...

As a developer, I have always been interested in writing software for Gnome since 1.x. The one thing that has really set me back from doing so is the fact that with each and every iteration, something in the very core of Gnome changes and more often than not, those changes mean that you would have to recode large chunks of your software to cope with the changes.

Yuh, sure all your Gnome 1.x apps will still run but it won't be able to use any of the new features in 2.x. This comes naturally, since this is after all a "major release" upgrade. They've really done it with 2.x this time, something major changes with each "minor" version is released. I know this is all about bringing Gnome closer into the "integrated desktop where you have everything you need to do everything you need" that it is trying to achieve.

Case in point, this whole new-fangled "Object-Oriented" metaphor. Now not only do I probably have to learn a whole new set of interfaces to get desktop integration going for programs that I write for Gnome, I also have to learn how to operate this contraption. I mean come on! Do we really need all this HIG crap?!? My UI was "usable", at least for me, before all of this HIG things were implemented. If the developers want to implement this HIG thing, then go ahead and do it but it would also be nice to let users with "bad habits" choose to revert to the old UI behavior when they want. And for heaven's sake, leave the API's unchanged until the next major release! Being a developer for Gnome is a lot like being Sisyphus.

Now I realise why there are more apps written for KDE than for Gnome.
</rant>

Yuh, I know this rant probably doesn't make any sense to you. But maybe that's because you haven't been around when Gnome 1.x was new and Miguel was still sane.

(puts on asbestos underwear and ducks under the sink)

Re:Gnome for the Developer

[Tyrell Hawthorne]

Do we really need all this HIG crap?!? My UI was "usable", at least for me, before all of this HIG things were implemented.

Yes. Or rather, each and every one of us might not be in dear need of it, but if we want Linux and free software to grow into the mainstream, then we sorely need human interface guidelines and more of the kind. Open source programmers write software to scratch their personal itch--that itch most often doesn't include creating user interfaces that follow good user interface practices, as long as they understand how it works things are fine. Then it's good to have guidelines to follow, so that they easily can make it easier for other people to use their software. Knowing when to do this or that isn't always easy, but it gets easier when you can quickly look into guidelines and find the answer.

Re:Gnome for the Developer

[damiam]

They've really done it with 2.x this time, something major changes with each "minor" version is released.

I have several apps originally written against GTK 1.3 (a prerelease of 2.0). They compile perfectly against GTK 2.4. Nowhere has backwards compatibility been broken.

Now not only do I probably have to learn a whole new set of interfaces to get desktop integration going for programs that I write for Gnome

The Nautilus changes are irrelevent to other GNOME apps. Unless you've was jimmying around with Nautilus internals, nothing has changed.

Re:ICEWM

[pe1rxq]

I use ctwm on a pentium 120 with 16MB RAM, its perfect for such a machine.
dillo for browsing and nedit for editing works fine on it. For real text processing even abiword is workable.

You can use such a machine perfectly well, you just have to be picky about what you use on it.

Jeroen

Re:Windows Longhorn renders all this obsolete

[unoengborg]

For your information, both Gnome and KDE are moving away from bitmaps right now, not 2007. And if you are talking about database driven file systems even Gnome people make experiments with that.See:
http://www.gnome.org/~seth/storage/feat ures.html

I would be surprised if there was many new things in Longhorn when it finally gets released. Not so much because Microsoft hasn't the technical knowhow to produce something new, but if Microsoft alters their GUI too much existing windows users will not feel at home.

A too big change would be bad for marketing. If you are going to learn a new way of working you can just as well learn something that is free.
It will be minor innovations like multiple desktops (known to the rest of the world since about 1990)

In fact I'm not even sure there will be a Longhorn. It sort of looks more and more like Pink and other pre MacOS X Apple OS attempts. It gets more and more delayed and filled with features that nobody really wants.

Instead I guess Microsoft will shift their focus of development to MS-Office and try to tie it more to the server side where Microsoft is not doing so well at the moment.

Re:Its called KDE 3.2.

[sniggly]

Yeah it wont be easy to write a 'neutral' comparison :)

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.

Re:Its called KDE 3.2.

[GAVollink]

Troll or not troll your post borders on being off-topic. Especially how it's worded as an advertisement.

I should also point out that some people have trouble supporting the Qt licence that KDE is built on. Qt is open (sort of) and closed (sort of), and there seems to be little concensus about how open it is -- having read the license myself, I'm still not sure. Thus the reason why the Desktop Linux project isn't supporting it.

A better way to work your post is that the Gnome 2.6 beta screenshots appear to take great strides in catching up to where KDE was several months ago.

Re:Windows Longhorn renders all this obsolete

[fr0dicus]

Unfortunately the release of Longhorn has already been obseleted by OS X 10.3 (and 10.4 and 10.5 which will both have come out by the time we see Longhorn).

Microsoft only innovate in ways to manipulate the law.

XFree86, GNOME, and KDE are all dead in the water

[Overly Critical Guy]

Here's why. We need to get away from this obsession with 20+ year old graphics servers running 20 different inconsistent toolkits, all working extra hard to "work well with each other" when we should really be focusing our efforts on one major desktop competitor running on Linux.

Re:XFree86, GNOME, and KDE are all dead in the wat

[Anonymous Coward]

1. Just because something is 20+ years old, it doesn't mean it should be thrown away. Plenty of people like the idea of heirarchical filesystems. Plenty of people like mice, monitors and keyboards. Plenty of people like icons and windows. The X protocol in current use isn't 20 years old. It's matured and gone through a number of revisions, just like any other technology.

2. If you are advocating a single desktop that runs on Linux, I guess you want to get rid of FreeBSD etc?

3. What happens when the desktop project starts being unreasonable? The only reason we aren't all stuck with XFree's tantrums is that competing projects like fd.o give users leverage. Do you really think that the XFree team would have backed down on the license change if they didn't think everybody would switch away?

4. There's no clear "winner". KDE and GNOME have different design goals, and lots of people agree with KDE's set of design goals, and lots of people agree with GNOME's design goals. You'll never get consensus, and you don't provide a reason for getting rid of one of them.

5. You state that X/KDE/GNOME are dead in the water, when in fact they are moving along at a rapid pace, and then point to Y, something that is barely out of the vapourware phase.

6. You state "we should be focusing all of our efforts...". Exactly what effort are you focusing? Or are you just an armchair know-it-all?

6 points, and you get called a troll. Bye now.

I don't get it

[rsilvergun]

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

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

My response

[Overly Critical Guy]

I should note that I am not at all surprised someone smoking crack modded me down as "Troll." What makes Linux so great that it's above criticism? XFree86 for that matter? Here on Slashdot, if you dare criticize something and hold a differing opinion than the majority, you get modded down.

I'll take your post point-by-point.

1. Just because something is 20+ years old, it doesn't mean it should be thrown away.

If you had bothered to RTFP (read the fucking paper) I linked to, you'd see *exactly* why using that 20+ year old X technology is a bad idea.

Plenty of people like the idea of heirarchical filesystems. Plenty of people like mice, monitors and keyboards. Plenty of people like icons and windows.

I have no idea why you're bringing all that up. Those are abstract concepts and ideas, like the idea of books, pages, and chapters. I never mentioned anything about those.

The X protocol in current use isn't 20 years old. It's matured and gone through a number of revisions, just like any other technology.

The X protocol *is* 20 years old. It supports extensions really well. As the paper outlines, many of these extensions are breaking other extensions. A typical desktop runs about 26 extensions. Not to mention that adding certain graphical effects requires changing a lot of architecture in the source code because of the way XFree86 is set up.

2. If you are advocating a single desktop that runs on Linux, I guess you want to get rid of FreeBSD etc?

Port it to BSD if you want. That's not even a relevant issue to what I was talking about--removing this silly desktop "competition" going on between competing products, completely scaring away any serious company wanting to write an app for X. Who do you write for? GTK? QT? Motif?

3. What happens when the desktop project starts being unreasonable?

What if both GNOME and KDE become unreasonable? You can't argue with a "what if" because it could apply to absolutely anything. You haven't even defined what you mean by "unreasonable."

The only reason we aren't all stuck with XFree's tantrums is that competing projects like fd.o give users leverage.

It's a fork of XFree86. It still has its tantrums. X doesn't even have its own widget set. The issues with X are much more fundamental than you are discussing here.

Do you really think that the XFree team would have backed down on the license change if they didn't think everybody would switch away?

What does the license have to do with anything? I'm talking technologically and logically--XFree86 needs to be gone, and the two competing desktops need to get their acts together. All these incompatible toolkits have driven away serious desktop development all in the name of "choice."

4. There's no clear "winner". KDE and GNOME have different design goals, and lots of people agree with KDE's set of design goals, and lots of people agree with GNOME's design goals. You'll never get consensus, and you don't provide a reason for getting rid of one of them.

Application support. There. Which one should Adobe port Photoshop to? If we had one seamless desktop with proper binary installation/uninstallation routines and a sane programming library that retained backwards-compatibility with each major release, you don't think companies would take a look?

5. You state that X/KDE/GNOME are dead in the water, when in fact they are moving along at a rapid pace, and then point to Y, something that is barely out of the vapourware phase.

Vaporware? You can already download it and compile. Developers are writing the base widget set as I type this. I don't get this bizarre aversion to change that Linux users have.

6. You state "we should be focusing all of our efforts...". Exactly what effort are you focusing? Or are you just an armchair know-it-all?

I'm currently writing a design paper. Sto

Re:My response

[some guy I know]

X doesn't even have its own widget set.

Actually, X used to be shipped with a basic widget set called the "X Toolkit", and also with a somewhat more advanced library called "X View" (which implemented more advanced concepts like callbacks ("notifiers"), etc).
I remember using these libraries when I wrote a font editor (around 1986 or so).
I found them easy to use, and bereft of much of the cruft that seems to have accumulated around more modern libraries (such as GTK+, etc.).
However, I don't think that XFree86 implemented either library, for some reason.