On Wed, 7 Oct 2009 19:06:37 -0700 Michael Jennings <m...@kainx.org> said:
> On Thursday, 08 October 2009, at 11:51:32 (+1100), > Carsten Haitzler wrote: > > > 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. > > They're actually all from the same few people/threads. (I did that > search myself.) > > > 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. > > Well, something does. On my system, and every system I've ever used, > something sets that property. Maybe it's in X itself; I always > assumed it was E, but maybe not. no idea, but e (1, 2, 3...14, 15, 16 or 17) has never set it. beats me what does - but i certainly dont have it set here. it doesnt get set when running those other wm's i mentioned for example. :) but X shouldnt set it - its not a core X property. some client/app sets it. but as i said. it'd not set by any of the wm's that support it (other than mwm i guess - dont have it here to test with). > > 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. > > I need something to check for; otherwise, I can't be assured of a > borderless window just because I ask for one. I see _MOTIF_WM_HINTS > in ecore_x. Should I be checking for that instead? well e adds it to the netwm protocols that it understands (or it did until jeffdameth removed it from the list. not sure it's a problem being there. any atom in that list a client doesnt know will be ignored as thats needed behavior for forward-compatibility). thats about it - but no other wm's add any form of info involving motif on the root window. try them (metacity, icewm, wmaker, sawfish - didnt try kwin as i just didnt have it installed, but my guess is its the same too). no one sets it, but they do all understand it. (note i tested only a set of wms - not every single one, but they were wm's i was sure supported mwm borderless hints). the problem is override-redirect does get you borderless, but it creates a chunk of other problems the option doesnt imply you will end up with: 1. window wont stay on its virtual desktop - it will always be there so its also becoming "sticky" which isnt what the user requested if we are to be pedantic about having borderless be guaranteed :) we can be pedantic about all the other undesired side-effects). 2. window no longer behaves like others (alt+left mouse for move - or alt+right mouse for menus etc.). 3. stacking order is no longer properly maintained with other windows 4. focus handling will not work for keyboard input as well as other window switching tasks (alt-tab etc.) correctly. (these are a result of the window not being managed). etc. override-redirect i believe (imho) is a WORSE result than simply failing to be borderless if the wqm doesnt support netwm hints. thats my view on it. so picking between the greater or lesser evils - i'd go for just using the mwm hints regardless. make override-redirect another option (imho) - sure. allow it, but make it explicit as it comes with the attendant above side-effects. make borderless request it via mwm - and if the wm doesnt do it, well point fingers at the wm, as you have no other way to have it borderless without severe side-effects. thats my position on it. it's your eterm source. you may do with it as you see fit. i'm not going to force you. i'm just putting my opinion on this as it seems to have turned into a bit of a flamefest. imho this would make everyone happy and not destroy behavior (again we can add the motif wm info to e - but you will still break under a host of other wm's - so i'm just addressing this as more of a universal solution). :) -- ------------- 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
