On 2006-01-19, Lubos Lunak <[EMAIL PROTECTED]> 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. > 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. >> 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. _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.) > 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. >> 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. -- Tuomo _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
