Re: WM hints interface

[Owen Taylor <owt1 cornell edu>]

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.

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

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.

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

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

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?

Regards,
                                        Owen