On 2005-04-21, Evgeny Chukreev <[EMAIL PROTECTED]> wrote: > On Fri, 11 Mar 2005 16:37:25 +0200 > Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > > TV> The number of remaining major changes planed for Ion3 becoming small, > TV> it's time for another Ion3 wishlist inquiry. > Full EWMH support?
See below. (Mail archive seems to no longer carry the old list, and gmane search isn't responding...) On 2004-02-23, Tuomo Valkonen <[EMAIL PROTECTED]> wrote: > On Mon, Feb 23, 2004 at 03:12:33AM -0500, Mike wrote: > > Requires EWMH... I seem to recall reading Tuomo's opinion on this > > standard... I believe he called it "brain damaged," I am not familiar > > with the details, perhaps someone can englighten us (me?) as to the > > problems... only concern i see is that it seems to be very much > > oriented toward a "standard" floatWS like environment. > > There are a couple of useful hints, lots of useless over-engineered > "modern desktop" and pager crap, and at least one totally brain-damaged > hint. > > Ion currently supports the following subset: > > _NET_WM_NAME > UTF8 titles > _NET_WM_STATE == _NET_WM_STATE_FULLSCREEN > The proper way to for applications go to full screen mode, > ask the wm to do it > _NET_VIRTUAL_ROOTS > This was originally intended to list "virtual root windows" for > separate workspaces, but Ion uses it to list the virtual root > window it creates for each Xinerama screen to get around > Xinerama's root window sharing. > > And of course the couple properties that are used to indicate WM > support. > > The _NET_WM_PID property together with WM_CLIENT_MACHINE might be useful > if more programs supported it. > > The workspace/"desktop" properties do not map nicely to Ion as not > all our "workspaces" are actually workspaces but single client windows > in full screen mode. > > I don't see a point in generic pager support as they are very tied to > how the window manager manages windows. > > There's no point in apps supporting moving/resizing themselves, so there' > no need for a _NET_MW_MOVERESIZE message, although it is better than the > apps just doing it all by themselves. > > Getting to the over-engineered part, there are a lot of "modern desktop" > window state/type properties that should not be supported by any WM. The > ICCCM is enough. Shaded or iconified, what does it matter? And yet there's > no state for just being unviewable, although telling apps the window is > iconified is more than sufficient. All transients should essentially be > modal, period. The program has no need to control stacking or the appereance > of windows in different lists. What little use I can imagine for these > could be replaced with more abstract hints, for example, some of those in > _NET_WM_WINDOW_TYPE. Although it is in principle a good property, most > of the _NET_WM_WINDOW_TYPEs, esp. -DESKTOP, -MENU and -TOOLBAR should > never be used, IMO. > > Now to the totally brain-damaged part: > > > > > Setting the ICCCM WM_TRANSIENT_FOR property to None or the root > window means that the window is transient to a whole group of > windows. This is an absolutely perveted notion, and also in > violation of the ICCCM. > > > > > -- > Tuomo -- Tuomo
