Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

On Wed, 2005-08-03 at 20:29 -0500, Billy Biggs wrote:
> 
>   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.

And other behaviors besides decorations have to change to make these
work well, I'd say. They are more examples I think of my basic claim
that if you want to add a new window type in a toolkit (or app), you
pretty much have to develop WM changes as part of the new feature, or at
the very least get tangled up in assumptions about how a specific WM
works.

I had previously tried to lump the code-assist and helper pop-up windows
under some kind of "popup" type, here:
http://mail.gnome.org/archives/wm-spec-list/2005-June/msg00064.html

I'm not sure I know how these would work in detail though.

Notifications from the taskbar (your #1 I think) have some design
available:
http://www.gnome.org/~clarkbw/blog/GNOME/nostrum

But I don't know if KDE wants to do it the same way, and nobody has
implemented anything afaik.

Basically we need someone to prototype these in a toolkit+WM pair
(paying attention to all the little details and corner behaviors) then
we'll have good knowledge of what the spec should have in it.

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

I think bugs like the ones you mentioned are a pretty inevitable
consequence of toolkit and WM diversity; people will just mess up or
diverge sometimes, usually by accident.

That said, it seems pretty easy to fix this sort of thing (mostly just a
matter of writing code).

To me the purpose of the semantic types is not to allow the more
creative WM behaviors (I think EWMH mostly assumes a GNOME/KDE style of
desktop already). I just think they are a cleaner design than other
approaches and allow WMs to be a lot smarter. Metacity uses the semantic
type info all over the place.

Havoc