Re: [Usability] window manager configuration

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes: 
> OK, I think the wm-spec might sort of suck here.  There are really two types
> of panel with different desired behaviour.  There is the standard panel, and
> the autohide panel and panels that aren't on the edge.   The covering is
> handled by WM_STRUT so that's fine.  But what about the layer.  Autohidden
> panels MUST be always on top else it just doesn't work. 

Not on top of everything though - e.g. not on top of a presentation
program. That's why we need the semantic hints. :-/

> Use DOCK hint only for autohiden panels that are on the side or for the
> foobar, and use the TOOLBAR hint for all other panels.  Is this on
> crack?

Here is what the spec says:

       <para> _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU
    indicate toolbar and pinnable menu windows, respectively
    (i.e. toolbars and menus "torn off" from the main
    application). Windows of this type may set the WM_TRANSIENT_FOR
    hint indicating the main application window.</para>

So, the panel is not a torn-off toolbar. Putting decorations on a
torn-off toolbar probably makes sense, keeping it on top probably does
not, for example.

It's better to add a _GNOME_WINDOW_TYPE_AUTOHIDE_PANEL extension to
the spec than to reinterpret the existing spec. (The spec allows a
window to have a list of types, for this reason.)

> In any case.  We either do that or we always keep panels on top.  Note that
> always keeping all panels on top is crack I think, but may be acceptable.  In
> any case, DOCK hint doesn't do justice to panels.  I suppose if the
> windowmanager actually does things nicely, then always on top might not be
> that bad.  Unfortunatly I have not seen any wm to get it right.  Like for
> example sometimes placing window titles under the foobar or some
> such.

We have to rely on the WM getting it right, otherwise things will
always and eternally suck, because the WM is the only place there's
enough info to get it right. Thus, we need to get Federico to make it
work right. ;-)

> We can do the raise-on-mouseover on the panel ourselves in the panel and not
> bother then windowmanager I don't think.  Focus might be more fun, I think we
> don't want focus unless we click even in sloppy focus.  This is because it's
> not common to have panel focus and most of the time you don't want your other
> window to lose focus.  This may be complete crack.

No, I agree with that. The desktop behaves similarly (requires a click
to focus, even in sloppy).

Metacity does the raise-on-mouseover on the panel's behalf - I think
that's really the right thing, since the WM is where the keep-on-top
or whatever setting will live.

My thoughts on focus are a) click-to-focus for desktop elements such
as desktop/panel, even in sloppy mode b) there are also key shortcuts
in the WM to focus the desktop and to focus the panel.

> In any case I don't think it makes sense to make this configurable.  In 1.4
> we have a gazillion options in the panel for levels and maximize cover stuff,
> and it's just a mess.  I think we should pick one behaviour (it must be one
> which doesn't lead to annoying behaviour:) and stick with it.

My basic opinion is that stays on top is right for the panel, but that
as you say it relies heavily on the WM doing the right thing in order
to come out nicely. For people who don't want to lose screen real
estate, autohide is a good solution. If it's still popular to flame us
once all that is working right, then we can add a raise-on-mouseover
option.

After trying both on-top and raise-on-mouseover in Metacity, I don't
really like raise-on-mouseover because I'm always "losing" the panel,
and because it causes a flickery/unstable sensation. The on top would
have been good if I'd implemented proper maximize behavior and so
on. So I want to prototype the proper maximize behavior and then go
back to stays on top, and see how that is.

Havoc