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

[raster redhat com]

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

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.

->  That is why I proposed the following extenstions (they should be easy to
->  support).
->  
->  WIN_ICONS (on application window) contains pixmap,mask pairs. They can
->  be of
->  any size or depth. We should specify a list of suggested sizes/depths to
->  have
->  (like default depth and square icons with sizes 16,32,48).

I think we can come up with a better solution....

->  WIN_ICON_SIZES (on root) a list of icons sizes (and possibly depths??)
->  that
->  window manager would like to have.

we already have an icon sizes hint - so we don't need any more

->  > 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?
->  
->  It is part of session manager support. (page 49 on my .PS). Maybe using
->  it it is not such a good idea after all.

AHa I see - it was  in the session management area - I don't think this
should be used for decoration and management (window, not session)
purposes - it seems this is here to allow the session manager to ignore
transient and other windows of the app so only the leader is regarded
as being important and worth doing session management on.

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

->  > ->  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
->  
->  I agree with the above. However, specifying an icon using an icon
->  window is not useful, because it can only be put in one place. My

true.. that is one minor problem... Time to think laterally...

->  wm always has at least two copies visible and can often have four
->  of them visible (app window, taskbar, window list and window menu).
->  It needs 16x16 icons to do this. For Alt+Tab (windows like switcher
->  between windows it would be nice to have 32x32 or 48x48 icons
->  displayed).
->  
->  If applications provided more icon sizes, I could even have the default
->  icon
->  size changing with screen resolution. (I'm sure 16x16 is small on
->  1600x1200

nah.. 1920x1440 makes 16x16 look a little small :) well it does on my
display:)

->  and above). Scaling could be an option, but it produces ugly icons most
->  of
->  the time (same as scaling bitmapped fonts).

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?
 
 



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