I like Gnome. I think it has a clean, efficient style especially when compared to KDE. But there are some things that I think are missing, and some things that I think were done without much thought or for wrong reasons that negatively impact ease and efficiency of use. KDE has a tendancy to try to match Windows features (while also doing some great original stuff also), but there are a lot of Windows features that are bad. Unfortunately, Gnome often does the same. At least it only does it sometimes, and is just as likely to borrow ideas (good and bad) from the Macintosh etc., and I also see a lot of creativity in its designs (both visual and software designs) -- though I admit to paying more attention to Gnome development than KDE.
I am also a programmer, and have used GTK+ to build programs, so I have some ideas about new GTK+ widgets that applications could use to improve usability and usefulness.
On this page, I gripe about the problems and brainstorm new ideas. Some of them are very small and simple and could be implemented and tested in about 30 minutes. Others are features that have to obvious implementation method. Others require restructuring or rethinking bits of Gnome's current design plan.
I choose to worry about Gnome because it is intended to be simple, clear and easy to learn, so any defficiency in that department really begs to be resolved. Plus, as one of the two most popular UI systems, improvements to Gnome will affect many people as well as be more visible to interested non-Linux users.
Some of these I've submitted as requests or bug reports (search all my bug reports here) but some I'm still thinking about and could someday hack into new programs or forks of existing programs.
Gnome also has a "User Feedback" Wiki page (you must Log In to edit) but I doubt any developers really pay attention to it, but there are some ideas there that are good but too vague or non-specific to be entered as actual feature requests.
Similarly, Ubuntu has Ubuntu Brainstorms. This site has voting on ideas so perhaps the top ideas might come to the attention of Ubuntu developers to try implementing.
Contact
Pie menus, if done elegently, might be really useful. They should have icons and text labels, and be flexible -- they are most effective when they fit in nicely with whatever the current action is -- that's the point. More generally, instead of just being a "menu" of options, it could present a focused control or set of controls the way a modal dialog box might, but pop up near the mouse and be easily canceled. It would be cool if they faded in and out (with configurable speeds by the application, e.g. a slow timeout fade out, or a quick cancel fade out).
Lots of widget toolkits seem to have put a lot of really neat functionality into their toolbar widgets, but restrict that neat stuff to only the toolbars! The main one is the ability to move toolbars around, to either drag it away from the top of a window and let it "float", or to attach it to a different toolbar in another part of the window.
The splitter pane widget (GtkPaned) should automatically let the user reorder panes and drag panes to other parts of the window. This would make it very easy for a user to customize a window either temporarily for a particular task, or permanently. Pane layout should be saved with the session somehow. (See below about better session management.) (You'll also notice if you read below that I'm not a fan of overlapping windows other than in exceptional cases where the user asks for one...)
GTK 2.10 will some new features for dragging notebook tabs, but not panes yet.
You should be able to make a pane get very small and compact, retaining only a title or icon, by double clicking on it perhaps; and also expanding it back to its original size by clicking on the title. Some Microsoft applications can do this. This would be far better in many circumstances than tabs, since only one tab can be active at once.
Sometimes you could use a GtkExpander but an expander's target is "part of" the panel or pane, not a seperate "peer" object logically or in behavior.
Gnome provides a session manager, which saves information about an application when it's shut down in a certain way (e.g. if you just log out while the program is still running) so it can restore that state when it's started again at the next session. Unfortunately there are some things that it doesn't automatically save, such as states of GTK widgets modified by the user (such as positions of sashes in paned layouts, etc.) If it's really important the application can save that information itself, but the two ways of obtaining the previous state (command line arguments, or by reading stuff from gconf) can be tedious.
If some mouse combination is bound to the focused window, display it in the status bar. Maybe this should be an optional flag on GTK objects? Then the text in the status bar would automatically update depending on what different mouse buttons do at that moment, even if they change (e.g. if you select a list or iconview item or hold down some key, or are holding down a mouse button and the action that doing a drag and drop will perform is defined).
Writing GTK code takes a lot of keystrokes. (Work). Most of this is due to the way it does OOP-in-C, as such it can't really be avoided. However, there are a lot of really typical things that take lots of code:
Probably restricting what can go into a toolbar was a usability decision. Gnome and GTK developers do this on purpose, and it's a good thing. But sometimes you do want something else. One thing that would be useful is to have a contextual menu (right click) actually be a toolbar or toolbox with different kinds of widgets (e.g. checkboxes). You can do this by hand but it's a bit hard.
A common need I have in the kind of apps I do is to display the values of a set of variables, either just for debugging, or for the user to monitor. It would be helpful to be able to do this with a minimum of fuss -- especially since in GTK creating new controls with labels takes a lot of programmer effort. This control would keep a set of labels, pointers to any program variable, a formatting code, optionally a pthread mutex to lock (or maybe just a functor to invoke before accessing the variable.) The control would create the right kinds of controls and handle columns, etc. It could also optionally let the user edit variables (either changing the variables directly, or sending a signal you can catch).
I'm not a fan of overlapped windows -- in the general case. Notice that the vast majority of the time, you are working in only one window. So you should only have one window visible, plus a minimum of extra stuff like docks, panels, buddy lists, mp3 players, unused desktop space with a pretty picture on it, etc. I came to this style after (a) using laptops with small screens, and (b) trying to reduce distractions while working and increase focus on my work. Micromanaging overlapping windows can be irritating as well.
How do you switch between applications, if some of them have maximized windows, or tiled windows, or floating windows? I would make the window selector panel applet a bit more like the Macintosh dock; it would be an application selector+launcher applet.
Like the OSX dock, applications in the process of starting up should be indicated as such. Maybe even display a "starting..." window if it takes too long?
(in many ways, Gimmie is similar, though it is a seperate thing from the panel. Also, it has an application/document/people categorization, though they may be planning on making that configurable.)
Another useful feature would be to better distinguish "minimized" windows. This could be done by a panel applet whose job is to hold icons for minimized windows. You could keep a panel on the bottom or side of the screen for these. A helpful gnome-panel option would be for the panel to go away if there was nothing to display in it (i.e. the minimized-windows applet, or an applet like the notification area, was empty). Another option would be for the window manager to stack the titlebars of windowshaded windows in a visible place.
An alternative to this application centered approach, is to try to support a user's-work centered approach. This idea has come up, for example, on the Gnome "topaz" wiki page. (Some of the good but more discrete -- or actually implemented -- ideas from that page get moved here occasionally, look there for a more concrete look at potential future features of Gnome!) This would require inventing some intuitive tools that allow a user to define some kind of structure represeting their current work, and somehow mapping that back to the conventional run-a-program (or send-a-message-to-a-program-using-dbus) paradigm.
One thing is, I have no idea if this setup would at all be useful to anyone other than me, since it is very idiosyncratic to my preferred style of working.
Furthermore, things like the window list have to make guesses about which windows can be grouped as part of the same application, since X-Windows doesn't explicitly provide this information (or even have that information, perhaps.) Gnome uses a library called wnck to make these guesses; if you're using applications all written for Gnome or using a consistent policy for naming window titles, then it tends to do fine though.
My specific request will probably not be implemented in Metacity as such, so I may make a hacked fork eventually, plus the applets which are seperated. One cool new feature of Metacity in Gnome 2.14 is a "magnetic edge" thing that causes windows to initially resist overlapping or getting out of alignment.
I have also now found a littel program called "Devil's Pie". You can install it on Debian as "devilspie". You write little lisp-like scripts that match window and application names and can do window-manager things to them. I have used this to implement the window maximizing idea above, with exceptions for certain things. If Devilspie had a few more features like data storage/retrieval to remember previous states of windows, and to also respond when the user initiates a change in a window by clicking a button, then I could probably implement most of the above for experimenting with.
Buttons to switch to other X servers running on the same machine, via a menu in the panel and also buttons on the GDM splash screen. I know this is not technically "window management" but this is where most users will consider it to be. I think newer versions of Gnome already have the menu to switch between X servers (between "logins"). It ought to help avoid logging in twice with the same user name, since that can cause problems, but you still should be able to if you want.
If in Nautilus, you have any directory open which is a subdirectory within a mounted volume, an "eject" button should appear in the toolbar. Most non-expert users won't know that you have to "unmount" a volume in order to be able to properly physically remove it (e.g. a CD drive often won't open if still mounted), and may not have the volume manager applet in her gnome panel.
Unix permissions can be confusing to the non-initiated. Nautilus helps a lot, especially by adding the readonly icon to files, but can still be weird about it. One instance is in the Permissions properties tab for directories: it lists "read, write, execute" permissions just like files, even though directories can't be "executed", so instead "executed" really ought to say "enterable" or "openable" to the Nautilus user.
Does anyone actually use these?
A few things would make them actually useful:
On the other hand, maybe the ways I think emblems should work are just too complicated :)
It looks like there has been some work at tagging objects in Gnome, and they have plans to map Nautilus emblems to tags: tags in gnome by Christian Hammond .
Mac OSX has a very useful "columns" view where subdirectories are displayed in columns from left to right, and the whole set of columns can be scrolled.
very often reported but looks like it's currently low priority to add.
Folder icons should indicate how many items are in them (0, 1, 2, 3, 4, 5, 5-10, 20-50, 50-200, 200+). Document icons should indicate how big the file is: Nautilus should let programs provide icons for various size ranges.
While Gnome comes with control panels for lots of stuff, it doesn't cover everything yet.
Tool to edit your crontab (with a button to try out a command before saving the crontab!) or set 'at' jobs. Gnome might already have this, not sure. Cronjobs are one of those things most people would do only sometimes, so remembering the syntax for the crontab file is hard. You should be able to either specify a command exactly, or choose from a list of abstract tasks and conditions (with key/value parameters associated) -- see abstract tasks and abstract conditions.
In addition to initializing services, if there were a nice GUI for selecting kernel modules to load/not load then you could disable anythnig you know you don't need. (See ideas about Gnome system tools above.) Basically a front end to /etc/modules.conf (or /etc/modutils/ in the case of Debian.) You should also be able to manually modprobe or insmod/rmmod files selected from disk, with the option of importing them into /lib/modules or /usr/local/lib/modules and including them in the default set to run at startup. (For custom device drivers.)
Could be integrated with Boot-admin tool. KDE has a nice tool for reconfiguring and recompiling the kernel.
It would also be helpful if this control panel included a paragraph explaining exactly what the kernel is and what modules are for (essentially, device drivers).
Essentially a front end to setseriall and stty. Maybe also to modify portions of /etc/inittab. (e.g. where to run gettys).
You can only set the global system-wide time and date, which requires administrative privilages. Users should be able to set their own custom time through the clock applet or one of the preferences (resulting in an offset value relative to the system clock stored by Gnome). This custom time should also be used by calendars and all other apps (unless the user explicitly specifies a time zone in the calendar, say). -- the problem here is that users might expect all programs to behave correctly. Really this should be managed at the user level, perhaps somehow the TZ environment variable could be set in the login shell? Or at least in shell-like proceses that will be launching other programs (the panel). And also broadcast to currently-running programs somehow.
Even if as a user, you don't have permission to read the contents of a log file you should still know that it exists.
The keyring can be annoying (MacOSX has this same problem). I am often prompted for passwords for no obvious reason, just because some program happens to be accessing a protected data source for the first time. I'd like to be able to just disable it and need to enter passwords each time. Or, to name trusted programs that can always access certain passwords (which would move this aspect of security onto the assumption that there has been no malicious tinkering with system binaries).
This may not be neccesary for most users using removable devices, but if you install/uninstall/repartition disks or want to add/remove virtual memory swap partitions or swap files, then you also need to edit /etc/fstab. A GUI would be useful here. It could be combined with Gnome's existing "Disks" admin tool which you use for partitioning mostly I think.
Provide GUI for certain daemon configuration parameters -- enough to make these work in most cases in a somewhat restricted way. An app each for:
These tools could be launched from the Services tool, but not every thing we consider a daemon or "service" will be thought of that way by the user. The config tools ought to appear in the Administraton menu as well. Caution, however, is recommended when making too many things accessible from too many places, or we'll end up with the maze called Windows XP.
There need to be more GUI frontends to services. I mention some specific examples above, but in general any service that the user might need to know about, should have at least some of its configuration able to be done via a simple GUI tool.
The Services tool lists some of the background services running, and allows you to disable them. It could do a bit more. It could provide a button to restart the service (/etc/init.d/service restart) -- I have to do this if my router was turned off when the computer booted, and it never got an IP address via DHCP. Sometimes an OS upgrade tells you that you may restart a service if you want (if required, it usually does it), or you did some manual configuration by editing a file, but don't neccesarily know about /etc/init.d/...
If a service has an administration tool to configure it in Gnome, then there ought to be a button in here to open it as well.
Also, on Debian, some services get startup parameters used when their init.d script executes by reading them as variables from files in /etc/default/. It might be nice to be able to change those variables via this tool as well, if that's the only way to configure them.
The Gnome developers seem to have asked themselves 'well, what kind of thing exactly is "Gnome"?'. The answer they came up with is that Gnome is "a Desktop". This means that in many places Gnome refers to "The Desktop" when it really just means "Gnome in general" or "all of Gnome". To me, "Desktop" just means the empty space behind all the windows on which you might also have some icons floating around; and Gnome and Nautilus also use the term Desktop for this thing.
Specifically, there is a menu in the panel called "Desktop" which really contains "Miscellaneous" things. Some programs have been somewhat arbitrarily moved from the Applications menu into the "Administration" category of the "Desktop" menu, (to be near your personal user Preferences). This menu also contains a help item, and log out and lock screen items. It also includes the "About" dialog for all of gnome, and "Take screenshot" which is possibly even less useful.
While reducing the number of sub-sub-sub-sub menus -- one of the worst unusability traits perpetuated by Windows and it's Start menu -- it also wastes space in the panel and makes it harder to find things that you're not sure are Preferences, Administration tools or System Tools. I would just move everything in Desktop into Applications, or rename it Gnome.
But see below about menu editing
Gnome's menu lets you "edit" the menu, but all you can do is disable certain sections, which is useless. Someone has written a much better menu editor called alacarte (allowing you to move things around), which should be adopted by Gnome to replace the old menu editor, be renamed to "gnome menu editor", improved to allow moving things between the "top level" menus (Applications, so-called "Desktop", and "Places"), creation/deletion of top level menus, and it should be accessible as part of the "Preferences" in addition to the menu's right-click menu. Even better, though, would be to do all this in an edit mode directly within the Gnome menu, reducing the need for the user to search around for a seperate tool.
In the menus, the gconf editor should show as "all preferences" or something. The idea is that a user could open it and to a search to find a certain setting. (gconf is like the Windows registry but just for applications, not "the system".)
The Todo list is an application that is usually accessed via a status bar icon. But if you hit the close box on the window, then the whole application exits and you have to remember where in the menu it lives in order to restart it :) gnome-jabber has this same problem. In general, my opinion is that any program that has a status bar icon should not exit on window-close (if the status bar icon is still there). Of course, most do. (There probably ought to be a HIG policy about this, I don't see one.)
Like a contextual menu that automatically appears near the mouse when you select something. For example, you click an icon in nautilus and the most common operations for that item appear as new icons around it, visually "floating" on top-- buttons to open, rename, delete, grab, properties, and "more actions" to open a menu with other nautilus operations, plus actions.
The popup menu would basically be a pie menu that automatically appeared on one click. Maybe be smart about how to arrange the items so as not to obscure useful information, and fade a few seconds after you make the click. When you start to drag an item, it should fade quickly, and a new popup appear when you drop it for copy/move/link/cancel.
Windows' file explorer puts a list of actions like this in the sidebar, but that's not easily noticeable or accessible. It has to be a visually obvious behavior and close to the mouse and focus of action. Plus, since it's a list on Windows they tend to put lots of things in it. If they had to be clustered around the mouse selection/action, you could at most have about 4 items plus a "more". Plus, it would be better to generally integrate the available options presented into the actual actions you are performing.
This could also easily be an option you can turn off, and it would act as before.
Similar to the .desktop files for menus that identify specific programs you can launch, a set of metadata for programs describing their functions or abstract tasks, each of which is mapped to one or more specific commands that the system can invoke and/or send dbus messages to (with some parameters required, defaults overrided, or always given with the command). The "preferred applications" control panel could then be expanded to let you choose any of the alternative commands (if more than one) in any file, or specifically add your own custom commands. Tools like the task scheduler/cron front end could use these abstract tasks, and also let you add new commands on the fly. Examples of abstract tasks are open a web page, send an email, change presence for IM clients and others. These tasks can each be achieved by running some command, or sending IPC (e.g. dbus) messages to a program if it's already running. This system should be acessible in the filesystem for installers to use, and in a C API for programs to use, perhaps with standardized GUI for GTK, and via a command-line tool for scripts to use (e.g. "gnome-action webpage url=http://gnome.org").
I think the next version of nautilus will include something like this. Not sure how restricted to nautilus it will be, though.
MacOSX has this too, and the "Automator" program lets you chain together actions that accept or provide defined input/output data types. I think actions are defined in XML files (plists) that describe their GUI, input and output types, and which applications to associate the actions with, plus either an AppleScript that operates the application's GUI, or a C program (maybe it has to be Obj-C?) that uses some kind of IPC to communicate with the application (services?) Here are some resources on OSX actions:
For Gnome, the IPC would probably be based on dbus.
It would be cool if wxWidgets or a companion library abstracted all these IPC architectures.
We could even have a VOS interface to OS-integration IPC services, where an action results in either a child property being set on (for convenience) or (more generally) a message sent to an object that also has an interface to the OS-integration service (dbus or whatever). See the VOS wiki page about this.
In addition to doing tasks (actions), another set of similar objects could be defined for "conditions". This system should be acessible in the filesystem for installers to use, and in a C API for programs to use, perhaps with standardized GUI for GTK, and via a command-line tool for scripts to use (e.g. "if gnome-condition presence=away; then mail $USER -s hello; else xdialog --infobox hello; fi").
A panel applet for putting "sticky notes" or todo notes in a panel. Ideally you could create a seperate panel for sticky notes. Options for sorting them too by category, time, priority, etc. (including features from the gnome todo program).
Linux used to start up very very fast back in the day, but it also required expert knowlege to install and configure. Now most distributions (I use Debian) do a lot of autodetecting and try running different services depending on what hardware and configuration is in place at boot time. Plus, there are many more helpful services running on a modern system, and it takes a bit longer for X to start up if you have a 3D graphics accelerated card.
Most
of
the
stuff
that
init
is
doing
at
boot
is
extremely
I/O
bound,
and
order
does
not
matter
to
certain
sections
of
boot.
What
if
dependencies
were
declared
between
init
scripts
and
init
used
make
-jN,
where
N
is
#CPUs
X
2
or
#CPUs
+
1
or
something,
to
execute
them?
In fact, people have done this -- this article at IBM Developer Works website gave me this idea.
If you set it up right, you could even remain compatible with the existing SYSV method Linux usually uses by leaving all the init scripts in place, and simply leaving any script without dependency metadata until last. Plus, Debian includes tools for installing init scripts that packages are supposed to use (this abstracts the init system a bit mostly for portability between Unix-like systems that do things slighly differently).
In addition to hacking your own makefile as described in the IBM article, at least one group has implemented this idea in a general way: serel, but seems to have been last active back in 2002. They use special tags in comments at the beginning of init scripts, which is a good way to go. serel generates RDF files to describe the dependencies though, which is kind of odd and adds a dependency on an XML parser to serel, and it actually runs some kind of background daemon that init scripts can communicate with, which they use to really tweak speed of scripts down to the last milisecond, which I don't know is worth the trouble.
The only other tricky part is how you go about doing shutdown. Can you just follow the dependencies "backwards"?
Just by eyeballing it the slowest part of my system booting is "setting system clock from hardware clock". It actually does this twice, too. Maybe some of this stuff can be parallelized, though that makes startup complicated and possibly bug-prone, not a good thing.
If my system doesn't find a DHCP server (which is my wireless router that I sometimes turn off) at boot then it gives up. The only way then to make networking work is to run '/etc/init.d/network restart' as root or reboot. This is kind of annoying; should it keep listening for a DHCP server to come online? Not sure how this sholud be fixed.
Not really part of Gnome (it has its own browser called Epiphany) but probably the most used browser.
Close the donwnloads window after last download finishes.
I used to use a great web browser on my Mac called OmniWeb. It had some nice features including a button on a multiline text edit box in a web page form that opened a modal dialog box with a bigger editing area and more tools. You could also use search and replace, spell check, and other tools that the browser more or less already supported for its own UI within the text edit field.
Zinf is an Mp3 player that has a nice combination of features (and doesn't do anything particularly annoying like some others). Unfortunately, it seems to have some bugs and not agressively maintained (at least the Debian package has some bugs and uses GTK 1.4).
Someday I'll get around to properly reporting or just fixing these.
It sorts all your music that it knows about by artist then album, which is what you usually want. But occasionally the artist differs but the album is the same (e.g. a compilation or set of remixes), or you have a grab bag of misc Mp3s you want to group together, or you have one song per album.
Finding the menu item is hard and this is a common operation.
The right-hand pane should resize if you resize the window, the left-hand pane should remain the same width. The ability for a split pane to do this automatically was only recently added in GTK, which is why zinf doesn't do it yet.
Or at least, it seems sort of like it to me. All the files should be appended to the end of the list, but be themselves sorted with their modification timestamp (so recently obtained files go at the end). Plus sometimes selection in the current playlist gets all messed up after adding files.
Often if you don't drag a song just right, it can't do the drag and drop reorder at all, except that minutes later, you start seing ghosts trying to drag files around (I assume that the drag events are getting stuck in the bottom of some event queue, or there is some deadlock that finally gets unlocked).
maybe
But the window manager should be taking care of this I think.
Contact