Re: WIP: wm-spec 1.9b

[raster rasterman com]

On 17 Sep, Michael ROGERS scribbled:

->  Don't forget that many users will not realise where the problem lies if, for
->  example, one application maps its transients in the ABOVE layer while another
->  maps its transients in the NORMAL layer. The user will just see that the
->  windows behave unpredictably, and conclude that X/Gnome/KDE is difficult to
->  use. If we introduce a complex set of hints we *will* get a complex set of
->  behaviours, and the overall effect will be to make KDE/Gnome look patchy and
->  inconsistent.

I don;t know about any other WM writer out there but if theres a spec
that requires me to limit my features I'm goign to happily ignore it.
:) layers are a great idea and i'm keeping them regardless of any spec.

remember that x gives us mechanism, not policy - you are trying to
impose policy - if you impose too restrictive a policy you have limited
the freedom wm's have traditionally had - and that is to do almost
anything they like outside an applications window. reducing freedom will
result in having a nice big spec that's porbably going to be very
scarcely used.

->  I think the current draft definitely describes a remote window managing
->  interface. Surely CORBA is the right way to do this? If we have to leave the
->  CORBA interface definition until later, so be it. I don't think we should try
->  to hack together a solution using X hints just to get the spec finished on
->  time.

the reason is no self-respecting WM author will write a whole corba
backed just to support your hints - you'll end up having to write your
own WM. 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.)

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.

->  >I'm concerned that this model won't work.
->  >
->  > - What is focusing the desktop good for? The only thing that would happen
->  >   is that WM keyboard shortcuts don't work anymore.
->  
->  It's good for, eg, typing on the desktop to launch applications. It also
->  shifts the root-window-click-proxying burden from the WM to the file manager;
->  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.

i dont think i'm interested in giving up selecting for clicks on the
root window and i ALREADY have the event procying code - i'm not in a
mood to chnage it all around just because there's a change of mind to
do it "our way" ratehr than the way it's alreayd being done that works
quite well.

also remember - the wm alsop can happily get rid of the roto window by
running everythign in a virtual root if it wants - I plan on removing
any desktop activity on the root window in future and movign all
virtual desktops to being virtual roots - so then you'd NEED have the
wm proxy for you as only the WM knwos what its virtual root windows are
:)

->  > - What about applications that can work with the root window background
->  >   now? They would *all* have to be modified plus they would have to
->  >   distinguish between a FM free desktop and one with a running desktop.
->  > - What about apps with 'transparent' background?
->  
->  Ack. Good point. Mind you, there must be some code in Eterm to handle E's
->  multiple virtual root windows. Anyone know how it's done?

properties on windows :0 easy stuff :)

->  > - Why is this supposed to be faster? I guess the shortcuts will still be
->  >   implemented as subwindows of the faked root window. Otherwise the
->  >   background would have to be redrawn frequently.
->  
->  Even if the shortcuts are implemented as shaped windows, they will not have WM
->  parents which need to be shaped, so this will cut the number of shaped windows 
->  in half.

actually by 66% (for example E reparents into a frame  the frame has a
container window for the app and the app window is in the container -
this is required to be able to do stuff liek shade windows etc.)

->  > - Multiple file managers will obscure each other! Being unable to run
->  >   more than one FM at once seems to be a silly restriction to me (and
->  >   confusing for the user).
->  
->  I think any user who wants to run more than one file manager (each with its
->  own desktop shortcuts and probably its own root menus) is pretty confused
->  already.  :)  Do you really run two file managers at once? Why?

they may have better aspects - one may be excellent for local filing
systems and another may be perfect for remote filing systems - users
coudl happily have them setup so one filemanager runs on one desktop
and another runs on the second.

->  >I'm still unhappy with the way the spec draft allows clients to take
->  >control over the window manager. There are very dangerous hints like
->  >_NET_DESKTOP_VIEWPORT/DESKTOP, _NET_WM_LAYER, _NET_WM_MOVERESIZE and
->  >so on. I guess most of us already have come into contact with those
->  >messy Java applications that maximize and respawn windows. What will
->  >prevent them from closing or moving other applications? It's *so*
->  >easy with this draft.
->  >
->  >If this kind of control is really required I strongly suggest that
->  >the hints providing WM functionality are grouped together and get
->  >a name that makes it clear that they are used by desktop and WM
->  >components only.
->  
->  I suggest that we move this functionality into a CORBA interface. But then you
->  already knew that.  :)

well i made my position on CROBA clear earlier. nowit's back to
lurking.
:)
-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com raster@valinux.com
                                    raster@linux.com