Re: Toolbar window type behaviour

[Lubos Lunak <l lunak suse cz>]

On Saturday 04 of December 2004 04:25, Billy Biggs wrote:
>   SWT is a cross-platform wrapper toolkit.  One of our hints for
> top-level windows is "SWT.TOOL", which is supposed to indicate that the
> window is a floating toolbar.  The description of the hint says that
> these windows are sometimes given a smaller title bar.
>
>   I would like to map this to GDK_WINDOW_TYPE_HINT_TOOLBAR (which maps
> to _NET_WM_WINDOW_TYPE_TOOLBAR).  However, I am worried because when I
> tried this on metacity 2.8.1, I found that no title bar was given at all
> to the window.  The window did get a title bar on kwin 3.0 (KDE 3.3.0).

 It did with KWin? *checking* ... oh, really.

>
>   I assume that the metacity behaviour is because GNOME's detachable
> toolbars have their own handles.  However, this is problematic for our
> use, since SWT applications don't add handles, and if we added some they
> would be extraneous under kwin (and probably look silly).

 As far as I can tell, GNOME toolbars don't set the type hint at all. In fact 
I wonder if somebody actually really uses this thing (meaning both the hint 
and detached toolbars at all).

 You can remove the decoration from toolbars when using KWin by requesting a 
non-border window (e.g. using Motif hints). Detached toolbars from Qt also 
have their own handles, and remove KWin decorations this way.

>
>   So, I think we will map it to UTILITY even though at first it seemed
> like TOOLBAR would be more appropriate.  I think that it would be really
> nice though if the spec indicated which window types were expected to
> have handles.   By reading the spec I think it would have been easy for
> us to make the mistake of using TOOLBAR, only to discover that the
> windows are unmovable under certain window managers (what if it were
> less-known WMs than metacity which had this policy?).

 Then it would be that WM's policy to have unmovable toolbars, and it'd be 
their problem if they thought it'd be a good idea but it wasn't. I think 
everybody knows what a torn off toolbar is, IMHO it doesn't need more 
detailed description of what a toolbar is. But it's true such technical 
details like this should be specified if needed. Probably it could be said it 
should be like KWin does, it should have decorations, unless explicitly 
specified not to have them. However, note that WM-handled handles for 
detached toolbars have a problem with docking the toolbars back to the 
mainwindow.

-- 
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   http://www.suse.cz/