GNOME Bugzilla – Bug 160470
Hiding a panel shouldn't change the window focus to the panel
Last modified: 2005-01-09 19:44:37 UTC
Distribution: Fedora Core release 3 (Heidelberg) Package: metacity Severity: enhancement Version: GNOME2.8.0 2.8.x Gnome-Distributor: Red Hat, Inc Synopsis: Hiding a panel shouldn't change the window focus to the panel Bugzilla-Product: metacity Bugzilla-Component: general Bugzilla-Version: 2.8.x Description: Please describe your feature request: I'd be cool if I could do things with the keyboard in a window and then, when I had to collapse a panel, I could do it with the mouse and go back to the keyboard without having to refocus on the window I was working in. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-12-04 19:59 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "metacity". Setting to default milestone for this product, '---' Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
This is planned; I've already written quite a bit of code for it. The metacity side is actually almost trivial. However, it requires changes to applets and/or the panel. The method was discussed on wm-spec-list a few months ago with the biggest problem being to get the GDK_WINDOW_XID of the containing panel to each applet so the applet can set _NET_ACTIVE_WINDOW if necessary (it appears that it couldn't be done in libpanel-applet). Anyway, I've been loaded with school work (and what little time I've had I've put into the bugsquad and bugzilla to get them in shape) so my patches have been gathering dust on my machine(s) for a couple months. When the semester ends soon, this is early on my list...
Created attachment 35024 [details] [review] Don't focus panels The idea for this patch came from Lubos on the wm-spec-list--see the last couple paragraphs of http://mail.gnome.org/archives/wm-spec-list/2004-October/msg00005.html. So, in addition to solving the problems the reporter mentioned here and the remaining ones in bug 100470, it increases interoperability of KDE and Gnome. I'll handle pinging the gnome-panel & gnome-applet maintainers and continue working on patches for the few cases where they'd need to make a _NET_ACTIVE_WINDOW call...
Comment on attachment 35024 [details] [review] Don't focus panels Should we still raise the panel on click, in case you get two overlapping panels or something? I wouldn't want to commit this until we have the panel patches ready to go or people will get all grumpy...
/me wonders why he didn't get bugzilla email from Havoc's change above, but did get bugzilla email for all the other bugs last night. Oh, well. Good point, yeah we should raise. It only affects people using keyboard text-entry applets (of which the only two I am aware of are the dictionary or command line applets, meaning that only people like me are affected), so I'm kind of worried that if we wait then it may be decided that these bugs just aren't high enough priority to warrant fixing. For the curious, the other bugs can be found in bug 161735 and its dependencies.
Reminder to self: Also, we need to update the doc/how-to-get-focus-right.txt document with this change...
I guess I just want to be sure there's a plan for the panel - we don't want to patch metacity then find out the panel fix is really hard for some reason.
Created attachment 35073 [details] [review] Updated--do raise panels on click. Also, update documentation
Reminder to self: When this is applied, we should probably go back and undo the temporary hack in bug 128200.
One thing I have trouble understanding is, if we're not going to do anything with these ButtonPresses on DOCK windows (i.e. we don't focus, move or resize them) why do we grab the buttons at all on these windows? (Oh hold on, we raise the window - is that the only reason, then?)
Update: Patches have been written, tested, and submitted for bug 161735 and each of its dependencies... :-) (Mark: I believe that's the only reason, yes, but I'll defer to Havoc since he's more familiar with the part of the code relating to the grabs)
Well, if we didn't grab it'd be a big special case in metacity, not really worth it. Plus we do raise. Also, it'd potentially break things to turn on the grab later if it wasn't on at first (e.g. the bug about getting leave notify on click when you have a grab)
Havoc: the patches have been committed for libpanel-applet, gdict, and mini-commander. Is the Metacity patch okay to commit now?
I'm committing the last attached patch so that it can be in the tarball release that's due soon; kick me if I wasn't supposed to do that.