GNOME Bugzilla – Bug 87831
Icon on window menu thing shouldn't change unless we're going to use it properly...
Last modified: 2018-01-24 13:14:38 UTC
Eugene just asked why the icon for the window menu thing on the menu panel changes to reflect the currently-focused window. We couldn't give him a good reason, it's just one more visual distraction every time you change focus (along with the updating of the window list and workspace switcher). As it happens, auspex also complained to me about this Christmas tree effect the other day, too :) I suspect somebody originally just saw it on the Mac and thought it was kewl, but unfortunately they forgot to include most of the functionality that really did make it useful on the Mac-- for example, if an application that isn't currently focused pops up an error message or otherwise needs attention, the icon in the menu bar is replaced by that application's icon, but flashing, to draw your attention to it. If we're not going to do anything useful like this, can we just replace it with a nice-but-static icon?
*** Bug 107243 has been marked as a duplicate of this bug. ***
I agree that at the current point this is a bad thing...so if we don't do anything with it we should get rid of the flashing :-P There are some good things that could go here if somebody felt inclined to do the coding. For example, having Close, Minimize, and Maximize as the first items in the window (that effect the focused window) could be nice. Also possibly "Minimize All".
Seth: I have no idea what you are talking about - for a moment I thought you'd added a comment to the wrong bug :-)
Mark: This bug refers to the icon at the extreme right of the Menu Panel. The icon changes every time a window takes focus, which as Calum says is a visual distraction, and doesn't give the user any information.
Eugene: yes, I understand that. But I don't understand: > There are some good things that could go here if somebody felt > inclined to do the coding. For example, having Close, Minimize, and > Maximize as the first items in the window (that effect the focused > window) could be nice. Also possibly "Minimize All".
Ah, sorry. Let me clarify... The use of a particular window's icon is very suggestive that the pull down menu will allow you to affect that window's properties and/or perform "actions" on that window. Currently closing/maximizing/minimizing windows involves positioning the mouse in two dimensions over a fairly small close button. Its much easier to throw the mouse into the corner, and position it in only one dimension (up|down). I could imagine an upper right corner menu looking something like: -------------------------- | [I] <b>My Window</b>| |--------------------------| | Close | | Minimize | | Maximize | |--------------------------| | Minimize All Windows | |--------------------------| | [I] Another Window | |*[I] My Window | | [I] Another Window | | [I] Another Window | | [I] Another Window | -------------------------- I suspect this is good from an overall efficiency perspective, though it is slightly weird to conflate "window switching" and "current window actions". I'm not sure how I feel about it overall, just something that popped into my head.
Oh, one thing is that for the pull down window list to be any use at all.... app's window titles need to really come into compliance with the HIG. The current tendencies like putting company name, version number, and other weird crap in the title make titles hard to scan, and make a pull down window list extremely difficult to use. "Seth's Bugs (17) - Ximian Evolution 1.2.1" "X-Chat [1.8.10]: seth @ ircd.gimp.org / #nautilus (+spn)" "Stanford University - Mozilla {Build ID: 2003021120}" Just to give a few examples from my current desktop... These things really should be dealt with anyway, but the consequences for a list that you can't scan as you're mousing toward it are more dire.
A potential hurdle with this idea (which I'm not convinced about anyway, but that's beside the point!) is that right now, as soon as you click on the pulldown window list, the panel gets focus, as indicated by the menu's icon changing to the panel menu. So as it stands, we can't add operations that apply to the currently-focused window, as that's always the panel :) And I've no idea what a good solution to this would be; things on the panel really do need to get focus when you click on them, for a11y purposes. Even if that was magically fixed somehow, you could have a similar problem for focus-follows-mouse users... the focused window may change while moving the pointer between the window you intended to operate on and the pulldown window list.
The suggestion from comment #2 and its following discussion is more pertinent to bug #104686
The Window Selector now uses the new WnckSelector widget from libwnck. Moving bugs to libwnck.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/11.