Re: incorrect interpretation of window types toolbar and menu

[Olivier Chapuis <olivier chapuis free fr>]

On Thu, Sep 04, 2003 at 02:07:19PM +0200, Lubos Lunak wrote:
> On Tuesday 02 of September 2003 00:09, Olivier Chapuis wrote:
> > On Fri, Aug 29, 2003 at 04:02:26PM +0200, Lubos Lunak wrote:
> [snip]
> > >  Toolbars second - that's not as bad. If you actually manage to find
> > > something that has tear-off toolbars and sets the window type on them,
> > > you'll get no, one or two decorations depending on what you use. Could we
> > > please agree how to decorate them? I think I already asked about this
> > > here once, but I can't find it in the archives :(. I also don't remember
> > > what conclusion there was, if any.
> >
> > If I well understand the ewmh spec we cannot add something like: "window
> > of _NET_WM_WINDOW_TYPE foo SHOULD be decorate like this and like this".
> > From the spec:
> >
> >   Rationale: This hint [_NET_WM_WINDOW_TYPE] is intended to replace the
> >   MOTIF hints. One of the objections to the MOTIF hints is that they are
> >   a purely visual description of the window decoration. By describing
> >   the function of the window, the Window Manager can apply consistent
> >   decoration and behavior to windows of the same type. Possible examples
> >   of behavior include keeping dock/panels on top or allowing pinnable
> >   menus / toolbars to only be hidden when another window has focus
> >   (NextStep style).
> >
> 
>  Exactly. But I don't want any "TYPE_TOOLBAR should be decorated like this and 
> this". I want only "TYPE_TOOLBAR should be or should not be decorated". The 
> purpose of this spec is to standardize the handling of windows. And if half 
> of WMs put decorations around toolbars, the other does not, half of toolkits 
> create their own and the other don't, something is wrong.
> 
>  BTW, have you noticed you contradict the cited part from the spec when 
> proposing the MOTIF hints below?
>

Hey, I do not wrote the ewmh spec. By the way _NET_WM_WINDOW_TYPE
always trouble me.

> > I think that if an application really need a specific decoration it
> > should use MOTIF hints.  For example, I see no reason _a priori_ to do
> > not put a border around a DOCK (e.g., I can double click on the border
> > to shade down this DOCK). However, a dock which looks like the GNOME
> > or KDE panel with a/two hiding button(s), should not be decorated.
> > Indeed, kicker and gnome-panel use MOTIF hints.  You give an other
> > example with the TOOLBAR's: maybe some toolkits will want a decoration
> > around a TOOLBAR and others not ...
> 
>  I disagree. There's only one kind of floating toolbars, which is floating 
> toolbars. If we decide one way standard way of handling them, e.g. on WM 
> being the one providing the decoration and also providing a titlebar button 
> for docking the toolbar back into the mainwindow as I suggested, I don't see 
> any reason why anybody would really want some other special kind of toolbars. 
> We build on top of ICCCM, but we don't necessarily have to be the same way so 
> awfully vague on everything.
>

Really I've no opinion on this (decorate or not the TOOLBAR).  Toolkit
developpers should decide. But if a decision is taken and the toolbars
really need decorations or no decoration, this must be expelcit in the
spec.

>  Perhaps there's no reason _a priori_ to not put a border around a DOCK, but 
> if you do, you'll have something different from the usual understanding of 
> type DOCK. You'll be suddenly able to move them, resize them, and whatever. I 
> don't consider something like that to be DOCK.
> 

Again if DOCK apps should not be movable, resizable or decorated,
then this should be specified in the spec.

About decor and window operations: A lot of wm can start window ops
on not decorated windows and can forbid some window ops on decorated
window.

About resize: you can specify that an app should not be resizable by
using size hints. Moreover, I do not see why a DOCK should not be
resizable. For example, kicker supports several sizes you can use the
sizes hints to specify these sizes.

About moving: gkrellm uses the DOCK type and it should be movable. If
xfce want to use the EWMH spec (the xfce panel works fine with any
GNOME1 compliant wm) the xfce panel should be of type DOCK? But the
xfce panel as some grip to allow to move it. What about moving a
kicker/gnome-panel like apps? You move it and when the operation is
terminated it "auto stick" to the closer edge of the screen. Note,
that you can "forbid" moving by using MOTIF hints.

If DOCK means kicker or gnome-plane or "mac-menu", fine no decoration
and others constraints. But what about a stand alone pager (as kpager)
or task bar, a panel which does not take the full width (height) of
the screen a without hiding buttons. I do not see why we should not
decorate such windows with a border and no title (and this can be
really useful, e.g., I want to resize easily my task bar when the nbr
of apps on my desk become big). If all these apps are not DOCK, I I
think that a new window type is needed (or maybe 2). I do not think
that UTILITY is always ok. An utility as a "palette or toolbox" want a
title bar and do not want to be ontop (I think) and sticky. 

>  "By describing the function of the window, the Window Manager can apply 
> CONSISTENT DECORATION AND BEHAVIOUR to windows of the same type." - one 
> sentence from your citing of the spec, emphasis mine.
> 
> > Maybe the ewmh spec can document the MOTIF hints and allow
> > applications to use it if they _really_ need it. It is clear that
> > describing the "function" of a window is better than a "visual
> > description". However, I do not think that _adding_ a visual
> > description is a bad idea.
> 
>  You mean those MOTIF hints that some people here laugh at ;) ? It's not the 
> application's job to tell the WM which buttons exactly may or may not be in 
> its titlebar.

GNOME and KDE use MOTIF decorations hints (at least for kicker and
gnome-panel). They are surely not perfect but they work with a lot of
wm. If an application really do not want decoration or really need to
be not moved and this application is not of a TYPE that force this,
what it should do?

I am not for "this" or against "that". I just think that window
type is a good idea, but that decorations and "forbid actions"
hints (MOTIF or new _NET one) may help to solve problems (one will
be the multiplication of the window types).
 
> I think just specifying the window type should be enough, _if_ 
> all WMs interpret the same window type reasonably similar.

If you want that _all_ ewmh compliant wm apply the same decorations
for the various window type you should specify these decorations in
the spec. If DOCK implies no decoration and not movable this must be
in the spec. If TOOLBAR implies decoration this should be in the spec.

Regards, Olivier