The GNOME Roadmap

glockenspieler writes "Recently on the the Gnome Foundation mailing list, Dave Camp posted a draft Gnome Roadmap for versions 2.8 and Beyond. Issues up for discussion are Mozilla/Epiphany, incorportation of peer to peer filesharing, blogging, addition of more media widgets, and many others. Time for Gnome users to weigh in on what improvements that you would like to see. If that's not enough, then there's always the the C# versus Java versus ? discussion."

Re:how about

[Harbinjer]

Gnome is NOT a windowmanager. Its a desktop environment. If all you want is a window manager, use IceWM, Blackbox, ION, or(heck, why not) rat poison. I would've suggested Enlightenment, but that is growing beyond a windowmanager if I understand thngs correctly.

You have heard of gdesklets, right?

[djeca]

oh, and 4 should be possible with Cairo and the new X servers. 2 sounds interesting, but I don't agree with 1 and 3.

Re:They should stick with C

[rmull]

extern "C" {
.
.
.
}

Re:Don't SCREW the EXPERT

[starnix]

Um... Rightclick the menu and all your menu editing functions are right there. Not a folder view like Windows but quite easy. Also if you want a folder view enter "Applications:" into a nautilus window and bam, you have a folder view to use to edit menus. Just because you haven't figured it out doesn't mean its not there. Read the user manual.

The GNOME NO Roadmap

[Anonymous Coward]

That's quite an facile editorial but you can't expect better from normal users. My screenshot looks better than yours. Evolution is better than KMail, GNOME looks more polished than KDE and so on. I do use XChat, Abiword, Rhythmbox.... ...usually you get stuff like these from normal users. And this is ok since you can't blame them for stuff they simply don't know about or don't have a slighest knowledge about.

Such editorials are hard to take serious since they are build up on basicly NO deeper knowledge of the matter. Most people I met so far are full of prejudices and seek for excuses or explaination why they prefer the one over the other while in reality they have no slightest clue on what parameters they compare the things.

If people do like the gance ICONS over the functionality then it's quite ok but that's absolutely NO framework to do such comparisons.

I do come from the GNOME architecture and spent the last 5 years on it. I also spent a lot of time (nearly 1 year now if I sum everything up) on KDE 3.x architecture including the latest KDE 3.2 (please note I still do use GNOME and I am up to CVS 2.6 release myself).

Although calling myself a GNOME vetaran I am also not shy to criticise GNOME and I do this in the public as well. Ok I got told from a couple of people if I don't like GNOME that I simply should switch and so on. But these are usually people who have a tunnelview and do not want to see or understand the problems around GNOME.

Speaking as a developer with nearly 23years of programming skills on my back I can tell you that GNOME may look polished on the first view but on the second view it isn't.

Technically GNOME is quite a messy architecture with a lot of unfinished, half polished and half working stuff inside. Given here are examples like broken gnome-vfs, half implementations of things (GStreamer still half implemented into GNOME (if you can call it an implementation at all)) rapid changes of things that make it hard for developers to catch up and a never ending bughunting. While it is questionable if some stuff can simply be fixed with patches while it's more required to publicly talk about the Framework itself.

Sure GNOME will become better but the time developers spent fixing all the stuff is the time that speaks for KDE to really improve it with needed features. We here on GNOME are only walking in the circle but don't have a real progress in true usability (not that farce people talk to one person and then to the next). Real usability here is using the features provided by the architecture that is when I as scientists want to do UML stuff that I seriously find an application written for that framework that can do it. When I eye over to the KDE architecture then as strange it sounds I do find more of these needed tools than I can find on GNOME. This can be continued in many areas where I find more scientific Software to do my work and Software that works reliable and not crash or misbehave or behave unexpected.

Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.

We still have many issues on GNOME which are Framework related. We now got the new Fileselector but yet they still act differently in each app. Some still have the old Fileselector, some the new Fileselector, some appearance of new Fileselectors are differently than in other apps that use the new Fileselector code and so on. When people talk about polish and consistency, then I like to ask what kind of consistency and polish is this ? We still have a couple of different ways to open Window in GNOME.

- GTK-Application-Window,
- BonoboUI Window,
- GnomeUI Window,

Then a lot of stuff inside GNOME are hardcoded UI's, some are using *.glade files (not to mention that GLADE the interface buil

Re:The future is BRIGHT

[arvindn]

One area in which GNOME has lagged behind other desktop operating systems like Windows and Mac OS X is tight integration with hardware. GNOME is working with the freedesktop.org community to make plug-and-play hardware management just work.

Here's a great paper [pdx.edu] (written just a couple of days back) that describes the current state and future plans of this effort. Highly recommended reading. If you read it your "warm feelings of loveliness" will be doubled :)

Re:Please God..

[Anonymous Coward]

"That means gnome/X/and associated libraries are now eating over 90 MB RAM!"

Please stop trolling. You know perfectly well that that figure includes memory on the graphics card. For any clueless mods: the more memory you have on your card the more memory X will apparently use.

Re:Um...Python?

[chris_mahan]

That's great, and CPython (the C implementation of Python -- as opposed to Jython) can directly call C modules like Python modules. Optimize your modules in C that need the speed, write everythong else in Python.

see: http://docs.python.org/ext/intro.html [python.org] for more on that.

On windows you can access COM components from Python.

By the way, did you know that Python is really OO with multiple inheritance (diamond-style class traversing added recently) and has hundreds of built-in libraries?

ultimately, stay with the UNIX philosophy. more here:
http://www.catb.org/~esr/writings/taoup/html/ch01s 06.html [catb.org]

Re:Firefox is OK, but...

[colinramsay]

Ben just ripped the profile UI out of Firefox, it's a lot more hidden now I believe. I suspect more stuff along these lines will occur - the profile stuff in Firefox is useful only for testing and network deployment.

Re:They should stick with C

[murrayc]

Evolution 2 will not depend on Mono, and Ximian have assured the GNOME community that they have no plans to make future versions of Evolution depend on Mono until Mono is part of the GNOME Platform - something that is also very unlikely to happen.

Re:My Gnome Wish List

[tempest303]

A few replies:

1. The Menus should be much more customizable; treated like folders that you can click and drag into (I hate to say this, but "Like Windows").

This is finally getting some serious attention [gnome.org]. (thank god!) Check out the whole thread if you're interested. Looks like there's a decent chance we'll see this by 2.8.

2. Better Video control properties; take advantage of XFree's extended features and have options like TV switching and such.

This would be cool, though certainly less of a priority. I'd bet we'll see some custom ATI and nVidia proprietary solutions to this for a while to fill the gap, which is what Windows has now, and then somewhere down the road we'll get proper "generic" controls that work with more than one driver.

3. Better preferences; the control panels are quite lacking.

This is poorly defined - what do you mean by "better"? For some people (I'll pick on the KDE crowd here), more prefs is generally though of as "better". For others (such as GNOME's case), "less is more", where preferences like "Use XVideo or XShm for video output"* are eliminated, since it's thought that the code ought to be smart enough to know which should be used, and that burdening the user with such things is a great disservice to them. See Havoc's essay on this. [pair.com] Naturally, there's no One True Way, and that's why there are (and should be!) more than one desktop for Free platforms like Linux, FreeBSD, etc. However, GNOME's approach is almost certainly best for typical non-geeky end users, and is also very popular with anyone else who expects software to Just Work, and that having to figure out what XVideo and Xshm are just to get good performance from a movie player should be considered a bug. It's obvious where my opinion lies on this, but again, I'm very glad KDE and all the rest are out there too, since GNOME's One Size Fits Nearly Everyone is not truly One Size Fits All, and doesn't aim to be.

4. Other aesthetic enhancements that will make gnome pretty enough to compete with other window environments (like win XP's or OSX's). Smooth scrolling, the zoom-on-hover icons in OSX are sweet, and _drop shadows on windows_ would be real nice.

Drop shadows are coming. [freedesktop.org] Smooth scrolling is coming. (scroll down on the link) [gtk.org] Zoom-on-hover is kind of crack, and probably won't happen. There's a gDesklet for this [gnomedesktop.org], though, if you really want this. :-)

5. Some kind of Linux-version-of-Active-Desktop would be real nice, so I could have an IRC session running as part of my wallpaper,anchor the weather channel radar map to the background, etcetera.

Done and done. [gnomedesktop.org] Hope that's been informative...

Re:My two cents...

[Skeezix]

Alt+Print Screen takes a screenshot of one window. Print Screen takes a screenshot of the whole Desktop.

MacOS X's packages leave much to be desired.

[jbn-o]

Do it in "bundles" like OS X, where applications install to folders in an Applications directory, and you can remove the program just by dragging the folder to the trash.

Even on MacOS X that's not true. NeXTSTEP had a far more functional Installer.app which would install, uninstall, and archive packages based on the bill of materials (essentially a list of files that belonged to the package) and this was more useful than the current MacOS X strategy (except that the NS Installer didn't handle conflicts at all).

On MacOS X you can't be sure that a package's content are only in the .app directory because some apps are installed with an installer program that does who-knows-what to your system. Programs that come with the OS are not always desired and don't come with uninstallers (how does one properly uninstall Microsoft Internet Explorer and be sure that all of its parts are gone; how can we know all the parts are in the .app folder? Why can't the installer let you tell it what not to install if you are reinstalling the OS and you know you don't want some program?). Many MacOS X users commonly run their machines as administrative users where they have the ability to write to system directories. Therefore it's possible for a program to see that some file isn't installed somewhere else (like a system dir) and then place a file there. Also the .app directory grants virtually no dependency tracking (modulo that which is built into an application). If program A depends on program B and B is removed, there ought to be a complaint and some kind of extra effort required to break program A but none will occur. As a result, programmers are implicitly urged to not reuse code in this way.

Then there's the inconsistent uninstall procedure -- uninstalling the developer packages appears to have somehow messed up a friend's ability to use Software Update on his iBook running MacOS X. He was lucky there happened to be a Perl script to do this job in the first place -- the developer packages install a lot of stuff in a lot of different places. Software Update complained of a permissions error on a /tmp subdir it was trying to write to. A reinstall of the OS fixed this (and also forced making a backup of personal data which was needed anyhow, so this wasn't a complete waste of time) but it sure seemed like overkill. Depending on each program to supply its own uninstall seems problematic and unnecessary particularly when you have the installer "receipt" which lists what files belong to which package and you could let packagers run a pre- and post-uninstall script to do things that aren't strictly file-based.

Making all of this worse is that so many programs on MacOS X are non-free software; inspecting the program's source code to see what the program really does is not possible. In the end, I think Apple sacrificed a lot for perceived simplicity that ended up not being so simple after all. I think MacOS X has some important user interface improvements other systems would be wise to build upon, but this way of doing package management is not one of them.

As for making a printer (and, for that matter, a scanner) work, I prefer the approach I've used in Fedora Core GNU/Linux: plug in the USB printer and run the printer manager program wizard. The wizard could be improved to automatically sense the new printer and configure itself (or the desktop could do this), but no additional software was needed. Scanning was even easier for me with my Epson scanner -- plug in the USB scanner, start the scanner program, scan. OS X required additional non-free software to do both of these tasks and that means another dependency I have no ability to share, modify, or inspect. I'm not willing to give up my software freedom for user interface enhancements and I don't think I should have to. Looking at how things used to be, history suggests I don't have to either.

Exposing C++ APIs

[roystgnr]

Because it's very easy to expose a C api to practically any language in existence

Absolutely.

but very difficult to expose a C++ one to anything except C++, and in fact it's generally done by flattening the API to a C one

Are you sure that's still true? It was true the last time I checked, but doing a look around today, it seems that SWIG [swig.org] has become very good at wrapping C++ in anything from C# to Tcl.

Re:Most important technology not on the roadmap?

[ianezz]

What about the vector graphics plans? Is a SVG based window manager so far away?

Well, you asked for it [freedesktop.org].

Re:how about

[Brandybuck]

gnome and kde are very much window managers

No they are not. They are environments. If you want to quibble about the term "desktop", be my guest, but a window manager is a much different thing than an environment.

KDE and GNOME come with file managers. They come with browsers. They come with email clients. They come with a lot of stuff that's unnecessary for window managers, but useful in working graphical environments.

They both also come with standard libraries and APIs. So they're also development environments. Write a KDE program and it integrates into the environment in a way a pure Qt program never could. Write a GNOME program and it integrates into the environment in a way no GTK+ program every could.

Re:Mozilla Firefox

[codemachine]

I agree 100% with the profiles. It seems Mozilla is packaged slightly different on different distros. On some, they force you to use profile dialogs on startup even if you only have 1 profile; on others, they never bother you about a profile unless you create a second one. Of course, I much prefer the second method.

As to the Mozilla SeaMonkey (Navigator/Messenger/Composer/IRC) suite, I do agree it is still a useful piece of software. I personally use Konqueror or FireFox as a browser on most of my machines, but when doing support for Windows users, I often install the Mozilla Suite instead of FireFox. That way you can kill the security nightmares of IE and Outlook with one stone, and have some integration between the two. Also the migration tools in Messenger and Navigator to move mailboxes and bookmarks are nicely done. The preloading is also nice - on newer 3GHz type desktops, a new Mozilla window "loads" faster than a FireFox window due to the preloading.

It does seems that the FireFox/ThunderBird developers would like to get the same integration and features found in the suite through extensions, which I think is a great approach. They can then ship their lightweight apps seperately for those who prefer them that way (many on /. fall in this category), but they can also still ship a full suite by having selected extensions installed by default. A FireFox browser with a ThunderBird and NVu integration extension and a preloading extension would come very close to the Mozilla Suite in functionality.