GNOME Bugzilla – Bug 55260
panel needs feedback on application launch
Last modified: 2015-03-24 13:00:35 UTC
Package: gnome-core Severity: normal Version: gnome-core-1.4.0.2-ximian.8 Synopsis: panel needs feedback on application launch Bugzilla-Product: gnome-core Bugzilla-Component: panel Description: From having now watched a number of Unix neophytes sit down with a GNOME desktop and try and figure out how to use them, I think I can safely say that application launch is the thing that confuses them most. (Or at least, the thing that confuses them first.) Compared to Mac or Windows, applications on Unix launch VERY slowly (and I'm talking about modern, average machines here: 600MHz, 64M RAM.) This is compounded by the fact that most applications are launched FOUR times at once! I've watched this happen many times. It goes like this: - Click on a button in the panel. Wait 2 seconds. - Nothing happened. Maybe I missed. Click again. Wait 2 seconds. - Nothing happened. Maybe I was supposed to double-click. Click twice. - Then at this point, they notice that their mouse is moving really slowly. Oh, maybe it's doing something. Now windows start to appear. They start trying to close some of them, but it doesn't work. - This sucks! they say. And these are not people who are new to computers: one of the people I've seen go through this process multiple times is a major-league expert Mac user. So you really need to find a way to give some feedback on when apps have actually been launched. Here are some suggestions: 1: when you click on a button in the panel, have it change state: have it stay down for several seconds, so they know that something happened. Maybe even have it change to say LAUNCHING over the icon or something. 2: have the button gray out after the first click, and stay gray until a window has been mapped that has the appropriate title/class. (The panel buttons could have a field that says the class of the window to wait for.) This could time out after, say, 10 seconds, and if it does, and pop up a dialog saying "the application does not seem to have launched properly." 3: Expert users might not like this, but it would be even better if the panel actually grabbed the mouse when an app was launching, and did not allow other clicks until the window appeared, to avoid spazzing. Turn it into a busy-cursor. People are used to this because that's how the browser works: after you've clicked to load a page, you can't click again until the new page starts showing up. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-05-26 14:20 ------- The original reporter (jwz@jwz.org) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, panel-maint@bugzilla.gnome.org.
xalf is supposed to help here, but as people seem to agree that xalf needs to be redesigned I'll leave this report here and add the Usability keyword to it.
Didn't someone at sun do galf? Anyway the solution should be generic for all GNOME launching mechanisms (Control-Centre and Nautilus) This enhancement/bug is the result of the gnome "must fix for 2.0" usablity project: http://developer.gnome.org/projects/gup/proposals/
Adding relevant keywords. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
this one really needs to be fixed (for nautilus as well)...
Definitely not going to happen for 2.0.
CC'ing Havoc. I just played with OS/X today, and thought the "bouncing launcher icon" feedback was quite excellent.
If anyone wants to implement this, send me email and I can send you a load of stuff to read first. I'll probably get to implementing it eventually, but it'd be nice if someone could get to it sooner.
moving to gnome-panel
For the record, I implemented a workaround for this lossage here: http://www.dnalounge.com/backstage/src/kiosk/sbin/runonce.c This requires setting up your panel icons to run programs like this: runonce "XChat" xchat -args It will raise windows if they already exist, and is pretty clever about processes that are just starting up and haven't mapped a window yet. However, this behavior should really be built into the panel, so that the buttons are grayed out while the application is in the process of being launched. Another suggestion you should consider, beyond the ones I made in the initial report, would be to put up a splash screen for applications that take a while to start -- panel could note that the process it has launched has neither died nor mapped a window within, say, two seconds, and in that case, could put up an ephemeral window that says "FooApp starting..." which would be torn down as soon as some Foo window showed its face.
This is a very important bug. When I test GNOME2 on users who are not familiar with GNOME/Linux, one of the biggest problems they have is launching multiple applications. Many of them don't even realize that they asked the computer to launch multiple times (even after seeing multiple windows open). I'm guessing they subconsciously assume that the click didn't take based on the lack of feedback. Its also a hard bug, so if we plan to resolve it in the 2.0.x timeframe we better start planning soon. (as an aside, users also have troubles with Nautilus in this regard, so a solution should handle both).
I don't think it's that hard, probably take a few days. I'll go ahead and attach my design notes if I can find them.
Created attachment 8112 [details] Notes on one possible design
So I owe Lubos Lunak from KDE some more discussion of this issue; KDE has a working setup which uses text strings serialized into streams of client messages. They don't support all the wacky stuff I put in my notes but their basic approach could be extended to do so. I feel like the client message thing is a bit hacky compared to the X properties and special X window approach, but it probably works fine.
Interop with KDE would be wonderful as long as we get to keep your (terrific, really) set of design goals.
New feature -> 2.2.x milestone
This bug would be on my "top ten usability problems I'd like to see fixed in GNOME 2.2" list.
Seth: are you keeping that list? it's not easy to manage right now, but I'd like to make it easier. [Note that I've already marked this 'high'/enhancement- I don't think there are many of those around, so if you want to use that combo to mark your other such, go ahead...]
oh, I have a paper list here, I can put them in bugzilla that way if that's best
this is working fine with sun's internal builds with galf - it seems a bit silly that we don't at least put a temporary solution in place for all gnome distro's by using galf (or am is that a totally crazy idea?)
What about the method that Havoc explained in: http://mail.gnome.org/archives/desktop-devel-list/2002- September/msg00366.html is that something that could work for 2.2?
I'm working on this for 2.2; there's a "startup-notification" module on cvs.freedesktop.org with a reference implementation already written, I'm finalizing a joint proposed spec with Lubos from KDE to send to xdg-list, and have discussed with Owen how to work this in to GTK 2.2. Remaining work is to add support to libwnck metacity, and panel (or rather our "launch a desktop file" code, wherever that lives). We should make GNOME 2.2 with a nice solution, no need for LD_PRELOAD wackiness.
Yay!
YAY !