Re: Problems with gnome window hints

[raster redhat com]

On 27 Nov, Tom Tromey scribbled:
->  >>>>> "raster" == raster  <raster@redhat.com> writes:
->  
-> -> 2. If #1 isn't feasible, add a way for clients to detect when a
-> -> winning wm starts up.  Then change the clients to detect this
-> -> situation and modify their behavior accordingly.  This scenario
-> -> avoids the problem because it doesn't matter if the panel wins the
-> -> race -- it will change its behavior once it sees that E starts up.
->  
->  raster> to detect a WM appearing or dissapearing the app has to:
->  raster> 1. select on propertychangenotfy's on the root window. If
->  raster> there is currently no gnome WM there then wait till the
->  raster> _WIN_SUPPORTING_WM_CHECK changes - when it does perform a
->  raster> chekc for the WM chekc window it poitns to.. if thats there -
->  raster> select on it for destroys (structurenotify) then sit around -
->  raster> whenevr that window is destroyed the WM went away - set status
->  raster> of WM to 0 and re-initialise all toplevel windows (or modify
->  raster> them for a workaround when no WM is around) o bakc to non WM
->  raster> there state and wait for a property change/.. if the WM starts
->  raster> up re-init the windows (or modify then unmap and remap them)
->  raster> to work... it's not pretty.
->  
->  It might not be pretty, but at least it is reliable.
->  Starting the wm before everything else isn't even that.

Well let me put it bluntly. Attemtping to do a desktop that in any way
requires antyhing to happen OUTSIDE of an application window (eg
certain window borders or behavior/positioning etc.) that is not
explicitly in ICCCM and have gnome be completely WM independant is a
pipe dream - always was - always will be. I eblieve I said this almost
a year ago. you CAN do it.. with gobs of workaround code and special
casing. Either you accept there will be one or a small subset of WM's
that chsoe to support you or you opt for not support and then expect
not to work wiht several WM's.

Anything outside of an application windows is in Window Manager land -
anything iunside an application window is Application land . No WM goes
and created butotns inside of app windows -it doesnt go moving sub
windows of that app window around etc. Conversely no app shoudl do
anythign outside of its application window - outside an app window is
window manager land. The boundary between app window and Window Manager
land is defined in ICCCM. This is the standard - we can chsoe to extend
this but do not expect everyone to follow. Doing anything outside an
app window is guaranted to fail eventually in one form or another.
GNOME without any Window Manager dependance is merely a set of
applications - it has to be accepted that you have window manager
dependance if you want extra features - gtk already is as is gnome - it
DEPENDS on MWM hints (NOT in ICCCM) for borderless windows - there is
no workaround - this is "assumed" to be supported - not every WM
supports this. You are WM dpeendant. face it. Patch your WM or use
another. It's a pipe dream to practically think otherwise. Trying to
account for all cases leads to an ugly code mess as you can probably
see the above would be to impliment.

Sorry but it's time to face the facts. I dont want to be personal hre
but as a MW authro I and many others have been overly patient with aps
stepping otuside their windows into WM space and then acepting blame
for it from users. We keep doing workarounds for bad apps. It's time
app writiers stopped steppign into MW space - either that or write a WM
and depend on it. It's time a line in the sand was drawn. I'm working
on a document wiht all the GONME WM hints in it.. it's not compulsory
but I think it has to be accepted that a MW that doesnt support these
is not suitable for gnome.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/