Re: Do-not-disturb protocol

[Lubos Lunak <l lunak suse cz>]

On Thursday 19 January 2006 17:42, Tuomo Valkonen wrote:
> On 2006-01-19, Lubos Lunak <l lunak suse cz> wrote:
> >  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.
>
> Such things should be separated into separate pager specs etc., not all
> lumped together. Helps keep the application writers from abusing the stuff
> too. As far as the applications are concerned, there should be just an
> abstract window manager, whether it consists of one or 10 components.

 Well, I guess that when creating the spec this problem didn't occur to 
anybody, or perhaps this didn't occur to be a problem to anybody. And I guess 
nobody will feel bothered enough to split EWMH into EWMH-for-apps and 
EWMH-for-wms. Sometimes the distinction is even not exactly clear - e.g. app X 
usually shouldn't care about which virtual desktop is the active one, but if 
it wants to launch another app it suddenly needs to know it in order to 
include DESKTOP in the startup info (at least as long as there's no 
LAUNCHED_BY in the spec). It could use at least some cleanup, but that'd need 
somebody to do it.

> > 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".
>
> What I meant is that the spec doesn't say when the WM or whatever should be
> free to consider the information dead and thus to free it from its own
> storage, if no explicit removal message is received. I think the last
> window using the information being unmapped or perhaps destroyed is such a
> situation that should be specified.

 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:

- Normal app - launch, kicker/kdesktop show launch feedback, when a matching 
window (or windows) is mapped, kwin applies DESKTOP (and whatever it sees 
fit). This keeps going on until something (which should be the app) sends 
"finish", or there's a timeout (reasonable hardcoded value, more or less), 
after that kwin etc. just forget everything about the startup.

- App that can be handled using StartupWMClass in .desktop file - launch, 
launcher together with all the startup info also sends WMCLASS, 
kicker/kdesktop show launch feedback. When a first window with matching 
WM_CLASS (and without _NET_STARTUP_ID set) is mapped, it's considered 
equivalent to getting "finish" (and kwin before it still handles the window). 
The rest is same like above.

- Apps that don't work - StartupNotify=false in .desktop file, no startup info 
at all. Actually I think there is startup too, but with SILENT=1, so there's 
not the annoying visual feedback - this helps with DESKTOP still working. But 
just not doing anything is a viable strategy too :).

 That's the simple part. The hard part is getting focus stealing prevention to 
work and moving apps to the topmost position in the list above.

> _NET_WM_HERE would give the application the information with which it
> can place new windows where it used to have a window, possibly by setting
> up a startup sequence (to not add any redundant properties). If it were a
> client message, I guess other programs could return whatever info they
> have as well.
>
> Plain old messy pile of papers on the desk -wm:
>
> _NET_WM_HERE='MPPDWM_GEOMETRY=(x,y,w,h) DESKTOP=foobar'
>
> Ion:
>
> _NET_WM_HERE='ION_FRAME="WFrame<12>" ION_FRAME_POSITION=4'
>
> (the position within frame could be encoded in a better manner, if
> it is even considered useful to use that information.)

 I see. I couldn't see any relation to the startup spec, and actually I still 
don't see it, I don't think there's a point in having startup notification 
just for opening a new window. So this should be a property, not part of 
startup notification, and it's something separate from this discussion.

 And I'm not sure what specific use cases for this would be. Normal apps don't 
need this, they always have a window. Most background KDE applications I can 
think of either open windows for other applications, so there you want that 
window to be opened with the other window, or open windows that I'd say are 
completely separate (new media inserted dialog, etc.), so there again they 
should open normally and not where the last one was. And if you want all such 
windows open in a specific place, the WM can be simply configured so.

 Which applications would you expect to actually implement support for 
_NET_WM_HERE then?

> >  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.
>
> Not the application, but the (top-level) window an action in which
> initiated the launch, if there is one. A browser application may, for
> example, have multiple windows on different workspaces (or frames), and one
> wants to display the postscript viewer that activating a link launched on
> the same one where that browser window is (or was). So this property should
> be the window ID of that browser window.

 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.

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

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