Re: WM hints again! (proposal)

[Marko Macek <Marko Macek snet fri uni-lj si>]

raster@redhat.com wrote:

> desktop_num isn't much use unles the app knows:
> 1. how many desktops are there
> 2. what desktop are we on now
> and a num isnt much of a generalization.. I suggest a mask (bitmaks) to
> determine what desktop the app lives on so if we have 8 desktops the
> bits in the byte of the mask could be:
> 01100101
> ie it lives on desktops 0,2,5 and 6
> thiw is a generalization of the desktop_num thing - well E 0.14
> supports it and is how it does ti interanalls - 0.14 is limited to 32
> virtual desktops - why you would ever need more beats me.
> but we can extend this to  - wm sets the numebr of desktops as a
> property onthe root window.. the app can suply as many vbytes as needed
> with the correct bits set to create a mask for which desktop it lives
> on.. if the number of desktops change - the wm can changed the root
> window property. the app can get this as  a propertychange event ias
> long as it selects it.

I don't think having a mask is really necessary. A workspace number
should be
sufficient. (fvwm,kde,wmaker and now icewm do it this way, CDE and some
time
ago icewm too use a bitmask (actually list of atoms)). In my opinion
workspace number + sticky flag is enough.

Anyway, here is my preliminary proposal for hints (icewm will implement
them in a few days). Please comment.

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

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

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

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?


Mark
-- 
... MouseDevice "/dev/null"
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si      http://ixtas.fri.uni-lj.si/~markom/