Re: WIP: wm-spec 1.9b

[raster rasterman com]

On 19 Sep, Michael ROGERS scribbled:
->  Leaving layers out of the spec wouldn't mean that you had to remove them to be
->  compliant.

what if the Wm requires the use of its layers for its own
functionality?:)

->  >use X properties and client message s- all the mechanism for
->  >IPc is alreayd there and provided by X - I still cannot fathom the
->  >continual urge to make everyhting corba when there's alreaday a proven,
->  >network-transparent, display dransparent and cross-platform way fo
->  >doing IPC that simply would need a small wrapper library for
->  >convenience for applications. I ESPECIALLY see the authors of
->  >"lightweight & fast" window managers not implimenting this as its just
->  >another requirement for a library (orbit, mico - whatever) and those
->  >libraires come with their own requirements (glib, C++ etc.)
->  
->  KDE and Gnome already depend on CORBA, so the burden of shared libraries
->  wouldn't be increased. I think.

but it would increase the burdenr on all wm's who might want to be
compliant. instantly we all have to learn a new api, leanr how to use
idl's corba etc.a nd require an orb, blah blah blah etc. when ti's not
even needed. i knwo i wont be supporting corba as a wm spec mechanism
anytime and i'd be pretty sure most wm's on't either - so again. i
suggest stickign to X - it has allt he nuts and bolts you need, and
write library calls for convenience for apps to do all the event
checking, client message/property changing stuff.

->  >so i suggest you thinnk twice then twice again about using CORBA - you
->  >may want it for your own inter-app communication but i seriously doubt
->  >many wm's want it to do what can already be done by X and what they
->  >alreayd do do via X.
->  
->  Does E already do communication between the internal pager and the rest of 
->  the WM via hints?

um.. no - it's internal - as in its inside of e's code. E just handles
its onw timer mechanism and "threads" (not real - just timeout threads).

->  >->  the file manager makes desktop clicks available to the WM, not the other way
->  >->  round.
->  >
->  >I dont see what the difference is. the burden goes somewhere - and wm's
->  >have since the dawn of time done clicks ont he roto window - chanign it
->  >to be the other way around is simply trying to go against the grain
->  >because you want to and nto because its practical nor does it fit into
->  >the model that already exists. wm's alreayd accept the clicks on the
->  >"root window" - to have them not accept them means a lto fo extra
->  >coding for a wm author and it means that many wms will instantly
->  >conflict wiht the filemanager and it wont work. if you do it the other
->  >way around you work withitn the current framework and way things happen
->  >- wms that are nice will pass on unwanted/unneeded mouse clicks for you.
->  
->  With the file manager proxying clicks, the WM still handles click on the root
->  window. It's just that the clicks are sent by the file manager after it as
->  filtered out the ones it is interested in. This means that the WM can use the
->  same code whether the file manager is running or not. Not a big difference
->  either way, I admit, but if there's a conflict at least you get consistent
->  behaviour (ie the file manager root menu doesn't "disappear" when you change
->  window managers).

a lot of wm's as part of th4eir startup select on button presses ont he
root window - E will fail and abaort if it cant get them. fvwm2 does the
same - if ti cant manage to select on buttonpresses on roto it will
about and fail. if i dug the code for twm i bet it probably woudl do
the same - infact most wm's would. by doign this you ar basically
forcing all wm's to me modified to even be used in conjunction with a
filemanager like this. the reason is one and ONLY one client in X can
select for buttonpresses and releases on a single window - so first in
gets it and all others afterwards hav their selects fail. the current
mechanism spport proxying onto one hidden window so one single extra
client can get the events if the wm doesnt need them.

remember - makign the filemanager select for button presses and takign
them will make the majority of wm's simply not work as they are now -
doign it the other way around means the fielmanager simply doesnt get
menus on the root window  since the fielmanagers for gnome and kde are
relatively new - infatc gnome is reqriting theirs - they can fall back
if they fail to select on presses on the root window - chanign the 2
fielmanagers is much less work than chanign the 50 wm's out there.
since one is alerady being written thats even less work.

so i suggetsa having the wm proxy for the fm sue to compatability
reasons. otherwise you just managed to ensure the vast majority of
"legacy" wms wont even start up when a fielmanager is running. :)


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com     raster@valinux.com
                                    raster@enlightenment.org raster@linux.com
				    raster@zip.com.au