Re: Problem with sawfish and GNOME global menus

[Harald van Dijk <harald gigawatt nl>]

On Mon, 2010-12-20 at 03:38 +0200, Michal Maruska wrote:
> > sawfish focus the GNOME panel when clicking on it. metacity and openbox make
> > dock type windows unfocusable.
> 
> when I run xprop on the gnome panel, I see:
> 
> WM_HINTS(WM_HINTS):
>                 Client accepts input or input focus: True
> 
> Is this wrong?

That is what it says on my system too, and that is why I still needed to
force "never focus" to true even with the patch. gnome-panel or the
global menu bar applet needs to give the proper notification so that the
WM knows the panel should not be focusable, rather than hoping that all
WMs behave as metacity or openbox.

> For some reason, I have been using
> focus_in()
> ....
>     if ((ev->xfocus.mode == NotifyGrab)
>         || (ev->xfocus.mode == NotifyUngrab))
>         return;
> 
> without any problems  (with focus-mode click).
> 
> But still, if you have some Grabbing client (password input, ...) you
> lose the feedback from the WM (framing).

In this case, losing the feedback is desired. When the menu grabs focus,
the application window should keep the active title bar colour. The only
other example I have handy of an application grabbing keyboard focus is,
again, the GNOME panel: I have this in my .sawfish/rc:

(define (gnome-main-menu)
  (ungrab-keyboard)
  (send-client-message (get-window-by-class "Gnome-panel")
'_GNOME_PANEL_ACTION (vector (x-atom '_GNOME_PANEL_ACTION_MAIN_MENU) 0)
32))

(define-command 'gnome-main-menu gnome-main-menu)

and bound gnome-main-menu to Alt-F1 (as in metacity). When I press it,
the menu opens. When I then press Escape, I want to focus to revert to
the window that last had it. I don't want the focus to be on the panel
containing the menu button. But, to be honest, I have added this to my
sawfishrc only after getting the global menu bar working, so I am unsure
how it behaved with an unpatched sawfish.

I don't have an example handy of an application that grabs the focus in
this manner and where the a WM response is desirable, but if you have
one, I'll be happy to take a look and see if there is any way to update
the patch to handle both cases correctly.

Cheers,
Harald