Re: WM hints again! (proposal)

[Max Watson <redline pdq net>]

At 09:15 PM 4/23/98 +0200, Marko Macek wrote:

>------------------------------------------------------------------------
>Properties set on application frame:
>
>WIN_ICONS:
>   Type: array of XID, alternating pixmap and mask, mask can be None
>   Desc: set additional icons for application windows. Any number of
>         icons of any size or depth can be set.
>         Which icons to set should be either policy desision
>         (icewm currently requires 16x16 and 32x32 with default depth)
>         or we could specify additional hints on root window where WM
>         could specify the list of wanted icon shaped/depth. (There
>         is a standard X hint WM_ICON_SIZES that partially does this.
>         icewm does set it, but I haven't seen any app using it).

Ack. Hairy to implement, but useful.


>
>WIN_WORKSPACE:
>   Type: CARD32
>   Desc: First value = workspace that application is visible on.
>         Second value high bit = is window sticky (occupies all
>workspaces)
>
>WIN_LAYER:
>   Type: CARD32 (0-9)
>     where layers could be:
>      0 = Desktop
>      1 = Below
>      2 = Normal (default app layer)
>      4 = OnTop
>      6 = Dock (always on top - for panel)
>      3,5,7,8,9 are spare..
>
>   Desc: Specifies layer (Z-order) where window should appear.
>
>WIN_FLAGS:
>   Type: CARD32[2]
>      Two bit masks. The first one specifies valid bits, the second
>      one their values. Bits are as follows:
>        0 - maximized
>        1 - hidden
>        2 - rolled up
>        3 - group transient

Clever. I can get this working pretty quickly.


>
>---------------------------------------------------------------------
>Properties set on root window:
>
>WIN_WORKSPACE:
>   Type: CARD32[2]
>   Desc: current workspace number and count
>
>WIN_WORKSPACE_NAMES:
>   Type: Text property (string list).
>   Desc: Workspace names.
>
>WIN_WORKAREA:
>   Type: CARD32[4]
>   Desc: minX, minY, maxX, maxY of screen work area.
>         For example:
>           - on 1024x768 screen with full screen work area,
>             with no panel or taskbar this would be set to:
>             0, 0, 1024, 768
>           - with 32 pixel bar on top of screen, this would be set
>             to: 0, 32, 1024, 768
>         This is intended to limit Maximize function. Maximized windows
>         should not be larger than WIN_WORKAREA specifies. When window
>         is maximized, it occupies the entire work area except for
>         window title bar on the top.
>
>   Set only by the window manager.
>
>   NOTE: Two issues remain with WIN_WORKAREA:
>       - negotiation of screen real estate. Applications should probably
>         specify the side of screen to dock to (top,left,right,bottom).
>         Window manager could then subtract their geometry from work
>area.
>         It should be possibly to dynamically change the work area.
>       - can workarea be different on different workspaces?

This is great. It will be possible to write one desktop pager panel applet
that will work with any GNOME-compliant wm. Also, I don't think negotiation
for reserved space will be an issue. A wm can just check the WM_LAYER_DOCK
hint (above) on newly created windows, and if the new window is a panel (or
other workarea limiting window), the window manager can get the coords of
the window and resize it's workarea accordingly. 


>
>Also:
>  For performance reasons (rountrip request time on GetWindowPropery)
>  it might be a good idea to have all hints in one property (including
>  WMhints, motif hints, and all the rest) as one propery on the window.
>  Comments?

I agree that all of the above proposed hints should be in one property
structure, but to group the WMhints, the MwmHints, and the rest is probably
a bad idea. Would that not break compatibility with window managers that
already support those hints?

M.Watson <redline@pdq.net>