Re: Simplifying the specs

[raster rasterman com]

On  1 Dec, Matthias Ettrich scribbled:
->  
->  Struts:
->  
->       Is the array overkill? Shouldn't one strut that is valid for all desktops
->       the defining window is visible on be sufficient?
->  
->       I know I requested the hint that complicated, but I'm a bit worried. The
->       array makes that simply hint much more complicated and is bascially only
->       useful for KDE-1.x's panel..... Probably we will not even make use of this
->       in KDE-2.0.
->  
->       I suggest to simplify it to _NET_WM_STRUT, CARDINAL[4]/32

there's no reasonto dumb it down - E certainly might use it - tho i'm
not sure of its use since E doesnt realyl like panels but uses generic
windows as "strits" thsu theycan be any shape anywhere - not just takig
ont or more full sides of the screen... but having the hint being
general makes it more useful.

->  NET_WM_STATE_MODAL
->  
->       While I honestly believed the hint was a good idea when I asked for it, I'm
->       not sure any longer. I did some testing in Qt and draw the conclusion that
->       modality really should be handled by the application. Since we already have
->       hints to notify the WM that a window shouldn't show up in the taskbar,
->       there's not much functionatliy WM_STATE_MODAL can offer.
->  
->       Maybe we should instead encourage toolkit vendors to deal with modal
->       windows according to ICCCM? This basically means setting wm_hints.input
->       to false for main windows and requesting the WM_TAKE_FOCUS protocol.
->       When receiving a take-focus method, the toolkit should simply set the focus
->       to the modal dialog ( using the right timestamp). That's the "Globally
->       Active" mode described in section 4.1.7. of the ICCCM and it's the only
->       mode that works sufficient and user-friendly in combination with modal 
->       dialogs. 
->  
->       WM_STATE_MODAL on the other hand might be a bit easier. And it would
->       allow the window manager to define a beep-sound or a visual bell or
->       anything if the user clicks fail. If each application does this, it will
->       be pretty inconsistent (some playing sounds, some just beeping, some
->       flashing....). Also I have no idea how good the Globally Active modal works
->       with existing window managers. KWin does it fine, kwm probably suboptimal.
->  
->       Dunno. I just wanted to share my thoughts. STATE_MODAL may be userful,
->       but it's a little bit duplicating. If we keep it, however, we should also
->       emphasize on the fact that the application may request a state stange
->       while the window is mapped (some dialogs like to become modal/unmodal
->       wile being visibile).
->     
->  
->  Matthias
->  
->  
->  

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