Re: Do-not-disturb protocol

[Tuomo Valkonen <tuomov iki fi>]

On 2006-01-20, Lubos Lunak <l lunak suse cz> wrote:
>  That's too late, this is only about startup, so the info is not useful after 
> that anyway, and for cases like the visual startup feedback you can't keep it 
> on so long. KDE works roughly like this:

What about programs that crash (before notifying that the startup sequence
is no longer needed)? Crashing is rather common these days. :(
I'm mostly thinking of memory leakage here.

>  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. (Of course, I don't like such
popups at all, and this should be done with a different notification system.)

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

>  LAUNCHED_BY
>
>  identification of the top-level window in which the launch was initiated. The 
> value is the X window ID of the window.
>
>  Better? You could've already written it this way.

Yes.

>> With the launching protocol and given application support for it, there's
>> no need for non-launcher applications to support the ion-specific stuff,
>> but with many other hints that is not the case.
>
>  Not sure what you're trying to say here, but if it's about adding 
> Ion-specific stuff to the specs, then I guess you could go with your private 
> fields for the startup spec after all. AFAICS the only launchers in Ion would 
> be either Ion itself, which is a launcher you can control, or apps, in which 
> case LAUNCHED_BY should be enough and you wouldn't need Ion equivalents of 
> DESKTOP.

I wasn't talking about the launching stuff there, but normal window
properties and protocols.

-- 
Tuomo