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

[raster redhat com]

On  5 Mar, Owen Taylor shouted:
->  
->  raster@redhat.com writes:
->  
->  > On  3 Mar, Marko Macek shouted:
->  > ->  raster@redhat.com wrote:
->  > ->  > 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.
->  > ->  
->  > ->  I agree with all of the above mentioned (ICCCM suggests but does not
->  > ->  specify
->  > ->  that icon windows should use the default visual). Also using color
->  > ->  icon/mask
->  > ->  pairs is not ICCCM compliant.
->  > 
->  > well according to the Xlib Programming Manual for Version 11 from
->  > O'Reilly & Associates - bottom of page 415....
->  > "The icon window:
->  > 
->  > * Must be an InputOutput child of the root window.
->  > * Should be one of the sizes specified in the XA_WM_ICON_SIZE property
->  > on the root (described in Section 12.3.4.1).
->  > * Must use the default visual and default colormap for the screen in
->  > question.
->  > ....
->  
->  Interesting - the R6.3 ICCCM has those all as "should" not "must",
->  though there are "musts" further down in the list.

Hmmm... looks like its back to ambiquity.. I'll take this dissention in
documentation to mean it's a free-for-all to disobey it :)

->  
->  > so it must use the default visual and colormap - i can see the reason
->  > for using the default colormap (avoid "colormap flashing" with icons -
->  > also it states elsewhere that the WM should exclusively be incharge of
->  > colormap changing) - but default visual? i see no good reason for this
->  > to be in the ICCCM specs. I believe we could safely break this bit of
->  > ICCCM.
->  
->  But each Colormap has an associated visual ...
->  
->  What I think your saying is:
->  
->  "The icon window should be either the root visual and default colormap or
->  any TrueColor visual (and StaticGrey/StaticColor ?)."

yes..:) thats what I mean :)

->  This won't work if the TrueColor visual is actually implemented as a
->  separate colormap (as is the case on my current 8bit display) but
->  should be safe on any hardware that I know of as long as the
->  TrueColor visual has a reasonable number of planes.

basically what I mean is to avoid "custom" colormaps on the window so a
colormap does not have to be installed or created just for the window
to look right.

->  > ->  > 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.
->  > ->  
->  > ->  I agree. Making such a list would be very useful.
->  > ->  
->  > ->  > ->  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 understand this. I am not sure if using WM_TRANSIENT on the group
->  > ->  leader
->  > ->  window should have the effect of having an group transient (instead of 
->  > ->  just window transient) window.
->  > 
->  > true - it is a little ambiguous - but i dont see that it says anywhere
->  > that properties of the group leader should be inherited by group
->  > followers - and these properties imlicitly inherited via the WM - the
->  > app should set them explicitly if it wishes inheritance to take place.
->  > Al least thats my view. 
->  
->  [...]
->  
->  Quoting the ICCCM:
->  
->  2.The properties of the window group leader are those for the group as
->    a whole (for example, the icon to be shown when the entire group is
->    iconified). 
->  
->  Of course, "properties" here is somewhat ambiguous - I don't know if it
->  applies to transience or not.

Hm.. well I'd assume it doesn't mean transience is inherited.. although
that is technically a property...

->  > not if the app doing the scaling has an intelligent "mipmapping" scheme
->  > - and always scale down, not up, if possible.
->  > 
->  > anyway - here's an idea for being able to have multiple sized icons of
->  > any size... any time - instead of having all the sizes fixed at startup
->  > of the program (limiting if the wm mid-stream decides to change its
->  > icon sizes for lets say mini icons to 10x10 instead of 16x16)
->  > 
->  > this is a little more involved... but It's more extenisble and
->  > powerful..
->  > 
->  > WM sends XClientMessage with ATOM of WM_NEED_ICON_PIXMAP_SIZE - data is
->  > in 32-bit chunks (long) data[0]=width in pixels of requested iocn,
->  > data[1]= height.
->  > 
->  > client responds by creating these pixmaps and setting a property on its
->  > client window wiht ATOM WM_HAVe_ICON_PIXMAP_SIZE, data in 32-bit (long
->  > format) with data[0] width, data[1] height, - which are exact copie sof
->  > the size requested by the wm (so the wm knows this property change was
->  > in response to that request for that size), then data[2] is the pixmap
->  > id and data[3] is the mask id (0 if there is no mask)
->  > 
->  > we can extend this so data[2] int he ClientMeasags is also the visualID
->  > for which the pixmap shoudl be created (if 0 no specific visual Id is
->  > required) and data[4] for the property can be the visul Id it was 
->  > created for (always set), The WM will pick up the "reply" to this
->  > request as a PropertyChangeNotify event...
->  > 
->  > this allows the WM to request an arbitary stream of icons - as many as
->  > it likes - or as few as it likes. - it allows re-negotiation and
->  > more... I'm sure there may be some additions to this others may wish to
->  > make?
->  
->  Hmmm ... this seems to potentially slow down the creation process
->  quite a bit - depending on the way the WM works, it might not
->  be able to show the window correctly until it has the icons for
->  the window - which means that between the MapRequestEvent and
->  the map event, the WM has to send the icon request to the client,
->  and the client has to create the icons.

the wm can "defer ralisation" fo icons until all the hints are
negotiated and keep drawing the border anyway... :) E0.14 does this
with external image classes - it doesn't wait for a reply - it adds the
external imageclass when and if it gest it - and soldiers

->  Since I suspect that WM's will most likely have very similar
->  requirements for all windows on a screen, might it not be better
->  to specify the requirements on a root window property, and then
->  if you want to support dynamic changes, either send the
->  client message when things change, or specify that clients
->  should request PropertChangeNotify events on the root window?

hmm I'd go for B - clients select property change on the root window...

in that cae all we need is a quick stat struct to put into the property
data like:
int num_pixmaps_sizes;

int width,hiehgt,visid;
etc.
per pixmap size.
and ont he client window set a property with the same format except the
data elements are
int width,height,visid,pixmapid,maskid;

?

->  Regards,
->                                          Owen
->  

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