GNOME Bugzilla – Bug 90134
tasklist should also use "on top" to decide whether to minimize
Last modified: 2018-01-24 13:15:24 UTC
I'm not sure I'm convinced that this is the right thing to do, but a suggestion here to consider: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71001
FYI, KDE does things the way I suggest. In fact, KDE will only minimize a window when you click on its taskbar button if the window is BOTH topmost AND has the keyboard focus. If either of these conditions does not hold, KDE simply raises AND focuses the window whose taskbar button you've clicked.
All sounds vaguely sensible to me, although I don't use focus follows mouse so what do I know :)
I use focus-follows-mouse except when testing bugs and patches for Metacity/libwnck. :-) I think Alex's suggestion sounds perfectly reasonable. However, Havoc's summary doesn't match Alex's suggestion so I'm going to change the summary (to reflect that toplevel window should not replace active window as the method to determine whether to minimize; it should use BOTH criteria). Here's my line of thinking: We want the behavior of clicking on windows in the tasklist to be "If the window is 'not activated' then 'activate' it, otherwise minimize it". 'activated' in this context is a little unfortunate in that there are window manager hints and function names using that word that don't necessarily mean the same thing. But I couldn't think of a better word. Anyway, libwnck currently interprets 'activated' as 'focused', whereas 'focused AND raised' perhaps makes more sense. (Of course, for click-to-focus, there's no difference between these interpretations since focused implies raised in that context) My first guess at implementing this would be to have libwnck treat both non-focused windows and obscured windows as 'not activated'. The reason I say obscured instead of not-top-level is that I wouldn't want a window which is unobscured but considered to be "below" another (which I think can happen if the two windows have no overlapping region) to be raised instead of minimized. However, this could cause problems in cases of windows that are always on top (such as the panel). So, if I understand correctly, implementing this would mean determining whether the current window is obscured by any windows "at the same level" (meaning that always-on-top windows such as the panel shouldn't count as obscuring a window). Does that make sense? Anyone want to provide guidance as to whether my implementation strategy makes sense and perhaps give some pointers on how to do that? :)
*** Bug 144526 has been marked as a duplicate of this bug. ***
note to self: wnck_screen_get_windows_stacked() may help here...
I'm glad that the discussion on this subject finally got going. When will this bug be fixed. I need to have it fixed yesterday!
If you're in a hurry, then please fix it yourself and submit a patch for us to merge. Otherwise, you'll have to wait until we get around to it. I'd like to do this before Gnome 2.10, but I have a lot of other higher priority things.
The proposed behavior seems sensible. However, usability wise we're trying to ween the desktop off of focus follows mouse anyway, so I would say this should be rather low priority.
> However, usability wise we're trying to ween the desktop off of focus follows > mouse anyway, so I would say this should be rather low priority. I fail to see how weaning users off of a valid preference, especially those of us who've been using Unix for years, is a good thing. Please don't penalize us for our preferences.
Michael: From both an ease-of-learning and consistency perspective, sloppy and mouse focus have some tradeoffs that make them suboptimal (see doc/how-to-get-focus-right.txt in the metacity source code for more details) and thus understandably reduce their desirability for usability folk. Seth's comments are spot on as far as guidance for priorities for the usability team (and the team was cc'ed after all, in addition to the keyword being added). That being said, I'm a die-hard focus-follows-mouse user as well, and I intend to continue to fix activation bugs for all focus modes in metacity, libwnck, and related modules. A truism in open source is that you can increase the priority of something by providing patches...which I intend to do. ;-)
Moving to the right component. Sorry for the spam.
*** Bug 167866 has been marked as a duplicate of this bug. ***
*** Bug 321265 has been marked as a duplicate of this bug. ***
*** Bug 349368 has been marked as a duplicate of this bug. ***
*** Bug 339371 has been marked as a duplicate of this bug. ***
It's worth noting that Stephen Cook has a partial patch in bug 339371; it'll fail in certain cases, but should work in quite a few of them. I've asked him to attach any further patches here. Also, bug 351055 will need to be fixed before this one can be.
*** Bug 351359 has been marked as a duplicate of this bug. ***
*** Bug 346790 has been marked as a duplicate of this bug. ***
*** Bug 458667 has been marked as a duplicate of this bug. ***
*** Bug 476907 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Please don't penalize us for our preferences. Welcome to GNOME. Apparently you're new here! ;) But seriously, folks, this STILL bothers me, more than five years later. I have neither the time nor the inclination to try to spelunk my way around the GNOME source tree and fix it myself, especially when KDE works just fine.
(In reply to comment #21) > (In reply to comment #9) > > Please don't penalize us for our preferences. > > Welcome to GNOME. Apparently you're new here! ;) Funny...but not accurate. I myself also use mouse focus and get hit by this bug on occasion and I'm one of the maintainers. I simply haven't had time to fix this issue; there are simply too many issues. I'm once again attempting to dig myself out of my inbox pile...
*** Bug 568923 has been marked as a duplicate of this bug. ***
*** Bug 491436 has been marked as a duplicate of this bug. ***
Maybe I should throw a party for the 9-year anniversary of this bug in a month... :)
I think the "dock" GNOME 3 shell extension handles this the right way. So maybe we can call it fixed in GNOME 3?
-- 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/12.