Re: Do-not-disturb protocol

[Tuomo Valkonen <tuomov iki fi>]

On 2006-01-19, Lubos Lunak <l lunak suse cz> wrote:
>  There is, $DESKTOP_STARTUP_ID, see the spec. These being set from a terminal 
> would require the shell having support for the spec though.

I seem to have missed this scanning through the first time. Actually, with
only the client-generated identifier being communicated with the environment
variable and the rest directly to the WM by the launcher, programs that
don't support the specification are not such big a problem, as the startup
information can be discarded after a timeout.

As a further note, I don't really like the launchee having to free the 
stored sequence. I think it would be good to let the WM consider the
sequence obsolete after the last window using it has been unmapped, or
something like that. 

Another interesting addition would be a _NET_WM_HERE or some such property
(or maybe request/client message?) containing a startup sequence, possibly
with WM-specific keys that the WM could set on client windows, so that
programs that occasionally open windows, but stay on the background most of
the time or some similar scenario, could remember their previous placement.

>> Ion needs to know which windows were launched from which for "smart" window
>> placement. If a program in frame A launches a program, and while it is
>> starting up, I switch to frame B, I would still usually want the window to
>> go in frame A instead of the active frame B when it is finally mapped.
>> In a more conventional WM one would probably usually want the new window
>> on the same workspace as the launcher.
>
>  That could be added to the spec if it makes sense. Which I think it does. I'm 
> not exactly sure how to do that identification though.

I think the startup sequence stuff pretty much does what I need, with the
addition of a LAUNCHED_BY key pointing to the window ID of the launcher
top-level window. Alternatively, the launcher could query the WM first for
where it would want to place a new window launched from the requestor, and
pass this information (containing WM-specific keys) back. (This is not
necessarily the same as _NET_WM_HERE above, although it would be in Ion's
tiled workspaces' current architechture.)

>  BTW, you could also use your own very-specific-hints-for-the-ion-desktop. 

And have all the programs support them? Not going to happen. It's best to
do all that can be done with very general hints that aren't tied to a
particular UI model.

-- 
Tuomo