GNOME Bugzilla – Bug 308632
Last launcher/applets get highlighted/focused when opening the menu
Last modified: 2008-08-04 02:34:13 UTC
This bug has been opened here: https://bugzilla.ubuntu.com/12084 "I really don't know how to describe this bug, so I simply describe what happens: 1. Click on any launcher on the top panel 2. Click on any menu on the top panel 3. Observe that the launcher icon was also "selected" by being highlighted and having a dotted box drawn around it"
I can confirm this, but I'm not sure it's even a bug... Can anyone comment? Vincent?
Yup, it's a bug.
*** Bug 345136 has been marked as a duplicate of this bug. ***
*** Bug 338350 has been marked as a duplicate of this bug. ***
URL is now: https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/18361
*** Bug 383146 has been marked as a duplicate of this bug. ***
*** Bug 378887 has been marked as a duplicate of this bug. ***
I had never seen this bug before until I installed Ubuntu Gutsy Alpha 4. This bug suddenly appeared. Please see https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/18361 for screenshots of the problem under two different circumstances (it either draws a dotted selection box around the menu panel or draws one around the last menu panel item clicked on and highlights it).
*** Bug 441266 has been marked as a duplicate of this bug. ***
1. The entire issue seems to be a bit more complex: We don't have a policy for the interaction between mouse clicks and a keyboard focus. At the moment, the applets can be divided into a few groups: (A) Cannot receive any keyboard focus (I haven't seen any, though) (B) Can receive keyboard focus, keyboard focus will be grabbed on mouse click (launchers) (C) Can receive keyboard focus, keyboard focus will not be grabbed on mouse click (menu and many others) Those that can receive a keyboard focus can also be divided into drawing the focus indicator, and those not drawing it. 2. Unified keyboard focus policy / GTK+ problems Regarding a unified policy, I'd propose to adopt the policy that GtkTreeView seems to use for its cells: * Mouse-clicks: Keyboard focus is taken but the focus indicator is not drawn * Keyboard presses: Keyboard focus is taken/moved and the focus indicator is drawn However, implementing this for GTK+-derived widgets ourselves for all applets is totally tedious and will just cause lots of sick and buggy code. The problem is that GTK+ assumes that all widgets having the keyboard focus want a focus indicator to be drawn. This is wrong. Thus, we should have a GTK+ widget property that allows us to disable focus drawing even for focused widgets. We can also implement it as a widget flag (cf. GTK_TREE_VIEW_DRAW_KEYFOCUS). 3. Long short story A satisfying solution with a decent focus policy without any GTK+ changes is just to complex and tedious. For the moment, a workaround would be to not grab the keyboard focus when clicking a launcher. Dual keyboard/mouse users might not be happy, but there is no keyboard focus policy, and some applets are broken anyway. best regards, Christian Neumair
Created attachment 107229 [details] [review] Proposed (workaround) patch This patch is a workaround. It will prevent the panel from giving the keyboard focus to launchers on click, and so no frame will be drawn.
*** Bug 543473 has been marked as a duplicate of this bug. ***
This patch only worked for launchers, but wasn't working for applets. I fixed it by giving focus to no child of the panel when the menu is opened.