On Wed, 7 Oct 2009 15:40:13 -0700 Michael Jennings <m...@kainx.org> said:
> On Wednesday, 07 October 2009, at 14:06:34 (+0200), > hannes.janet...@gmail.com wrote: > > > yes, Eterm becomes an override-redirect window when using borderless > > option with e17, so its window is not handled by the wm in any > > way. I commited a workaround that makes e17 pretend to be mwm so > > that Eterm use mwm hints for borderless mode instead of going > > override redirect. > > Okay, let's get something straight here. You keep implying that Eterm > is somehow buggy because it expects the WM to "pretend to be" the > Motif WM in order to do borderless. This is simply wrong. > > Setting _MOTIF_WM_INFO is the correct way to advertise yourself as > supporting the MWM hints, at least to the best of my knowledge and > based on everything I've read or seen. Thus, a WM supporting those > hints should set this property. On my (albeit somewhat outdated) copy > of E 0.17, Eterm -x works just fine. And I'm quite certain it worked > on E 0.16, so I'd wager it works on e16 too. The only WM it doesn't > work on AFAICT is kwin. > > Falling back on override_redirect is the ONLY way that Eterm can be > certain it does as the user asks (comes up borderless) in the face of > non-compliant window managers. Which is the better failure mode > (ignore the user request and have borders vs. being outside the > control of the non-compliant WM) is a matter of perspective, and I'm > tending to agree with Marc Lehmann (urxvt) that the right choice for > Eterm is to do everything it can to fulfill the options it was given > (i.e., override_redirect if necessary). > > If there is an EWMH for borderless that I'm missing, please feel free > to add support for that. Beyond that, I think the previous code was > correct. ok. time to chime in. waaay waaay back... back in the early days. no one other than motif set those hints. many others understood them and did it so apps that asked for no borders got them, but NO ONE claims to be a motif. icewm, sawfish, windowmaker, ... ALL of these understand mwm hints, and display no borders. i can find other wm's that did the same. metacity is a modern one for example. but e did too (e14/15/16 days). support the hint and not provide motif wm info hints. no one set motif wm info because no apps required it - they ASSUMED mwm hint support. that was the actual common - if not 100% behavior case (it was universal that i saw). so as such history says "doesn't matter if the motif wm info hint is there, the wm probably supports it, and likely hasnt set that hint" as NO ONE sets it other than mwm (that i know of or can find) out of all the wm's that actually support it. if you google for _MOTIF_WM_INFO you will find a tonne of distro and app bug report systems all patching out the motif wm info checks from eterm (and urxvt) as they simply dont work in the common case. i'm not saying that the eterm code is technically wrong. the problem is you are not going to go change 5, 6, 7, 8 or more wm's to suddenly provide the _MOTIF_WM_INFO hints. everyone is patching the reverse. removing it as it is "moot" because the wm's "everyone uses" (notice in quotes) suports the hints, but doesnt advertise being mwm. now i'd say that the sensible thing would be to remove the mwm info property checks as the "real world" doesnt work like that. standards or no standards, when the vast majority of the world is working counter to the standard, the standard is bunk. it is no standard anymore. standards are in the end what the vast majority of software actually does. so again - don't get this wrong. im not saying you are technically wrong. the code simply gets in the way of most users by being to pedantic. people are actively patching it out and working around it just for eterm. they are not patching their wm's. i think the time has come to just let this one go and forget about being pedantic. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
