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

Comments

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

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. (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. 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. Smooth scrolling is coming. (scroll down on the link) Zoom-on-hover is kind of crack, and probably won't happen. There's a gDesklet for this, 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. Hope that's been informative...

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.

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.