On Thursday 19 January 2006 15:15, Tuomo Valkonen wrote: > On 2006-01-19, Lubos Lunak <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] , [EMAIL PROTECTED] Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
