GNOME hacker Seth Nickell has written a lengthy PDF and accompanying blog post with a number of very interesting ideas for GNOME 3.0. I pondered putting this up on the front page, but since that usually only attracts the "It's not what I'm used to so it sucks"-crowd, I decided to put it up here. Be sure to read the blog post, the PDF, and the comments on the blog post to get the entire picture.

They sure have thrown around a whole bunch of creativity with their plans for Gnome 3. Like for example the fixed location of things, as they themselves noticed, helps develop muscle memory and as such the more you use GNOME3 the smoother the ride becomes.

But I personally liked the most their plan of allowing you to just drag a whole workspace into 'Pooper' so you can work on it some other day, with all the window contents and data still intact. It's gonna be such a killer feature. Unfortunately they're not apparently going to get it working for GNOME 3.0, but I hope it's not going to be delayed for long.

It's not mentioned in the blog post or the PDF but they're also working on getting off-screen rendering working in GTK+ so you can finally have fluid and rich animations wherever you need them. Well, ABOUT EFFING TIME!

Ps. read the PDF. It's atleast somewhat more coherent than his blog post.

The Task Pooper concept looks like an evolved (drag animation) of the workspaces concept (IIRC the name) of OS/2 Workplace Shell (WPS)

WPS folders had a setting that made the it work like the real folder, if you have open documents when that folder is closed, all documents were saved and closed simultaneously, the next time you open the folder the previous state is restored and all documents previously open are reopened

But I personally liked the most their plan of allowing you to just drag a whole workspace into 'Pooper' so you can work on it some other day, with all the window contents and data still intact. It's gonna be such a killer feature.

Agreed, assuming it actually works as they expect it to. It's such a new concept that I think it will take a *lot* of user testing and tweaking to make something that is really as awesome as they are hoping. If they just build it and foist it on users based on their own assessments of "what's right", without first doing a lot of iterative testing and redesign to make sure it really is right, it will probably die a slow, horrible death.

I am however very skeptical about the touchpad-corners idea. Even on my ginormous unibody-Macbook trackpad, I still don't really like the idea of parts of it being off-limits. It just seems like it would be too error-prone. Again this is of course something that needs to be tested a lot, maybe it would work better than expected after all and have a huge fan base--but it still strikes me as something that should be disabled by default.

On the whole it is good to see the Gnome 3 team focusing on UI first before they start hacking away... It tells me that something is finally right in the world.

I am however very skeptical about the touchpad-corners idea. Even on my ginormous unibody-Macbook trackpad, I still don't really like the idea of parts of it being off-limits. It just seems like it would be too error-prone. Again this is of course something that needs to be tested a lot, maybe it would work better than expected after all and have a huge fan base--but it still strikes me as something that should be disabled by default.

I'd assume it's off by default and that you can enable/disable all four corner separately as you wish. But you know, those corners aren't really off-limits; while I still had a laptop I had lower right corner function as a right-click. Just one tap there and POOF, right-click. But you could still drag to and from that corner without doing a right-click and as such it wasn't off-limits or hindered the use of it in any way.

But I personally liked the most their plan of allowing you to just drag a whole workspace into 'Pooper' so you can work on it some other day, with all the window contents and data still intact. It's gonna be such a killer feature.

With the exception of the explicit save function, this is not really something new. I have used this for years, and pretty much have my usage pattern adapted to it. I simply newer close an applications when I still work on stuff, I let the session handling of the desktop take care of it. And it restores the state of my desktops and applications the next time I log in.

One of my PCs at work have one desktop containing a set of Konsole windows, filemanager views, webpages and text files in editors. The application set have been more or less in a permanent state for over 2 years(with countless logouts), but with everything at the ready when I need to work on the project.

This guy have some nice ideas. What I liked is that he is focused on the goals of the user, not on creating stuff for the sake of creating stuff like people on kde4 and gnome-shell...

By the way, there's a whole methodology of creating products focusing on goals. It's called Goal Oriented Design, and I think OSS people should start using immediately if they want to stay competitive..

Goal oriented design is a good option and if they stick to it they'll end up with something nice.

However, that doesn't meant that anything else is crap. KDE4 was not creating stuff for the sake of creating stuff. Their goal, as I saw it anyways, was to provide a platform for a user to accomplish their work in what ever fashion they found easiest. Comparing the two is like comparing the objective C language to AppleScript. Objective C doesn't suck because it requires some skill to start itunes and tell it to play a song as opposed to:

So they aren't really forcing users, because they are using the users' own ideas. Anyways, choice isn't generally a good thing. It's only necessary when the developers can't make a good interface, so need the user to do the last leg of work to get the software working correctly. Every checkbox is a failure on the part of the developer.

As a power users, I don't use a computer like a new comer. I use advanced features such as KPart/KIO and custom action menu scripts, tiling windows managing, d-bus script to connect my desktop to my apps, windows placement rules, chopped down UI to have more working space (i use only keyboard shortcut) and many other aspects. Give this to a non-technical person and he/she will be unable to do something with it. Give me a UI with 7 toolbar on the top, a status bar and pane on each side (like MS Visual Studio) and I will cry.

KDE allow me to tweak apps for my taste, and my tastes are unique. One UI can't fit all cases, you have to add some configurability to it.

Yeah, and extremists are idiots. Even computers haven't been seeing the world that black and white for about three decades now. Add at least some shades of gray into your head. It has 'gray' matter for a reason, you know.

Apple... At least they do user research before assuming what the users want in the first place...

No. They most certainly do not do field research, especially when it comes to usability.

What kind of research did Apple do to allow the round mouse, or to withhold for decades more than one button on a mouse?

Furthermore, what kind of research did Apple conduct to bring us:
- window buttons so tiny that it takes slow, methodical attempts to actually click on one;
- programs that don't really close when one closes the program's window;
- the perfectly "intuitive" model/metaphor of trashing drives to unmount and/or remove media;
- monitors that can't tilt downward;
- use of sub-keypads on touchscreen devices, so that one has to navigate through several screens and tap 9 times just to type something as simple as an ellipsis ("...");
- the lack of cut-and-paste;
- critical buttons and access ports hidden on hardware;
- magsafe connectors that overheat and catch fire ("mag-safe" connectors that were in use before they were adopted by Apple didn't have this problem);
- the list goes on...

Apple has consistently put "style" (and the designer's ego) over the user's needs, and Apple has frequently rushed products to market that other manufacturers would take a lot more time to perfect.

First of all, EVERY f--kING OS/DE does in one way or another enforce their own view of how you should use the computer, that's the whole point of it; if all worked exactly the same there'd be no point in even having more than one single OS and DE. Some focus on presentation of the filesystem as abstract objects, some focus on actual filesystem layout, some focus rather on presentation and manipulation of windows contents etc. Claiming that GNOME does try to make you do things in a certain way and that f.ex. OSX or KDE4 doesn't is utter bull; they all do it in their own ways.

Secondly, exactly how does these planned features hinder you from doing what you wish? All of them allow you to do the same thing as before, just in a slightly different way and providing ways of planning your actions over several days. Most of them are even customizable or can be disabled.

First of all, EVERY f--kING OS/DE does in one way or another enforce their own view of how you should use the computer, that's the whole point of it; if all worked exactly the same there'd be no point in even having more than one single OS and DE. Some focus on presentation of the filesystem as abstract objects, some focus on actual filesystem layout, some focus rather on presentation and manipulation of windows contents etc. Claiming that GNOME does try to make you do things in a certain way and that f.ex. OSX or KDE4 doesn't is utter bull; they all do it in their own ways.

Secondly, exactly how does these planned features hinder you from doing what you wish? All of them allow you to do the same thing as before, just in a slightly different way and providing ways of planning your actions over several days. Most of them are even customizable or can be disabled.

While I do agree with you to some extent, it is important to point out that KDE goes a great length to ensure that the computer works the way you want and not the other way around. KDE 3 even more so than KDE 4 obviously, but KDE 4 is getting there.

You can change keystrokes, toolbars, default applications and with Plasma even the desktop itself - making it look and behave like other OS/DE if that is what floats your boat - so it is somewhat incorrect to state that KDE "forces" you to do anything. For example, I change most KDE/Qt applications' "Refresh" keystrokes - when that applies, of course - to F5 to match my old habit of pressing F5 to refresh web browsers while some people that I know prefer to press Ctrl+R. Neither Windows nor Mac OS X can claim such levels of flexibility.

On the other hand, GNOME tries REALLY hard to enforce its developers' vision on to your usage pattern. I guess that it works for some people but I'd rather have something that I can shape and mold to work the way I want or that fits my workflow better and not the other way around - reasonable defaults notwithstanding - so the parent poster's point still stands.

On the other hand, GNOME tries REALLY hard to enforce its developers' vision on to your usage pattern

I'd say that is a point of view: atleast I find my GNOME desktop customizable enough and not forcing me to do things in some specific way. It would be forcing if you weren't allowed to change anything, but you are and as such the point is moot.

Of course KDE4 is more customizable than GNOME, but it doesn't mean GNOME is forcing things on you either: if not having every possible imaginable option available means you are being forced to work one way or another then KDE4 would be forcing too; it just doesn't have every possible imaginable option either.

Besides, these are all just semantics; GNOME3 hasn't been released even as an RC and no one can yet say whether it'll be any good or not.

Yes, some people prefer something they can mould according to their own tastes, others prefer something that just works out of the box and is reasonably rigid. For me personally, the value of customisability in itself is pretty much non-existant.

This is also a case of giving choice. In our world, ultimate customisability is always guaranteed on the source code level. Beyond that, requirements differ.

I´ve been a Gnome user for a decade in my embedded programming career, and I really think it´s a great GUI (Especially the fantastic Gnome Terminal!).

The PDF was about the GUI, but what I´m interested in for Gnome 3 is if there is any plan for anything else than storing files locally.

In the Chrome platform, the client is state-less, and the user content is online (On servers of the new Monopoly of course, but safe) all the time.

Right now, I only see the following options:
- The old file-system-world, I have a local or a shared file system that I or someone else backup where I store my user data.
- The new online-world, a company (Google, Apple/mobile-me) keeps my user-data online and backup.

I would like Gnome and/or KDE to make an interface that makes it possible to implement local applications that stores my user-data on a server, and also handle the offline access by some kind of cache.

In short, make it possible for applications *and* server:s to be implemented with a non-company proprietary protocol/interface/implementation that makes it possible for me and possibly some friends to either setup this server myself, or share it with friends and implement applications/services corresponding to gmail/google docs with a local GUI but online or cache:ed encrypted data.

Until it is possible to setup a non-commercial cloud with an Application interface towards this, GUI updates are not that interesting to me. The trend from company-owns-your-content nice 24 hours available Web app:s will not be changed by a nicer GUI.

Now surprise me and tell me that this is also happening in some project! Perhaps there is a corresponding new driven De Icaza pointing at Google instead of Microsoft out there...

I would like Gnome and/or KDE to make an interface that makes it possible to implement local applications that stores my user-data on a server, and also handle the offline access by some kind of cache.

Gvfs allows you to read and write to files on local system just as easily as it allows you to do it on remote systems, and it supports quite a few different protocols too: I am atleast aware of SFTP, FTP, Samba, NFS and Gmail (you need to install the appropriate plugin).

If you are writing an application of your own why not just tap into Gvfs and save the files remotely yourself?

In short, make it possible for applications *and* server:s to be implemented with a non-company proprietary protocol/interface/implementation that makes it possible for me and possibly some friends to either setup this server myself

SSH (SFTP) server works as a file-server just fine and has even the added bonus of transferring everything encrypted.

Qt is the better toolkit and everyone knows it. The plug needs to be pulled on GTK and we all know what is keeping it alive.

What's keeping GTK alive is that literally thousands of applications depend on it, including, but not limited to, the GNOME DE. There are reasons to choose GTK over QT for programmers who are not targeting GNOME. Maybe because their app is written in C and easier to bind to the language they use. Perhaps it is because GTK is just a toolkit and a lot slimmer than QT. Maybe they just prefer the look and feel of GTK.

No "binding" is needed to use C code from C++. All you need is a good ol' linker. Most C programs can be compiled with C++ compiler, even.

I actually edited that part into incoherence. What I meant to say is that if your program is written in another language it is easier to use a C based toolkit, especially when QT is so much more than just a toolkit and GTK works well with other GNOME and non-GNOME C libraries that are easier to interface with other languages than C++.

I doubt developers really care about this kind of "slimness", being that Gtk+ apps mostly target desktop computers.

Actually people do care because GTK+ is used in the mobile space and mobile embedded platforms are becoming increasingly important.

I actually edited that part into incoherence. What I meant to say is that if your program is written in another language it is easier to use a C based toolkit, especially when QT is so much more than just a toolkit and GTK works well with other GNOME and non-GNOME C libraries that are easier to interface with other languages than C++.

Qt have as much binding as Gnome, including C#, Php, Perl, Java (dieing, but still working), Python, ruby, JavaScript/HTML, OBJ C (not sure how compatible, I did not tested). It will also work with C and lua-c. You can write in pretty much everything GTK support.

Qt have as much binding as Gnome, including C#, Php, Perl, Java (dieing, but still working), Python, ruby, JavaScript/HTML, OBJ C (not sure how compatible, I did not tested). It will also work with C and lua-c. You can write in pretty much everything GTK support.

The C++ object system is not very compatible with other languages. That is one of the main reasons that GNOME is a C based project. Sure you can get other languages to work with QT but it is much messier. Some people just prefer GTK+ because it is a much cleaner interface for non C++ code.

I don't think your point is valid, please give details, because I am an experienced programmer and to me, C++ is as compatible as C. Binding take little work for functional languages, but otherwise, it work quite well.

If you read the developer docs for GNOME the reason they chose C for GNOME and GTK+ is because the C++ object system is not as runtime-centric as the one created for GTK+. GTK+ makes binding to interpreted languages much smoother. For QT you need MOC, which just sucks if you're a C++ programmer that isn't already familiar with QT. You would be better off with GTKmm than QT if you like to program in C++. It may not be an issue for you but a lot of people really hate MOC, mostly because it is a non-C++ way of doing things.

The main reason to use GTK is the GNOME userbase. It isn't because of technical proficiency.

I guess you just aren't that familiar with the desktop linux then. As I have repeated many times (and you have ignored) there are far more GTK+ applications that have no connection to GNOME than their are GNOME apps. If you think all of them are just going to switch to QT then you're not using your head.

First, it is Qt, not QT. And your point is not valid once again. It is not because a GTK app does not link to gnomelib that it is not intended for Gnome. Gnomelib does not add that much to GTK experiences, and make the startup faster, so I wouldn't use them, even if I were targering Gnome. KDElibs add a little more to Qt, than gnomelib does to gnome. It is much more than a registery system a default directories. It add KXMLGui, making apps customizable. It is mostly why much Qt app use KDElibs in Linux (even if they don't in other pleteoform).

What? So now you KNOW that GTK+ apps were intended only to blend in with GNOME and not because they chose to use the GTK+ toolkit over QT for other reasons? That's just silly. You don't know that more than anyone else knows or doesn't know that. What I do know is that XFCE apps are GTK+ and that there are quite a few other GTK+ apps out there not intended for only GNOME desktops.

I'm quite aware of desktop Linux and how GTK apps look like ass in KDE.

If the major distros switched to KDE then those GTK apps would be re-written or eventually phased out.

I'm also aware that Qt is leagues ahead of GTK, especially when it comes to cross-platform development. That gap will continue to expand as Qt is better financed.

There are more GTK apps but Qt has advantages that will favor it in the long term. We'll see more open source projects that primarily target Windows + OSX with Qt and integrate with KDE as a bonus. Qt will gain further support as GTK stagnates.

Leagues ahead in what respect exactly? You have to take into account that they have very different goals and design; Qt is intended to be a full suite including I/O operations and all, GTK+ is only a GUI toolkit, nothing more. As such they cater to very different needs and have very very different set of features.

If the major distros switched to KDE then those GTK apps would be re-written or eventually phased out.

Most developers develop to scratch an itch: if the itch is to code GTK+ apps then it doesn't matter no matter what DE major distros use. They'll still code for GTK+. KDE4 doesn't suit everyone and many people even very much dislike it altogether, and as such there'll always be use for other DEs and other toolkits. Qt might gain more traction if there came up another Qt-based DE as long as it didn't resemble KDE4, but atleast I am not aware of any other Qt-based DE.

I'm quite aware of desktop Linux and how GTK apps look like ass in KDE.

And I'm aware of how bad QT apps look in GNOME. So what?

If the major distros switched to KDE then those GTK apps would be re-written or eventually phased out.

What's your point? That's a giant if. First of all it's not like KDE is the only other option. Second it's an entirely unlikely proposition. Even if it did happen you would still have tons of GTK+ apps. QT is not a drop-in replacement.

I'm also aware that Qt is leagues ahead of GTK, especially when it comes to cross-platform development. That gap will continue to expand as Qt is better financed.

Really? You're aware that it is leagues better? How so? Not everyone is writing cross platform apps. To say that it is better financed is also just ignorant. GNOME is the standard desktop on most commercial distributions. Paid developers work on GNOME, including GTK+.

There are more GTK apps but Qt has advantages that will favor it in the long term. We'll see more open source projects that primarily target Windows + OSX with Qt and integrate with KDE as a bonus. Qt will gain further support as GTK stagnates.

This is the same wishful thinking that people have been using since GTK+'s inception. It hasn't happened yet and GTK+ and GNOME have only gotten stronger.

Maybe because their app is written in C and easier to bind to the language they use.

Actually I think the fact that the Gnome desktop is written in C is one of the main barriers to rapid development. If they were to use just about any other language--my top vote would be for Vala, followed by C++, C# or Java--there is no question in my mind that the speed of development of the Gnome desktop would explode. But sadly I think most of the Gnome hackers are still too much stuck in their "hacker" mentality, with their vi, emacs and what have you, to realize the benefit that a truly object-oriented platform with a full-featured IDE/toolset could bring....

While I'm a KDE Plasma user, I welcome any advancement in the FOSS ford, no matter which toolkit is used.
However, below the surface of GNOME's popularity GNOME is sadly a battleground for corporate agendas.

Novell decided to focus their corporate money-making on Mono. Therefore the former Ximian devs try to push Mono into GNOME.
OTOH Red Hat focuses on Java, especially after the takeover of JBoss. While Red Hat does not try to push Java into GNOME, they see Novell and Mono as a competitor and want to leave it out of GNOME.
And on top of that, there's also very often an anti-C++ spirit, leaving gtkmm at a marginalized position.

The victim seems to be GTK.
Instead of putting development resources into GTK itself, they are drained, because
1. everything seems to be needed developed twice -- one time using Mono, then without Mono
and 2. other GTK contributors seem to be fed up with Red Hat's and Novell's corporate agendas. Nokia and Intel were both GTK contributors in the past, now both turned to Qt (Nokia when they decided to buy Trolltech and now together with Intel in the MeeGo project).

I also liked the paper. The ideas are fairly new and fresh and could be really useful. But I think they are still geared towards advanced users (all the craftsman talk)
I want mouse velocity in KDE!!

On the issues you raised: Yes I think Novell wants to push Mono, I don't think RH wants to push Java into Gnome though, but the C++ thing is true.

I really wish they would push Vala with Gnome3.0. Make it the preferred language and built bigger apps in it. C# and Java devs could easily learn Vala and I think C devs will like the higher productivity.

One more thing:
OSnews is cool. While people on Ars/LWN are mostly bickering about the "task pooper" name here on OSnews there are good points in the comments. Submitting was worth it.

C cannot continue to be the answer for the next generation of apps. Writing GObject code in C is a humungous kludge. Vala makes it pretty and elegant again, while using a very Java/C#-similar syntax and adding all kinds of niceties from the C# world like properties. It's just freaking awesome. If Gnome were to start over in Vala, I think the existing developers would not only be much more productive themselves, but they would get a lot more support from third-party contributors as well.

I see a lot of neat ideas floating around with GNOME for version 3.0 but there is just one problem. As a GNOME user I like my current GNOME w/ Compiz setup. If GNOME plans on uprooting a lot of people from their current desktop habits the changes they make better be flawless. Even if the new interface is superior it is still not an easy transition for people who have been depending on certain behaviors for years. I have a kind of nervous anticipation for GNOME 3.0. I can't wait to check out the new features but I also dread losing things that are important to me.

Yep, totally understandable fear. After all, I still far prefer KDE 3 to KDE 4, and I used to be one of the biggest fans of KDE 4 before it was actually released...

At the same time though at least it can be said for the Gnome devs that they are starting out by rethinking the interface... The KDE devs mainly focused on rethinking the technology while leaving the interface an afterthought... and what they got was basically the KDE 3 interface all over again, just done worse...