OSNews

But nautilus-burn does it for me, in a far nicer way. Third party applications like Brasero can always be installed if you need them specifically, but tightly integrated services like nautilus-burn add some real value to the desktop that "normal" applications can't provide. Or maybe you just meant that Brasero should become a part of the GNOME project in some way or another, there would be nothing wrong with that of course.

I meant the second, yes.

Nautilus burn needs, at least IMO, a user interface improvement. I've found many people that thinks that ubuntu can't burn cds because the nautilus burning interface is not...very easy to "find". They ask me what they should to to install a program that does it (and then i tell them to install K3B, which rocks, just to avoid them confusion)

It's right there in the places menu (one to the right of Applications on the desktop) and it has a very clear name. What would you suggest? I think some users are just so conditioned to the idea that CD burning is provided by a third party application that they don't even notice the integrated solution if it stares them right at their face. That cannot necessarily be fixed by the software, so why not tell them about it when they ask? Of course K3B is always a safe bet, but there is no reason to tell them to install K3B if all they want is to burn an image file.

i think that nautilus-burn's window needs a bit of text (small size, italics) right under the name in the blue banner, saying "drag n drop some files here to burn". It is not fool-proof obvious for some people what to do.

Edited 2007-03-14 23:27

Exactly.

I think some users are just so conditioned to the idea that CD burning is provided by a third party application that they don't even notice the integrated solution if it stares them right at their face.


Right, that maybe the problem - which may befixable which just adding a "CD Burner" icon in the apps menu that opens the cd burning folder. But. "Usability" is about people being able to use software, so if they can't find what they want despite of being there...there's a usability problem IMO.

For example, you may argue that the "places -> cd burner" menu is "usable". But why should users think of the cd burner as a "place"? And what happens when you've a CD inserted?: You've the cd menu entry, AND the burner entry. IOW, there're *two* menu entries for the same physical thing. And that apparently confuses users.

And then, there's the nautilus burning interface: A "virtual" directory. Sure, you and me know that you should copy & paste the files there. There's only a not-clickable "burn" button. Nothing informs users that they're inside of a "burning app". It shouldn't be to hard to put a small text there: "Drop here the files that you want to burn" or something.

And then, when they move around the directories and they want to return to the CD burning app...how to do it? You can do it, but it's not easy for novice users.


IOW, I think that the nautilus burning interface is just not intuitive. It's very brave to try unify the cd burning app with the file manager, but unless you make things easier, users are not going to use it.

Well when you put a blank CD in it prompts you then opens up nautilus. I think people are going way to far with this, it's not like XP intergrated burning is obvious to.

It's not like anyone uses XP's integrated burning, either.

That's funny, like I have time at work to bother with loading up that convoluted POS Nero to burn a CD?

Nop, I rely on XP's integrated CD burning. Quick, unobtrusive and reliable.

DVD's a different kettle of fish.

And then, there's the nautilus burning interface: A "virtual" directory. Sure, you and me know that you should copy & paste the files there. There's only a not-clickable "burn" button. Nothing informs users that they're inside of a "burning app". It shouldn't be to hard to put a small text there: "Drop here the files that you want to burn" or something.

The nautilus burning interface is very similar to the XP interface. So if people are having problems with Gnome then they most certainly have problems with XP. I don't think it is too confusing considering there is a big "write to disk" button in the window. That being said I prefer using Brasero. I am used to having another program to burn CD/DVDs with.

I've met several windows user who had no idea that XP could burn CDs out of the box, so as such I'd say that XP does not have a good CD burning interface and should not be emulated.

I'm pretty much an idiot when it comes to working my Ubuntu/Linux drive...
so I asked on the LinuxForums.org site about a suitable burner for Ubu,
and installed whatever it was they recommended (couldn't even call its name now!)
Took one look at its decidedly UN-intuitive interface,
couldn't figure out what the hell to do,
and forgot about it, and haven't returned!

Nowadays, when I want to burn something, I fire up the XP drive, and use NERO, which I know and understand.

WHEN will the Linux ppl come around to the reality that 90% of us idiot computer users are NOT geek-types?
We want/demand INTUITIVE, not dorky!

Are you talking about just burning files, mp3s, oggs, etc. to a cd?

If so, just put the blank CD or DVD in the drive, wait for the CD/DVD Creator window that will pop up, drag your files or folders to it, and click the "Write to disc" button.

You don't have to download any apps that you don't find intuitive to do it.

If you are using rewritable media and it already has something on it, you will have to go to Places->CD/DVD creator to pop up the window. It will ask to confirm that you want to erase what is already on it.

If you are wanting to burn an iso image directly, just right click on the image file and select "Write to disc".

The only thing that this facility will not do for you is burn an old fashioned music CD. For that you need to use a different app.

Hope this helps!

-Steve

Edited 2007-03-18 01:00

"I think some users are just so conditioned to the idea that CD burning is provided by a third party application that they don't even notice the integrated solution if it stares them right at their face."

These basic tools belong to Linux and BSD distributions for some years now. The users should get aware of the fact that a modern OS contains such tools by default.

"That cannot necessarily be fixed by the software, so why not tell them about it when they ask?"

Maybe it's too complicated for them to understand? "But I have to install something if I want to [insert desired action here]!" seems to be a common principle.

"Of course K3B is always a safe bet, but there is no reason to tell them to install K3B if all they want is to burn an image file."

For FreeBSD, burncd would be the first choice, connected to a drop icon in Gnome, or simply called via a xterm session.

I can't imagine how they could not see automatically opened window after inserting blank cd.

They don't insert the blank CD - because they don't know there's a burning app!

Hmm.. maybe that depends on how specific people work. I gather materials first (like insert cd), and then start work on them. Other people first start to work and then notice they need materials (burning app asks them for cd).
Anyway, if they are used to burning cds on their comp, and they are not "experienced" enough to find "cd creator" menu item... then they would have problem with launching any other cd/dvd burning app (i assume someone else installed different OS and/or GUI on their comp).

I agree (with one of previous posters) that adding some short info (about pasting files) to that blue bar above items view could help too.

basically apps that are part of the release are no different then gtk apps you install yourself later, except the fact that they arent included in the release.

Yes, but in many people don't install apps, especially people in offices. Defaults matter in a distro.

Yes, but in many people don't install apps, especially people in offices. Defaults matter in a distro.

Indeed. I once had to change the colours on a Windows desktop for a user who had no idea what had gone wrong. Oy.

Personally, I wish someone would create a project that would tie in GnomeFiles.org and pup or pirut or whatever GUI package installer du jour is. There's still this huge gap between browsing available apps on GnomeFiles and actually installing them.

For me, nautilus-burn really doesn't do it for me because you can't brn iso images - sure, I drop to command line and do it manually, but at the same time, I would have thought that along with packet based writing (treating a cd/dvd like any other storage), image writing would be quite important.

Simply right click an ISO image and select "Write to CD".

"""
Simply right click an ISO image and select "Write to CD".
"""

I just want to add that this has been true for quite a number of releases.

Some people, who disagree with the level of simplification of the Gnome UI, want to see more options added back.

But this user missed a very basic one in the current forest of menu options.

I think it is obvious that we need at least three levels of interface, selectable by the user:

1. Novice
2. Intermediate
3. Advanced

The current strategy of simplifying the primary interface and stuffing all the rest into the gconf-editor is suboptimal.

The user should be able to start out with a simple, reduced option interface. And then graduate to higher levels as their proficiency increases.

I'm not confining my recommendation to Gnome, BTW. Gnome, KDE, and XFCE are all in a position to implement it.

First one that does will be a winner.

"I think it is obvious that we need at least three levels of interface, selectable by the user:

1. Novice
2. Intermediate
3. Advanced"

I've suggested this as an idea to improve KDE. Because this has been discussed a few times, I just want to add a fourth level.

4. User configured

In this level, the (advanced / professional) user could configure all options and menues for what they should include, item by item, rearranging them as he likes it.

A similar concept has been used by Geoworks Ensemble 3.0 more than 10 years ago.

"The current strategy of simplifying the primary interface and stuffing all the rest into the gconf-editor is suboptimal."

This approach will make the UI less interesting for professionals who want to use it. On the other hand, even the simplest interface can be "misunderstood" if the (potential / novice) user is spoiled by strange and complicated concepts he might know from other desktop environments, usually from them manufactured by MICROS~1. :-)

"The user should be able to start out with a simple, reduced option interface. And then graduate to higher levels as their proficiency increases."

This is what made GeoWorks that appealing.

"I'm not confining my recommendation to Gnome, BTW. Gnome, KDE, and XFCE are all in a position to implement it.

First one that does will be a winner."

The first one was GeoWorks, as far as I know.. :-)

I really like this idea. It has been discussed to even to change the level dynamically. The system recognizes which options are used most times and places them in an obvious place. The disadvantage is a periodically changing UI which might cause problems...

Okay, just an idea. :-)

these 'complexity levels' have been discussed, and according to usability experts, they are one of the worst ideas imaginable. So it won't ever make it into KDE 4, and I guess the same goes for Gnome.

"""
and according to usability experts, they are one of the worst ideas imaginable
"""


Maybe I'm just wrong.

But I'd be interested in who these mysterious "usability experts" are, and why they think that dumping all the overflow into gconf-editor is superior to presenting various levels of options in a more organized fashion.

Are they licensed, and members of some accredited "Usability Experts' Association" or something?

Or do they just show up calling themselves usability experts?

Edited 2007-03-15 12:23

That reminds me of gnome 1.x... it didn't work because when someone asked a question on how to change one option that was in advanced mode, they would switch to the advanced settings and never switch back. Also, many users, especially those who want to try Linux, feel like they're advanced users, so they will enable that option. For the most part, options are either useful or they're really not, except for really, really advanced users who want to customize everything on their entire desktop. Being able to edit the menus everywhere might be helpful, but I think it would be a huge step back to have more then one set of defaults for beginner and expert and in between.

For the most part, options are either useful or they're really not, except for really, really advanced users who want to customize everything on their entire desktop.

I think there are two (three) kinds of options:

1. Basic, useful, used often. This is the usual stuff, the homepage of your webbrowser, font size etc.

2. Matter of taste, seldomly used but nevertheless useful. This is stuff you change once and then never again. e.g. I haven't touched much of my pretty extensive KDE customizations since the early 3.0beta days.

(3. Advanced system configuration stuff; used not too often, but it's nevertheless important to offer a graphic config tool for it. IME it's much easier to tell a non-expert over the phone how to change stuff in the third submenu, second tab, than to get them to open anything that looks like a command-line. For this kind of stuff gconf is sufficiently "GUIy", more buttons and less text wouldn't hurt though. =)

Imho, developers should try to split their options in categories 1 and 2, and put those in 2 in an "advanced tab", or in an advanced dialog (see advanced settings in the Windows display settings; I need them quite often, I'd be really pissed if I had to edit the registry for this kind of stuff, but I acknowledge that it's just too advanced to put it in the main dialog)

Another variant is the one oulined in this paper [1]

"The design includes two interfaces between which the user can easily toggle: (1) an interface personalized by the user containing desired features only, and (2) the default interface with all the standard features."

Instead of fixed interface "levels" you have the "personalized" level and the "kitchen sink" level. With an easy way to toggle features from the latter to show in the first.

[1] http://portal.acm.org/citation.cfm?doid=503376.503406

This hast discussed to death, you know?

(*shudders* another ghost of user interface past... )

Experience levels have been tried before and they have always failed and will always fail.

First of all, it's a hell to support. Have you ever worked on IT first level support? Even getting people trough "normal" configuration dialogs is a hell. Having multiple versions of configuration dialogs and trying to figure out, which version the user has active is so much, much, much worse.

The second issue is, that as soon someone doesn't find a configuration option for some exotic feature he would like the application to have, he (or she) will turn to the "Advanced" level. Noone ever uses the intermediate level configuration dialog.

Nautilus had such a thing years and years ago. It failed, is was removed. It's dead and burried, please leave it there; it's just where it belongs.

Or drag and drop the iso file to the cd burner place, and you will be asked if you want to write that as a disk with just one file that would be the iso file, or rather create a disk with the contents of the iso file.

It is a tricky question, but writing CDs is tricky; Gnome cannot assume you want to create a disk from the iso image, though that would be the most frequent choice by far. Maybe the burn button could directly create the disk from ISO asking no questions, while the file-burn command in the pull down menu could pop up a window offering more choice (as happens in many apps with the print button and the file-print option).

Thank you for the correction; I don't know why I was marked down given it was a genuine inquiry; the way I interpret 'write to cd' I assumed it meant just a straight copy to the cd of the file rather than the actualy image itself being used to create the cd.

For me, nautilus-burn really doesn't do it for me because you can't brn iso images - sure, I drop to command line and do it manually, but at the same time, I would have thought that along with packet based writing (treating a cd/dvd like any other storage), image writing would be quite important.

I don't know what Gnome release you're using, but here (2.16) when I double click on a iso file nautilus-cd-burner starts.

http://img134.imageshack.us/img134/5691/cdburnervm2.gif

Edited 2007-03-15 10:33

I consider nautilus-burn not usable for the following two reasons.

1.) you cannot write to multi-session CDs.

2.) you cannot erase CD-RWs.

You can do the number 2.

Packet writing is another sore point in linux.
This is so useful and convenient, I don't get why it's being so overlooked.

Anybody here brave enough to submit support for rw udf mounts to udev/volume manager?

The only thing I cannot understand is why isn't
mutisession support included.
I found nautilus burn to be most reliable gnome burner (probably it has interaction with gnome volume manager sorted out best) but lack of such basic functionality makes it useless for great part of users.
That's a shame, because having a one click burner would be very convenient.

gnomebaker rocks my world .

Why it's "faster" and has "better memory performance"? Not that I doubt it, the gnome guys have been improving that fields for a while and could very well have done the same in this release. But....

...but this time I can't see any performance/memory related items in the release notes! Are there any? Maybe 2.18 focused in features...

Edited 2007-03-14 23:06

"""faster, better memory performance, a worthy release."""

Now that they have a solid base, its nice to see a focus on efficiency. "Make it work... and then make it fast" and all that sort of rot.

I remember listening to a webcast in which a RedHat official mentioned that they expected Gnome to have a 1.0 release in "about a year".

It has been very gratifying to watch this project mature. Oh, they've stumbled and made a few mistakes. When they decided to be completely WM agnostic I cringed. When they decided to make Enlightenment's WM the standard I cringed even more. (Enlightenments WM wanted to be a DE in itself... and it showed.)

Then came Sawmill. Errm, excuse me, Sawfish (gotta love that one!).

And then the great simplification effort. Controversial, I know. But I think that it was a good move. It does make things easier for new users, and those who prefer to be confronted with more switches and dials have KDE, Ion, or whatever catches their fancy.

We've even been treated to Linus Torvalds displaying an all too human side... trolling the Gnome mailing lists... eventually even submitting patches, some of which were accepted, I think. Funny thing it was: Linus asking that his patches be accepted, and not any too politely. I'm in Oklahoma and he was in Oregon. But I swear I heard him grit his teeth! ;-)

I don't mean to detract from KDE, XFCE, or the WM/DE of your choice, here.

But I think that we can agree that the landscape is richer for the existence of this project.

"""
And to think, I just installed gnome-2.16 yesterday.
"""

The rest of us owe you a great debt of gratitude for "causing" this release.

It reminds me of the part in "Mostly Harmless" in which Tricia McMillan, anxiously waiting for a phone call, leaves her hotel room to go out to a movie specifically in order to make the phone ring. (It works.) ;-)

Maybe alive, but they didn't seem add much interesting. Tomboy's mono dependency is pretty much overkill for something as simple as note-taking - it's mostly on par with Knotes, but can't get close to Basket. Why all the resource use?

Anyway, the best improvement is the security/signing/encryption stuff, and in that area (typical) they're years behind KDE. Finally catching up...

Sorry, but why isn't gnome doing more? They had 2 years to get ahead of KDE, but still didn't manage to put out things that where slightly better than what they had. Except for the usability area, you can't argue gnome 2.18 is much better than KDE 3.5.x, and KDE 4 is coming in 8 months...

Anyway, the best improvement is the security/signing/encryption stuff, and in that area (typical) they're years behind KDE. Finally catching up...

That's not true. All of these were there since long, like Seahorse. They just were not officially part of Gnome, and some things didn't work well (like encrypting mails in Evolution)

Well, then, they are catching up. I've been encrypting my emails for years...

But you're right, I didn't know this app existed for a long time, so at least it's not that bad.

Sorry, but why isn't gnome doing more? They had 2 years to get ahead of KDE, but still didn't manage to put out things that where slightly better than what they had.

Let's see what the GNOME guys have been up to...

- dbus and HAL, which made several improvements to the user experience possible. For example...

- ...gnome-volume-manager (from Project Utopia), so USB and Firewire devices "Just Work". Went in on 2.8.

- NetworkManager, so WiFi "Just Works". Going in on 2.20.

- gnome-power-manager. A must have for laptop owners (does KDE have a proper HAL frontend for power mgmt yet, or is that also going to be a 4.0 feature?)

- Gstreamer and Totem. We know Gstreamer 0.10 was a major improvement, but things continue to get better with improvements pushed by projects like Jokosher. Totem 2.18 has a *much* improved browser plugin (openSUSE for instance shipped an early 2.17 release with their latest release). So, when you visit a site that has multimedia content, it "Just Works".

- Orca, a much improved screen reader, was introduced in 2.16.

- GNOME received a fresh look in the 2.x series, with Clearlooks (introduced in 2.12 and constantly tweaked to perfection) and the new icon theme (introduced in 2.16, and now much more complete with this release).

- Cairo. Version 1.4.0 came out just before GNOME 2.18 with major improvements. Of course, GNOME has been using Cairo since 2.12, and KDE will see something similar when KDE 4 is finally released.
Cairo has allowed several improvements on the user experience.

And cairo is by far not the only improvement to the platform. I didn't mention "Project Ridley", a refactor of the platform (without the downside of having to break compatibility again) that has already made GTK+ a much more powerful toolkit.

There's D-Bus, which is a project started and maintained mostly by GNOME devs and KDE will adopt when version 4 is eventually finished.

Nautilus and gnome-vfs have seen several bugfixes lately, and Alexander Larsson is already hacking gvfs, gnome-vfs's replacement (that will be integrated on glib). Emmanuele Bassi is hacking on the next-gen GConf.

And that's not to mention the improvements the GNOME platform receives from projects like Sugar (the OLPC GUI), Maemo (Nokia 770 and 800), OpenMoko (FIC Neo1973) and several others.

To me, it looks like the GNOME guys are working on fixing the problems and bugs people face when they actually use a GNOME based desktop, instead of rewriting code that works just for the fun of it.

- dbus and HAL, which made several improvements to the user experience possible. For example...

Yes, HAL is a godsend, and everyone benefits from that. dbus.. Well.. it's ok. It's good because its a standard, but from KDE's perspective, it's not significantly better than the dcop they already had.

- ...gnome-volume-manager (from Project Utopia), so USB and Firewire devices "Just Work". Went in on 2.8.

Yeah I love this feature. KDE has the equivalent, dunno what the name is though.

- NetworkManager, so WiFi "Just Works". Going in on 2.20.

Also, brilliant feature. Thank you to whoever came up with that. KNetworkmanager is a wicked frontend to it for KDE and it was one of the main reasons I can actually use linux on my laptop. Far better network handling than Windows now.

- gnome-power-manager. A must have for laptop owners (does KDE have a proper HAL frontend for power mgmt yet, or is that also going to be a 4.0 feature?)

There is none included in KDE yet, but KPowersave (0.7.2) does exactly that and works great. I'm not sure if it will be included in KDE 4 or what. I sure hope so. Either that or HAL support will be added to klaptopdaemon.

- Gstreamer and Totem. We know Gstreamer 0.10 was a major improvement, but things continue to get better with improvements pushed by projects like Jokosher. Totem 2.18 has a *much* improved browser plugin (openSUSE for instance shipped an early 2.17 release with their latest release). So, when you visit a site that has multimedia content, it "Just Works".

Not really a big fan of gstreamer. They like to break compatibility a lot, and the xine engine seems to cause a whole lot less issues every time I've tried it, and Codeine has taken over all my video player tasks.
http://kde-apps.org/content/show.php?content=17161

- Orca, a much improved screen reader, was introduced in 2.16.

This is important. KDE 3.x is lacking in the accessibility front. Gnome has been paving the way here with atk, and KDE will hopefully catch up with version 4.

- Cairo. Version 1.4.0 came out just before GNOME 2.18 with major improvements. Of course, GNOME has been using Cairo since 2.12, and KDE will see something similar when KDE 4 is finally released.

Shows promise, but it's still too slow.. 1.4 goes a way towards fixing that though.

To me, it looks like the GNOME guys are working on fixing the problems and bugs people face when they actually use a GNOME based desktop, instead of rewriting code that works just for the fun of it.

I assume that is a jab at KDE. But they're not rewriting code just for the fun of it. They're rewriting code to make writing the next generation of apps easy for developers. That is of _critical_ importance. Nothing is more important than providing a very advanced set of tools for application developers. That is what has allowed people to create amazing applications for KDE in a very short amount of time. With KDE 4, that will extend to Windows and Mac, and more people will have a chance to build on that platform.

And that's not to mention the improvements the GNOME platform receives from projects like Sugar (the OLPC GUI), Maemo (Nokia 770 and 800), OpenMoko (FIC Neo1973) and several others.

Do you have something particular in mind. (no offense, just asking).

Memory reduction, for starters.

Sorry, but why isn't gnome doing more? They had 2 years to get ahead of KDE, but still didn't manage to put out things that where slightly better than what they had. Except for the usability area, you can't argue gnome 2.18 is much better than KDE 3.5.x, and KDE 4 is coming in 8 months.

Welcome Ladies and Gentlemen to today's 2254th Linux-DE-Genital-Size-Comparison-Masters.
For 50 comments it looked like today's championship game would have to be called off due to a lack of trolling, but thankfully a last minute intervention by superstoned rectified that problem and now we're good to go...

Honestly, was this really necessary?

lol... OK, maybe I shouldn't have done that... Sometimes it's hard to resist saying what you think, you know. I really thought the release notes where pretty dull (and I understand they should've mentioned performance improvements everywhere).

I voted you up, btw.

I totally agree! I find this the most annoying bug in Gnome.

No, it's still there. Have you filed a bug report? Although I am not convinced that this is a bug, but a wanted behavior by the developers.

This is an acknowledged bug in libwnck with many duplicates. It takes so long because the Gnome folks are pondering how to fix it The Right Way(TM). Though I personally think that the patch should be dead simple (set a fixed button size, possibly depending on screen resolution). Somewhere there even is a patched libwnck .deb for Edgy that has this annoyance fixed.

I just tried out fiesty Herd5 live CD and it seemed to be fixed in that. :-) I am guessing ubuntu has patched this and not actually fixed in Gnome.

Edited 2007-03-15 00:29

Then I might not have understood correctly the first comment above. My firefox entry in the taskbar still resizes depending on the Title size.

It takes so long because the Gnome folks are pondering how to fix it The Right Way(TM).

Set a maximum button width based on the width of the taskbar widget such that a user-configurable whole number of buttons fits in the taskbar at this maximum width. If the number of buttons is higher than this threshold, each button is sized such that they all have the same width. Button width is only recalculated when adding or deleting buttons from the taskbar or resizing the taskbar.

That seems like reasonable and pretty simple behavior to me, but then again, my GUI programming experience isn't very extensive.

There is not much to say, so no blog post. The last few releases had very minor new things in them in terms of user features (gtk# inclusion was big, but is not a user feature for example).

What are they waiting for, then? Except for usability, they're still playing catch-up to KDE 3.5, and 4.0 is coming. There are external projects offering things like compiz and beagle, but they still aren't part of gnome. Well, tracker will be, for 2.20, that's a good thing. But will that be enough? I don't see them adding grammar & style checking, or any 'next generation desktop' stuff.

I loved the Lisa screenshots some time ago, they showed how the desktop indeed hasn't changed since 1985... And I really miss the ambition at Gnome. I won't use it, of course, big KDE fan, but KDE will need some real competition on the free desktop, and as far as I can see, Gnome won't be it... Maybe Enlightenment, but they've been in alpha for ages.

It probably won't matter how good gnome is or not, the big distro's are so entrenched, they'll deliver it as their desktop, even though they won't ever get ahead on MS that way. But it's limiting for the average Linux user, imho.

I loved the Lisa screenshots some time ago, they showed how the desktop indeed hasn't changed since 1985... And I really miss the ambition at Gnome.

What's the point of completely changing the desktop when you can't even use WiFi without hassle?

And by the way, desktop experimentation is not something you'll see on an official GNOME release, but rather on related projects like Gimmie, Avant, Sugar, etc.

A big difference between GNOME and KDE is that these experiments are done in parallel in GNOME. For example, the KDE panel is pretty much dead, with "Plasma" set to replace it. But people still have no idea what Plasma will look like and whether it will work (and they won't know until they test it on real people).

On the other hand, the GNOME project will only decide to replace its panel (which has problems, but works) with something else after a new candidate has seen testing. That's how metacity replaced sawfish in GNOME 2.2, for example. And there are people working on ambitious new ideas, as I mentioned above (the GNOME-based "Sugar" UI is definitely the most ambitious one today).

KDE 4 is very broken today (is pre-alpha the official definition?). GNOME will most likely never be in that state again.

KDE 4 is very broken today (is pre-alpha the official definition?). GNOME will most likely never be in that state again.

So you're saying the system architecture of Gnome 2.x is the ultimate possible, and will never need to change? Sorry, but if you want to make something better in a fundamental way, you have to break it first. Either that or create a lot of compatibility layers to keep the old API, and only Microsoft has the resources to do that.

So you're saying the system architecture of Gnome 2.x is the ultimate possible, and will never need to change? Sorry, but if you want to make something better in a fundamental way, you have to break it first. Either that or create a lot of compatibility layers to keep the old API, and only Microsoft has the resources to do that.

That's not exactly what I'm saying. GNOME will replace components of the platform, but without breaking the entire stack while they're at it. In fact, it's been doing that for a long while now (see Project Ridley, D-Bus, gvfs).

The D-Bus adoption is a perfect example. GNOME adopted D-Bus without breaking anything.

gnome-vfs is not perfect and will be replaced by gvfs, which is being developed. But GNOME will not depend on gvfs until it's ready; that's the main difference in strategy between the current development model of KDE and GNOME. KDE decided to fix its entire platform in one go, while GNOME is incrementally replacing components as the next generation ones are completed and ready to go.

Of course, supporting gnome-vfs and gvfs, ORBit/Bonobo and D-Bus, etc, is not a lifetime solution, which is why the old libraries will eventually become unsupported and the platform released as version 3.0.

Btw, GTK+ adopted Cairo without having to break its API, but that's because GTK+ was well designed to begin with.

The D-Bus adoption is a perfect example. GNOME adopted D-Bus without breaking anything.

Yes, this worked because Gnome didn't have an equivalent to d-bus before d-bus came along. You can add a feature without breaking anything quite easily. In fact, KDE did the exact same thing. Some components of KDE in the 3.5 series use d-bus, and it didn't require any major changes.

What KDE is doing in version 4 is quite different. They are _replacing_ their dcop implementation with d-bus. This requires breakage. Sure, they could just add d-bus support and keep dcop as well, but now you're dragging along two IPC frameworks that you have to maintain, and expose interfaces to, and load into memory. From a development standpoint, it is far better to migrate to the new framework and drop the old one.

gnome-vfs is not perfect and will be replaced by gvfs, which is being developed. But GNOME will not depend on gvfs until it's ready; that's the main difference in strategy between the current development model of KDE and GNOME.

Since when does KDE depend on technologies that aren't ready? KDE 4 is a development version, just like the next development version of Gnome will depend on technologies that are not currently ready. They will be ready on release date.

Of course, supporting gnome-vfs and gvfs, ORBit/Bonobo and D-Bus, etc, is not a lifetime solution, which is why the old libraries will eventually become unsupported and the platform released as version 3.0.

Bingo. And this will cause breakage. So how is this different from the KDE 4 situation? The only difference is that the decision to break compatibility comes at a different point.

Hoping to see a relevant system update come in,
on my Ubuntu drive, sometime soon.

Not going to happen. You will only see Gnome 2.18 in 7.04/Feisty. The entire release schedule of Ubuntu is based off the Gnome release schedule - in other words, every new Gnome will only be in the Ubuntu release that follows it up a month later.

Linus submitted his patches after feature freeze. They will be in the next release

Debian have an outdated desktop ?
Nah...

Debian's focus is on stability, not the latest and greatest.

So, the majority of Debian users are extremely happy it will have an "outdated desktop"

Maybe they should base gnome's VFS on Fuse, so that all the virtual new paths and units would be visible to any app, even console apps, with no need for trekking all over the filing system.

They should replace gnomeVFS and kio-slaves with a unified, DBUS based protocol for accessing stuff (many of the more useful things you can do with a VFS need more information than is available through basic file operations; for example streaming content vs. copying it; should the backend keep a resource mounted, for how long etc.), that uses a Fuse (or something similar) backend for virtual mounts, that are accessible by all programs.

Ideally, the backend would be split up in a provider that does the mounting and plugins that access the data source; those plugins could be written in any language (otherwise you'd be losing half your developers) and could more easily do some funky data mining (e.g. a plugin that runs an html parser and takes a webpage -let's say osnews.com- as source, puts the text of the page in a file but also provides every link as a subdirectory -in this case the directory osnews.com would have a text.html file and a bunch of subdirs, one of them called "GNOME 2.18 Released").

I agree with this, FUSE would seem to fix a lot of annoying problems with gnomevfs.

No, it wouldn't.

gnome-vfs is a framework that goes far beyond the capabilties of FUSE. FUSE doesn't use asynchron operations, for a start.

The use of FUSE in gnome-vfs, it's merits and drawbacks has been discussed over and over again in the gnome-vfs-list.

On a different topic, has anyone realized why Gnome and KDE are so differnt? It really is because of the engine. KDE started out with an existing engine.

While clearly Qt and GTK are differentiators, I think the difference runs much deeper than that, into actual development philosophies.

For instance, take your previous point:

What a enterprising developer needs to do is create a system wide plugin infrastructure that could make the plugin available to all of the applications. The developer of the plugin could decide the rest.

Substitute plugin infrastructure for component framework, which is what you were basically implying, and you've essentially described KDE.

KDE stresses the developmental advantage of having reuseable components for consistency and ease-of-development. Build protocol handling into the core so that any KDE application can deal with it transparently by simply accessing the file picker. Build functionality into kparts so that things like document viewing are not only simplified for the OS, but can easily be embedded into applications. Etc.

KDE 4 takes it further by wrapping interface translation layers around things like hardware access or multimedia functions to isolate application developers from having to code for or even deal with the underlying OS/system framework. When Amarok began porting to KDE4, they were able to incorporate video playback capability from phonon by simply adding 7 lines of code. That's the type of rich application development environment the KDE devs are aiming for, one that provides a powerful, easy-to-develop tool for the app developers while providing a powerful, consistent application interface for users.

One could argue that maybe KDE takes abstraction to an extreme level, but I would disagree. It's often dismissed as bloat or complexity by KDE detractors, but I wouldn't necessarily consider an extensible framework to be bloat if it leads to easier app development. That abstraction approach is also leading to application portability among OS-platforms, and from an efficiency point-of-view it strikes me that if you load up a KDE environment with several KDE applications versus a Gnome environment with several equivalent Gtk applications, you will see a significant difference in resource utilization, in KDE's favor.

Gnome exemplifies the Unix philosophy of one tool - one job, do it the best that you can. There's nothing wrong with that in principle. And many people will prefer the simplicity of Gnome and it's predetermined settings. But at the same time I would consider things like frameworks to be tools as well, and I sometimes think that automatically labeling components or features as bloat simply because it doesn't provide a direct, short-term benefit is short-sighted. Gnome is fine as a DE, but frankly I consider DE to be a bit of a stretch, it really aims to be more of a comprehensive window manager. I don't see any of the application integration or interoperability that one would expect from a comprehensive desktop environment, it just strikes me as a configurable interface for running Gtk-based apps, but then in fairness I don't really use Gnome that often and my preferences are certainly different from everyone else's.

I think it's good that KDE and Gnome are stretching themselves in their philosophical directions, as long as interoperability doesn't take the hit. As long as KDE/Qt apps run fine in Gnome and Gnome/Gtk apps run fine in KDE, everybody wins because users *and* developers will always have their choice of preferred tools.

Just my 2c...

I do agree. What you are speaking of is easily one of the best things about KDE. From a develoment perspective KDE is easier to create applications with. That is what gnome was trying to do with Bonobo but... oh well.

But the problem is that those ideas need to come out in the user interface as well. I would be floored if KDE came out with a more simplistic interface but with the ability to insert system wide pluggins/components.

Look at what the model has done for firefox. Firefox starts out very simple. But I can add web development tools, ad blocking, tab customizations, I can even add audio controls. Now think of that on a large scale.

Ex