Some comments: > - MIME system. A spec needs to be documented on xdg-list, > and it has to be implemented. A #1 UI issue right now. > (Rather than calling this "MIME system" the UI-focused name > might be "opening the right app when you double click") Is it just me or does the gnome MIME system need to be totally overhauled. Nautilus just doesn't seem to be properly integrated. I was trying to work out how to merge the the nautilus "open with" stuff with the gnome mime type dialog but I think i just gave up and said "this needs to be redone not fixed". > - Lock down mode. Especially for the panel, we need to think > about how this works. There was a thread about it > I started a while back: > > http://mail.gnome.org/archives/desktop-devel-list/2002-November/msg00265.html The Kde 3.1 feature list mentions a desktop lockdown mode. It'd be interesting to see how their implementation functions. This would be a great feature to have in gnome :) fun fun (evil control freak laughter) > - Unifying/fixing "launchers." The launcher editor sucks UI-wise, and > can't be invoked on a nautilus launcher, among other issues. > For many people launchers are the main point of both nautilus > and the panel, this needs to be better. In a recent discussion on nautilus list about how nautilus browses syslink directoories, the issue of whether or not nautilus should create launchers instead of syslinks by default came up. If it is decided that nautilus should create a launcher instead of a syslink when you do "Make link" then this would need to be taken into account when "fixing" launchers and the launcher ui. I think this would involve being able to make a launcher to a file and have it be opened with the appropriate app. Also, the code to edit launchers in nautilus is there, but is turned off for any folder but applications:// - I think that the nautilus boys want to use the plugable preferences for this instead though. Also it would be nice to be able to edit the .directory file in a directory when looking at that dirs prefs. > - gnome-session is (still) unacceptably flaky in the presence of > non-GNOME SM implementations, or anything going wrong. It needs a > lot of robustness love, or someone could whip msm into shape (see > msm/TODO in CVS for a pretty comprehensive list of what needs > doing). Also, gnome-session-properties sucks (and the way > it talks to gnome-session sucks). Reminds me: shouldn't nautilus be session aware. That'd be real handy. > - Preferred applications spec. There should be a cross-desktop > way to specify your preferred web browser, etc.; ideally, this > would automatically adjust the default menus and panel > configuration when appropriate. We should have default e-mail program in there somewhere. It's hidden somewhere in gconf IIRC atm. > - Improve the notification area applet. It should support for example > saving icon positions, hiding/showing icons, this type of thing. > A UI spec for the notification area would help. Also there was discussion about making it automatically add itself to the panel the first time an app uses the notification area. Personally i think it should just be there by default. It's tiny anyway. > - rework the applications:/// VFS *again*, following the newer > specification. This isn't just gratuitous, it adds a numbr of > features such as supporting third party subdirs and allowing > admins to modify menus by dropping in files, instead of by > modifying the file from the RPM or .deb Would this also involve getting menu editing to a good enough state that it will make it into redhat? > - clipboard manager. Perhaps it doesn't need a UI, but it does need > to be a "just works" daemon to persist clipboard contents after > application exit. A UI to "view clipboard contents" is maybe a > bonus. No need for this to be complicated. Personally i've never liked advanced clipbook managers and always found kde's overcomplicaed clipboard thingy excessively complicated. But being able to copy text then close an app and not loose the data is in my opinion so basic that it is a bugfix not a feature ;) > - kill off remaining occasional need to run a whole session as root > in order to avoid the command line. e.g. an aspect of this is a way > to launch nautilus in "root mode" (and be sure it's sane for that, > e.g. doesn't leave metadata files in system directories). right now > to manage files as root graphically you have to start a root > session. Then, configure gdm to disallow root login by default. Yeah, this would rock. Nautilus really needs to have a root mode. Right now i have to do 'sudo nautilus --no-desktop' and it still leaves root mime data and other stuff around the place from time to time. I'm maintaining a little su frontend at the moment, but it would be nice to see a proper "solution" to this integrated into gnome. > - get key GTK 2 ports released and working well. evolution, epiphany, > some native-widgets media player such as rhythmbox. No offense to the team, they are great guys, but they really need some support and encouragement so that they get a 1.0 version stabilised and released. We all want a good music player don't we. As for epiphany. Seems interesting, can't wait to test it (when i work out how to make it build). Certainly has a lot more momentum than galeon, I'm just not sure if i like the new bookmarks system, people are just so used to having bookmarks menu. ---- Maybe these are two specific but here are some of mine: - Gconf-editor: Make it more palitable. Add a search. Maybe support for application icons. Make the deafult window bigger and the tree view wider: Horizontal scrolling makes baby jesus cry. -Window Management: Try to get that patch for saving window position finished. Fix focusing behavior(look at what xfce4 has done, maybe that is the "right way"). Window should be release on drop not drag if at all possible. -Panel: move preferences into a top level menu. fix the applications menu context menu. Applets should inherit background from panel. Should only be one or two types of panel. Add a help menu. etc.... -Nautilus: lots of stuff. See bugzilla ;) Would be nice to make the menus more object-oriented and less "We have File,Edit.View menus because everyone else does". Might be 2.5 stuff though. Am about to send a sepporate e-mail to nautilus-list about nautilus bugs. > If we did even half of the above, GNOME 2.4 would rock. If we did > them all we will have killed a huge number of longstanding user and > developer gripes. Wish we had a 1000 monkeys on typewriters for a thousand years. They could no doubt write us the best desktop ever :) > I know I'll think of more issues as soon as I post this. ;-) We should really have a website for this stuff. And mark each item as 2.3 or 2.5 ad time goes on. bugzilla is good for bugs, but sometimes it just isn't the best way to get something done. In fact I hate the buzilla interface so much that i've been tempted to maintain a list of nautilus bugs in catagories and with discriptions etc.. LAter -- .--= [ MArk Finlay - sisob ] =--. [ Gnome User's Board : www.gnomesupport.org/forums ] [ Public Key: http://evolvedoo.sf.net/sisobatericomdotnet.asc ]
Attachment:
signature.asc
Description: This is a digitally signed message part