Re: [gtk-list] Re: WM hints interface

[raster redhat com]

On  1 Mar, Marko Macek shouted:
->  Owen Taylor wrote:
->  
->  > This isn't a satisfactory solution until colormap/depth issues
->  > are addressed. Matching the root window may be OK (the current
->  > defacto standard for ICCCM-incompliant pixmaps), but it is
->  > incompatible with the way gdk-imlib works now.
->  
->  Why is it incompatible? How do you plan to address colormap/depth 
->  issues?

even thoogh the ICCCM specs say it must be of the default visual - there
is no good reason for  a programs icon window to not be on any visual. S
window of any visual canbe reparented to a parent of a different
visual. If you want a color icon, use an icon_window. Using a pimap
will mena you violate the ICCCM standards - having a multi-depth pixmap
here woudl break WM's if they aren't wirtten to be very robust and
check pixmap depth becuase ICCCM allows them to ASSUME 1-bit deep icon
pixmaps.

->  > Another function can be added once something worked out.
->  > (gdk_window_set_icons ?), but I wanted to get something in place right
->  
->  Something like that would be nice.
->  
->  > now. A gdk_window_set_icons could even check WM_ICON_SIZES and
->  > pick one out to use for the ICCCM icon.
->  
->  This makes sense.
->  
->  > > Modal windows are missing (inputMode from motif). Or you could say
->  > > that modal windows are banned from gtk (and I would agree ;-)
->  > 
->  > Modal windows aren't banned from GTK, but they are pretty much
->  > supported without any WM functionality. The only real benefit
->  > of WM support would being keeping the modal dialog on top
->  > of the rest of the applications window.
->  
->  Keeping them on top is not called modal, it is called transient (and
->  is already supported). Modal windows would prevent input focus from
->  being given to the parent frame.
->  
->  One thing that is not supported is keeping a window on top of all
->  windows in the same application. AcroRead seems to to this
->  by making a WM_CLIENT_LEADER window and then having WM_TRANSIENT set 

WM_CLIENT_LEADER is not part of any ICCCM I know odf not in versiion
1.0 or 2.0 of ICCCM unless this is a motif hint?

What i woudl like is a canonical unambigous list of all the hints
(motif included) ont eh cxlib level (ie atom names) and EXACTLY what is
expected of these hints.

->  to that window. It's not supported by any wm I have seen (I will support 
->  it  in icewm unless I find something is wrong with this).

if it wants a leader it should set the group XID to its own window Id
(according to ICCCM) and all other windows int hat grup chocul set the
XID to the leader window ID - according to ICCCM. If it is not doing
this si it not conforming to ICCCM specs - which i spent the whole
weekend reading over again - making E0.14 fully 100% ICCCM compliant.

->  > I am quite against supporting the SYSTEM_MODAL feature of of MWM - the
->  > user should be able to choose which application they want to
->  > interact with. Modal dialog hints could be added later, but I
->  > didn't feel that they were either needed enough or standard enough
->  > to put in now.
->  
->  I agree about not using system modal. I also thing that a wm and toolkit
->  should provide the capability, but it should be discouraged from use.
->  
->  > > Icewm does. It sets it to 16x16 to 32x32 using 16x16 steps.
->  > 
->  > Tiny little icons.... Do most applications actually pay attention
->  > and provide an icon that small?
->  
->  No. Most application provide an icon of some random size ;-)
->  Actually what is need is small/large icon size that depends on display
->  size. OS/2 does things this way (16/32 or 20/40).

the app should be able to provide an icon in ANY size form 1x1 to
1000x1000 or even bigger. The WM just has to set the size ranges it
wants with the XA_WM_ICON_SIZE atom. the client, if ICCCM complient
must provide an iocn, if it provides one, in a size the WM accepts -
the WM has the right to deny the use of that icon any time it so wishes
- especially if it does not conform to the size it requested. In this
domain the WM is "God" so to speak. It may deny almost anything it
pleases with complete disregard to hints - that, in many cases, is the
WM's right according to ICCCM. If Hints are not fully documented and
clearly defined as to what they are to do, it will be hard for WM's.
even if they want to, to all universally "conform" to those hints.

->  Mark

-- 
--------------- 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 Enlightenmenthttp://www.rasterman.com/