_NET_WM_HERE (was Re: Do-not-disturb protocol)

[Lubos Lunak <l lunak suse cz>]

 Let's keep this stuff separately.

On Friday 20 January 2006 19:33, Tuomo Valkonen wrote:
> On 2006-01-20, Lubos Lunak <l lunak suse cz> wrote:
> >  And I'm not sure what specific use cases for this would be. Normal apps
> > don't need this, they always have a window.
>
> E.g. some IM stuff may pop up a window when a message arrives, and the user
> might want it to appear at a stored position.

 And some other user might not, and yet another might want this feature for 
some other app. That's why things like this are configurable in the WM.

> The property could also be used to store positioning information over
> invocations of the program. Many programs do that now, but only for
> geometry. (At least in Windows. I haven't done any real work in non-tiled
> WMs in ages.)
>
> >  Which applications would you expect to actually implement support for
> > _NET_WM_HERE then?
>
> Preferably all. I'm divided on whether the programs themselves should
> support an option to allow the user to decide whether to actually use
> this information, or whether them WM should do that (by not giving any
> usable information unless the user has requested from the WM that the
> position should be saved.)

 Well, first of all, I disagree with the preferably all part. Most apps seem 
to do just fine with wherever the WM puts them and they should at most 
remember their size.

 Saving window position in apps has the problem that those apps can never know 
as much as the WM. Consider virtual desktops, for example. Some may have them 
for separate tasks, then it should be remembered. Others have virtual 
desktops simply as a way of having more space, and there it shouldn't be 
remembered, perhaps with an exception for few apps. The app either can't know 
or it has to have special support for it. And now Ion tiles or whatever come 
into the play and it's all over again.

> WM_CLASS/ROLE doesn't do the same thing, as it isn't usually unique for each
> window. Session management is closer, but it only works over entire stored
> sessions.

 But CLASS/ROLE should uniquely identify a window within an application. If 
some app can't get this right I don't think it'd get something else similar 
right either.

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