GNOME Bugzilla – Bug 436817
Minimize to tray: window jumps
Last modified: 2008-02-16 18:14:25 UTC
I first thought this was a bug in the Compiz Window manager, but it turned out Metacity has the same problem. To reproduce: - Activate "Select windows when the mouse moves over them" in the Window Preferences - Have a window (e.g. Firefox) maximized - Have a banshee window (_not_ maximized) on top of that - Now move the mouse to the tray icon and click => Banshee shoud minimize to the tray => Instead, the window jumps to its last position and gets focus => clicking again actually minimizes to tray The problem seems to be that minimize to tray only works correctly if the window has focus. Can this be fixed?
Created attachment 87790 [details] Video A screen capture I did which shows the problem and how it works correctly if the banshee window has focus when clicking.
This is by design. The notification icon focuses the window if not focused, and minimizes it if it is focused.
By design? Hmm... it's different to how about all other apps work :/
All? I know Deluge and Pidgin work this way. If I recall (it's been a while since I participated in any discussion of notification area icons), the GTK+ and/or GNOME move was towards this behavior. All I was able to find offhand was a reference in some GNOME HIG draft: http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html.
Deluge does, Pidgin does not... just tested this. Anyway, what's the use of this "feature"? If the window is open anyway, clicking it to rise would be way easier than to click the tray icon?
It's for windows that may be behind others. Take Pidgin, or Banshee in Mini Mode: clicking the tray icon presents the window, at which point it can be hidden. It's certainly an issue maybe as divided as vi vs. emacs. :P Closing it here, as Aaron and company have obviously chosen in their code.
(In reply to comment #6) > It's for windows that may be behind others. Take Pidgin, or Banshee in Mini > Mode: clicking the tray icon presents the window, at which point it can be > hidden. Again, Pidgin does *not* work this way. The "right" way would be to have a check if the window is already on top (don't know if that is possible). > It's certainly an issue maybe as divided as vi vs. emacs. :P Closing it here, > as Aaron and company have obviously chosen in their code. ...and not ever commented on this bug :( Well, perhaps this will magically change when trunk supports this feature...
It would be possible to check if the window is *focused*, which I think is what's already happening. I don't know about it being on top AND unfocused though. Does the problem only happen when "Select windows when the mouse moves over them" is active?