Re: Still need a hint for undecorated windows

[Billy Biggs <vektor dumbterm net>]

Havoc Pennington (hp redhat com):

> Step one is to get people to post the apps they care about and their
> detailed behaviors. WINE/XMMS, the app you mentioned, onscreen
> keyboards, whatever. Then we could have an intelligent conversation
> about what the types (and flavors of them caused by states, etc.)
> should be.

  Here are some of the ones I've seen that I don't have a good type for:

  1. Some guys on IRC are developing a VoIP utility app in SWT.
     It's a taskbar icon, and on an incoming call they want a window to
     appear which shows the caller and has buttons for handling the call
     or transfering it, with a text entry for who to send the call to.
     It should also animate in.  It's currently an override_redirect
     window, and is having problems taking focus.

     Also see Firefox's "download complete" window under Windows.

  2. We often gets bugs about the code assist drop-down in eclipse not
     being resizable.  It is under Windows.  The expected behaviour is a
     drop-down window with resize handles but no title bar.

  3. Helper pop-up windows (Eclipse's key binding assistance pop-up and
     focusable tooltips).

  Each of these cases is a window that has some other more normal window
it is associated with, and it has some specific desires about what its
decorations should be.

  One tricky part of the semantic types is that as an application
developer you don't really know what to expect.  For example, the
_NET_WM_WINDOW_TYPE_SPLASH hint was implemented quite differently
between kwin and metacity:

   - Under older versions of metacity, the window was set
     always-on-top, which seems reasonable but was unusable for Eclipse
     since it opens dialogs while the splash screen is open, which
     were then obscured:

       (http://bugzilla.gnome.org/show_bug.cgi?id=165243)

   - Under kwin, splash screen windows disappear when you click on them.
     I like this idea, but it definitely impacts design somewhat (no
     clickable URLs on a splash screen).

  The _NET_WM_WINDOW_TYPE_TOOLBAR type I also found a little awkward,
since it has no border under metacity but does get the utility border
under kwin.  See:

  http://mail.gnome.org/archives/wm-spec-list/2004-December/msg00000.html

  I think my point is that the policy can't be too abstract.  The
semantic types have to have fairly well defined behaviour otherwise you
can end up not being able to use them in an application without breaking
the user experience on another WM that implemented the spec differently.

  -Billy