Hints for swallowed pagers and MacOS-style menus

["Michael Rogers" <mrogers cs ucl ac uk>]

Two suggested modifications to the spec:

(1) A new root window property to allow WM-provided pagers and taskbars (and 
foobars) to be embedded in DE-provided docks and panels.

  _NET_SWALLOW_THIS_WINDOW, XA_WINDOW/32

  The Window Manager MAY set this property on the root window to be the ID of 
  a child window created by the WM. This property indicates that the Window 
  Manager wishes to embed the indicated window in the Desktop Environment's 
  dock or panel. The child window MUST have this property set to the same 
  value.

  An Application MAY reparent the indicated window. Before it does so it MUST 
  set the window's _NET_SWALLOW_THIS_WINDOW property to None to prevent other 
  Applications from attempting to reparent the window. The Application SHOULD 
  attempt to provide the window with enough space for its requested size. 
  However, the Application MAY change the window's configuration at any time, 
  so the Window Manager MUST listen for ConfigureNotify events on the 
  swallowed window. For example, a panel might resize a swallowed window when 
  a new launcher is added to the panel.

  Rationale: This hint allows the dock or panel to "swallow" a window provided 
  by the Window Manager. For example, the Window Manager might want its pager 
  or taskbar to be embedded in the Desktop Environment's dock or panel.  If no 
  dock or panel is running, the Window Manager can manage the pager or taskbar 
  itself.


Possible problems:
* What happens to swallowed windows if the panel crashes?
* What happens if the user has a Gnome panel running on one desktop and a KDE 
  panel running on another desktop? Only one of them can display the pager 
  (but then again, multiple pagers communicating with one window manager would 
  be worse).
* Maybe this should be a list of window IDs to allow (eg) a pager, a taskbar 
  and a global menubar to be embedded? That would allow the panel more 
  flexibility when finding the requested space than embedding one huge window 
  with all three features in it.


(2) A new window type to allow MacOS-style menu bars:

  _NET_WINDOW_TYPE_MENUBAR indicates a menu bar. This is the only case in 
  which a _NET_WINDOW_TYPE hint should be used on a window which is not a 
  top-level window. This property MUST NOT be set on more than one descendant 
  of any top-level window.

  Rationale: This hint allows the Window Manager to provide a global menu bar. 
  (The menu bar of the currently focussed window appears at the top of the 
  screen instead of at the top of the application's window, making it easier 
  to hit menus with the mouse.)

  The Window Manager MAY reparent windows of type _NET_WINDOW_TYPE_MENUBAR, so 
  this hint should only be used by toolkits which can rearrange the contents 
  of the application window to fill the space left by removing the menu bar. 
  (This shouldn't be a problem for toolkits which allow tearoff menus.)

  Note: Menu bars MUST only be reparented by the Window Manager, because 
  global menu bars only work in a click-to-focus environment, and the focus 
  policy is determined by the Window Manager.


Possible problems: 
* What happens to reparented windows if the wm crashes? Do we need to add menu 
  bars to the save set?
* Will the menu bar windows be resized by the widget-packing code when the 
  application window is resized? Or will they resize to fit their new parent 
  window? (Havoc, how does GTK do it?)
* Perhaps _NET_WINDOW_TYPE_MENU should be changed to 
  _NET_WINDOW_TYPE_STANDALONE_MENU to avoid confusion.


Michael