Re: incorrect interpretation of window types toolbar and menu

On Tuesday 02 of September 2003 00:09, Olivier Chapuis wrote:
> On Fri, Aug 29, 2003 at 04:02:26PM +0200, Lubos Lunak wrote:
> >  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?

> 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.

 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.

 "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. I think just specifying the window type should be enough, _if_ 
all WMs interpret the same window type reasonably similar. Which is IMHO 
currently not the case of TYPE_TOOLBAR.

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]