Re: panel focus

["Padraig O'Briain" <Padraig Obriain sun com>]

It seems to me that Seth is asking that the GTK_CAN_FOCUS flag not be set on 
objects on the panel, except in very limited circumstances.

The problem at present is that when a button on the panel is pressed, it 
receives focus as the button press signal handler calls gtk_widget_grab_focus() 
and the GTK_CAN_FOCUS flasg is set.

One possible solution could be to unset the GTK_CAN_FOCUS flag fopr all objects 
on the panel when the window loses focus and set the flag when the window 
receives focus. I will investigate this further.

Padraig

> 
> > > However I do think that if you click on the panel, your app window
> > > should defocus; otherwise we are violating the premise that the panel
> > > is just a "special app" rather than a part of the WM.
> > 
> > I think the more salient point here is that if we don't defocus the app
> > window when a panel or panel object has focus, it gives a misleading
> > visual cue that the app is still receiving keyboard focus, which it most
> > certainly isn't-- the panel is, and no amount of jiggery-pokery will
> > send your keypresses to the apparently-focused application.
> 
> No disagreement here. I don't think anybody is contending with the
> notion that when the (keyboard, or otherwise) focus is on the panel, the
> window should be drawn unfocused. The issue is *when* should the panel
> be focused. My opinion on that is "as little as possible".
> 
> If we really need to focus the panel, for example so somebody can type
> in a text box on the panel (say the command line applet), we have to
> focus the panel, NBD. But in most cases we don't really need to focus
> the panel. I'm not exactly sure how to give an abstract description of
> when the panel should or shouldn't be focused, but I can give a list of
> examples.
> 
> Cases where the focus should stay on the window that was active when the
> panel operation was started:
> 
> Adjusting the volume with the volume control applet.
> Pulling up the right click menu on any applet
> Clicking a launcher on the panel or in the menus (eventually a new app
> will come up, yes, but until such time I think the previously focused
> window should be focused)
> Clicking on the "Applications" menu and then pressing "esc"
> Clicking "next track" on the CD player applet
> Bringing up any menu on the panel and pressing "esc"
> 
> Cases where the panel should take the focus:
> 
> Clicking in a text box in an applet (say the command line applet)
> Clicking directly on the panel itself (*not* dragging)
> Whatever the magic keyboard shortcut is for focusing the panel
> 
> GNOME 1 *almost* does this, with the caveat that it temporarily
> unfocuses the window while system modal things like menus are selected,
> though the focus goes back to the window when you are done. The GNOME2
> panel used to work like this until the keyboard nav and prelighting
> changes were made. I would prefer that these work like application-local
> menus (so the application stays focused), but I don't think this is
> nearly as important as where the focus is when you are done.
> 
> Basically the long and short is that the panel would never take focus
> unless it needs focus to allow you to use a particular widget in an
> applet. This makes the panel seem light, and allows the user to mix
> interaction with the panel with window interaction. The panel ain't a
> window, and IMO has very little reason to have the heavy focus that a
> window has, and makes the interface feel better if it doesn't have heavy
> focus normally.
> 
> For users who do not need keyboard nav, I believe that a focus-avoiding
> panel is much better than a panel that grabs focus. There's simply no
> benefit to most users when the panel steals the focus from the window.
> For users who need keynav to navigate the panel, they're going to be
> using keyboard anyway, so having keyboard operations focus the panel
> should be enough, right? I doubt there's going to be anyone who uses the
> mouse to click on a panel applet to do something, and then really needs
> to move around the panel using keynav.
> 
> Basically, I think this accessibility change is bad. I think the old
> behavior was much better, and I don't think as much change was necessary
> from the old behavior as was made. IMO, all you need is a way of
> focusing the panel using the keyboard (which as I understand it is
> necessary anyway), and this change shouldn't have to impact mouse usage
> at all.
> 
> A side issue is how the panel indicates focus. I care much much less
> about this issue if the panel weren't so eagre to grab focus, but its
> worth noting that prelighting is broken if it passes it on to child
> widgets (i.e. the applets). I don't know if its possible to prevent
> this. GTK specifies that prelighting happens when "the mouse is over a
> widget". Some applets, sanely enough, assume this behavior. So for
> example menubars focus all their top level menu widgets when the panel
> prelights! This will be a serious issue if we try to use a menubar
> applet post GNOME 2.0. But once again, if the panel isn't so easy to
> accidentally focus, I don't care very much.
> 
> cheers,
> 
> -Seth
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list