Re: issues for future version

[Sasha_Vasko osca state mo us]

Hi
> Hi,
>
> I've added the patch recently posted to clarify use of the PID, and
> also done s/UTF-8_STRING/UTF8_STRING/. Not on the website yet, but
> will be soon.
>
> Here are some outstanding changes to be made, some minor and some
> hard. Most have been previously mentioned/discussed to some extent.
>
>  - "What's This?" protocol.  Should allow a What's This button in the
>    window manager titlebar or in a global menubar as on the mac.
>
>  - Set a hint on the client giving the frame geometry.
>
>  - Full screen window state for presentation windows
>
>  - Minimized window state (allowing IconicState to mean any kind of
>    yanking offscreen)
>
>  - Note about how WMs should support the WM_Sn selection
>
>  - Hint for "requesting attention". On the Mac, you can cause a
>    little diamond to appear by your app in the task menu,
>    and the task menu icon blinks.
>
>    Perhaps just say that if the UrgencyHint flag in the ICCCM should
>    be interpreted in this way.
>
>  - Clarification of what window groups mean semantically. The
>    ICCCM says "a set of top-level windows that should be treated
>    from the user's point of view as related." Too vague. ;-)
>
>    Perhaps define that a window group should include all windows
>    that the user would consider a single application. So e.g.
>    gnome-terminal's current behavior where all terminals are
>    in the same window group is not correct.
>
>  - Define what to do if you only support maximization but not vert/horiz
>    independently. i.e. if a client requests vertical but not
>    horizontal, do you fullscreen maximize?
>
>  - Add note that "HORZ" is indeed intended, do not use "HORIZ" ;-)
>
> What else do we need to cover?

- Window Layers. AS was discussed some time ago, there is a distinctive
need
  to provide for window layering. For example you can place all your
  panels/docks/wharfs in the higher layer, to keep them always visible, or
  move terms onto the bottommost layer to keep them from obscuring other
  windows. It was proposed as KEEP_ON_TOP hint, before, but IMHO layers
  are much cleaner and flexible way to do that.

- Pseudo-Transparency support (aka Root pixmap ID). One of the most
annoying
  missing features in X protocol is lack of call to obtain background
  pixmap of any given window. That makes it very difficult to implement
  different pseudo-transparency things. The solution has been for some time
  to maintain property on root window set to the value of the pixmap,
  that is the copy of root pixmap. It is a cludge, yes, and is causing
  considerable memory waste(due to having two copies of single pixmap),
  but untill X implements XCopyBackgroundArea() call it is probably
  the only way to go. Other alternatives includes having process around
  responcible for root background rendering, and have it fill pixmaps
  with parts of the root, on application request. Anyway, that sort of
  things should be standard.

I could draft this things, if there aren't other takers.


>
> Havoc

Cheers
Sasha Vasko