Re: Still need a hint for undecorated windows

[Lubos Lunak <l lunak suse cz>]

On Friday 24 of June 2005 14:13, Carsten Haitzler wrote:
> On Fri, 24 Jun 2005 14:03:00 +0200 Lubos Lunak <l lunak suse cz> babbled:
> > On Friday 24 of June 2005 13:40, Carsten Haitzler wrote:
> > > On Fri, 24 Jun 2005 13:19:36 +0200 Lubos Lunak <l lunak suse cz> 
babbled:
> > > >  Yeah, and I'd want $100M and days to have at least 28 hours. That
> > > > said, it's questionable if either of this would be actually good for
> > > > me. And this still doesn't answer the "why?". There must be a reason
> > > > why them want it. So why?
> >
> >  still no answer ...
>
> they may want wm focus policy and the wm to handle hiding/whatever the
> window when flipping desktops but NOT have any wm control - NOT allow the
> window to be moved or resized... maybe they dont want to indicate any of
> this. maybe its displaying some kind of OSD that needs focus but wants the
> rest of what a wm provides. who knows.

 That sounds like a new window type. Hmm, actually that reminds me of 
_KDE_NET_WM_WINDOW_TYPE_OVERRIDE, which probably was meant to be something 
like this, although I've never really got what it was supposed to mean 
exactly. With its unclear semantics it got abused for so many things that I 
eventually made KWin ignore it completely except for treating it as another 
way of saying "noborder".

> >  Or at least we don't have anything better than taskbars and start menus.
> > There's nothing inherently wrong with taskbars and start menu, they may
> > have their problems, but they're more or less fine. That's not the case
> > with apps trying to provide their own wm controls just for the fun of it.
>
> what if someone has a new idea? they are working on it - the current
> semantic types dont fit - or a semantic type fits but the idea is a slight
> variation where that window is to be borderless? WITHOUT explicit
> borderless hints such development of the client would be hard or impossible
> as it would mean wm hacking. :)

 But wouldn't wm hacking be the right way of developing the idea? I'm actually 
not strictly against the noborder hint. If somebody comes up with a good 
reason why it should be in the spec, I'll support it to be in the spec. But 
so far the best reasons have been "xmms" and "users are used to it that way", 
which I don't find quite convincing. Especially given that I fear the 
noborder hint would be a precedent "yes, it's ok if you try to abuse things, 
do it your way and screw the WM".

 Take TYPE_SPLASH for example - had we had the noborder hint since the 
beginning this one would probably never come - apps we'd just make it a 
normal noborder window. And I actually really use this type in KWin for some 
things. Noborder windows I can think of are either normal windows a'la xmms, 
for which I still see no reason to give them a say about the decorations, or 
something that should be actually a separate window type, and then it's 
better to have them as a separate window type.

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