Re: WIP: wm-spec 1.9b

[Dominik Vogt <dominik vogt fvwm org>]

On Fri, Sep 17, 1999 at 10:40:42AM -0700, raster@rasterman.com wrote:
> 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.

Don't get me wrong.  I don't want to limit what window managers can
do (of course not, I'm maintaining one myself), but what spec
compliant applications can do.  Especially the layer hints in
conjunctions with transients, override redirect windows and the
'remote' window management interface will be extremely clumsily
to code and won't run well on slow machines with a slow connection
to the server.

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

Yes, that's what I think too.  Forcing WM authors to write CORBA stuff
may annoy many of our (fvwm's) users because of the added complexity
to the WM.

> ->  >I'm concerned that this model won't work.
>...
> ->  > - 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 :)

May be easy, but would force authors of other applications to rewrite
their code to make them spec compliant.

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

Same with fvwm, but that doesn't necessarily mean that this applies
to this special kind of windows. If you don't decorate them, bind no
keys to them and don't resize them there is not much left a WM could
do with the double-reparented window.

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

And there may be uses we don't think of yet, but we know that they
would not be possible.

Bye

Dominik ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de