Re: E/Gnome window placement quirks

[raster redhat com]

On  3 Mar, Daniel Burrows scribbled:
->    I've attached a small screenshot to this to illustrate what I'm talking about.
->  I'll refer to it from time to time, so please take a look.
->  
->    I don't know whether this should be sent as a comment on E or on Gnome, but
->  several people have brought up what I'm talking about on this list so I'm
->  posting this here.  These are some annoying facets of the way the E handles
->  window placement, window stacking, and window movement.  Note that there may
->  be a way to fix these but Gnome/E is supposed to be usable and _pleasant_
->  without requiring lots of tweaking (although I enjoy tweaking whenever
->  possible :-) )  These all relate to the (excellent) E-Mac theme recently posted
->  to e.themes.org. (if the author is listening..let me move and resize windows
->  using wmaker-style click-and-drag and I don't think I'll have anything left
->  to complain about :-) )

this basicalyl shows that gmc is not a managed E client - it has no
clue gmc exists - mots likely becuase you started gmc before E started.
- thus is fell back and used overrider-reidrect windows, bypassing the
WM.

->    The basic problem is that E doesn't seem to recognize the concept of a screen
->  area beyond which windows can't be dragged or placed unless it's absolutely
->  necessary. (eg, a program requests a window which is too big for the
->  screen).  Because of this, windows tend to get haphazardly strewn over the
->  desktop dragbar, under panels, under theme decorations, and on top of other
->  important stuff.  Moreover, the panel places itself in the corner regardless of
->  what E decorations are lying around, and gmc puts icons in the same place all
->  the time.  In addition, windows sometimes end up on top of these but sometimes
->  don't (I can make icons overlap windows)  I have an idea about a way to solve
->  this, but even if my way isn't the best--something has to be done.  This
->  mess needs to be cleared up before 1.0.
->  
->    I don't know enough about the current WM communication scheme to know exactly
->  what needs to be changed, but I think that the best way of doing things would
->  be to:
->  
->   * give the WM some concept of windows with "special" placement treatement, and

alreayd have someof that- but gmc manages placement of its own
windows.. E just does what gmc tels it IF the windows are managed
windows (ie gmc started after E) - thus it is gmc's responsability to
work out where to put them.

the panel - thats also the panels responsability as it , just like gmc,
requests explicit positioning - If it is a managed client. If it is
not, then it will dowhat gcm does - use override-redirect and bypass
the wm and thusa the wm can't do squat.

->   * Give each window a 'placement niceness' which determines what priority
->    they get (default 0).  Windows would never be placed over a window with a
->    lower niceness if possible.

alreayd there - called layers. E arranges preferntially ased on the
layer if the app doesnt explicitly ask for geometry.

->    For example, I'd set the niceness of the E menu bar and dragbar to -20, the
->  niceness of the panel to -10, and the niceness of the gmc icons to -5.  So
->  the windows would be placed as follows:

E's dragbar is an internal gadget - you can turn it off if you like.

->  (1) the menubar and taskbar would go at the top and bottom of the screen,
->    respectively.  The 'area available for special placement' would eliminate
->    these two regions.
->  
->  (2) the panel would request placement at the top and bottom of the screen.  But
->    since the area available has been diminished, it would actually get stuck
->    directly underneath the menubar and directly above the dragbar.
->  
->  (3) gmc would have its icons placed in the upper-left region of the remaining
->    available space.
->  
->    (I suppose that for purposes of the calculation, an edge panel and a corner
->     panel would have to be treated the same way)
->  
->    To deal with windows getting in the way of special decorations or the panel, I
->  suppose you'd need some sort of WM hint that says "don't allow windows to
->  move over this window".  Or maybe just configure it in the WM for each window
->  class?  (icky, but can I do this already?)  Probably a corner panel should
->  allow windows to move over/under it, but an edge panel shouldn't..
->  
->    Daniel
->  

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

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/