Re: Do-not-disturb protocol

[Lubos Lunak <l lunak suse cz>]

On Thursday 19 January 2006 15:15, Tuomo Valkonen wrote:
> 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.

 Not really, there can be problems even with apps not supporting it. In KDE 
the basic use of the spec is showing feedback that some application is being 
launched - failing to detect properly the end of a startup means the visual 
feedback is still there. Even focus stealing prevention can be problem, e.g. 
the already mentioned Mozilla problem - you have it already running, launch a 
new one, it tells the running instance to open a new window but doesn't also 
forward the startup id - without knowing the new window belongs to that 
startup, the WM has to consider this an unwanted activity from an application 
running in the background. The solution here is either to add the support to 
the apps or selectively disable the feature for them.

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

 I think that this, just like your criticism of some parts of the EWMH, stems 
from the fact that you have only the Ion view of the desktop and don't 
understand how larger desktops like KDE work. With Ion 
(Windowmaker,Blackbox,...) you have only the WM and the applications. With 
KDE(GNOME,Xfce,...) you have several separate components, moreover usually 
interchangeable.

 When going over the KDE implementation when designing the spec we were 
thinking about this too, IIRC Havoc originally wanted to have the information 
about the startup sequence to be properties on some X window that'd be 
cleaned up after the sequence is done. But we had a problem with deciding who 
should be the responsible one, e.g. in KDE not only KWin uses the startup 
information, but also the desktop and panel use it to provide feedback, all 3 
being separate processes. And launcher can't be made responsible either 
because it may be already gone.

 We eventually stayed with sending the messages, which means everybody is 
responsible only for their resources and the startup sequence itself doesn't 
have any, so there's no "stored sequence" (that on the other hand has other 
problems like not being able to find out the information after it has been 
already sent, oh well). This way everybody involved has to keep their own 
data and can take some action whenever they feel like it if the app fails to 
send "I'm ready".

 And BTW, the startup sequence is finished by the time the application is 
considered to be up and running, not when the app exits.

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

 I don't understand what you mean here.

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

 Say, something like this?

 LAUNCHED_BY

 identification of the application that initiated the launch (not necessarily 
launcher if there's e.g. a separate launcher application that all 
applications use). The value is the X window ID of the application's 
top-level window.

 Fine with me.

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

 That's how DESKTOP currently works. And I'm not sure it'd have to be 
alternatively. LAUNCHED_BY seems to be a better approach, it's more generic 
and actually implicitly carries all the information. However, LAUNCHED_BY  
only works as long as there's a valid value for it. If I launch an 
application e.g. by clicking an icon on KDE's panel then LAUNCHED_BY 
shouldn't point to the panel. Theoretical reason being the fact that the 
panel is no application from the normal point of view, practical reason being 
that if I click the icon and then switch to another virtual desktop, I still 
want the application to appear on the old one.

 I see no other way than including such info directly. And I don't think there 
would be a problem adding more things from the EWMH to the startup spec.

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

 Not all programs, just launchers, and there aren't that many of them (well, 
at least definitely less than all programs). If you want your Ion specific UI 
model supported, I guess you'll have to add it to the EWMH ;).

> It's best to do all that can be done with very general hints that aren't
> tied to a particular UI model.

 This is again failing to see one of the points of EWMH. You see it only as a 
way of communicating between apps and the WM, but the other half is that it's 
also about communicating between the WM and other components of the desktop. 
No normal app is supposed to mess with e.g. _NET_WM_STATE_SHADED, but in KDE 
the panel pager (or the KPager app) are separate from the WM, and they need 
to communicate the status somehow. And given that somebody may want to run 
e.g. GNOME with KWin as the WM and some pager app from freshmeat, this needs 
a common spec for the communication. Get it? You don't have to implement all 
of the EWMH, nobody does. But if you want your WM to communicate with more 
than just itself, e.g. like above, having it in the EWMH helps.

PS: As I already said, implementing some parts of the startup spec is not 
exactly trivial, so if you decide to give it a go, don't be afraid to ask.

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