Re: WIP: wm-spec 1.9b

>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.

Leaving layers out of the spec wouldn't mean that you had to remove them to be

>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 Gnome ad KDE both intend to impose a certain amount of policy. In this
respect they are treading on ground traditionally occupied by the window
manager, but I think that's unavoidable.

>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. 

Well, I'm trying, but it sucks.  :)

>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.

>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?

>->  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).

>->  > - 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 hadn't thought of that. Apologies to anyone who runs two file managers.  :)

Michael Rogers

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]