Re: Window types (Re: [Usability] Resizability of windows)

["Elijah Newren" <newren gmail com>]

On 5/4/06, Matthew Paul Thomas <mpt myrealbox com> wrote:
> But the four things I want to do most often with a splash screen are
> (1) minimize it ("get out of my way!"), (2) move it ("get out of my
> way!"), (3) return it to the front ("... wait, did that say
> OpenOffice.org 1.1? I thought I'd launched 2.0!"), and (4) cut out its
> heart with a spoon ("get out of my way!"). Are you saying I can't do
> any of those? :-)

Metacity hasn't currently implemented such policies, but the existence
of the splashscreen hint means that such policies could be implemented
by metacity or any other window manager (including more hostile
versions: auto-minimize, refuse-to-map, map-offscreen,
placed-below-the-nautilus-desktop-window, run-kill-on-relevant-PID,
warn-user-that-a-"virus"-has-infected-their-system,
attempt-to-cleanse-said-"virus"-from-their-system), all without
adversely affecting behavior for any other window types.  :-)

> On further thought, if it's not too silly to give a splash screen a
> title bar (and splash screens are already pretty silly), they can quite
> easily be a subset of progress windows (which they already are, in
> functional terms). The title bar would allow moving, and would have a
> minimize button and no others, just like any other progress window.

Yes, that's fully possible.  Given that we have a hint to allow us to
recognize such windows, we can tailor our implementation pretty much
however we want.  (We used to place them above all other windows, then
got a complaint from the Eclipse developers since their splashscreen
hung around for 30 seconds or so...)

> 1.  Why are _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_UTILITY
>      separate types? The spec says "...UTILITY ... is distinct from type
>      TOOLBAR because it does not correspond to a toolbar torn off from
>      the main application". Yes, but so what?

I dunno.  Ask on wm-spec-list.  Or find one of the Gnome developers
who was around for the relevant conversations at the time.

> 2.  What type are tooltips? It's a bit hard to tell that with xprop :-)

Override-redirect windows don't currently have a type specified by
application authors, because the window manager doesn't manage them
(the name comes from the fact that applications specify that X11's
normal redirect of requests to the window manager should be
overridden).  The applications (or the toolkit used by the apps) are
currently fully responsible for the behavior/looks/etc of such
windows.  Other examples of override-redirect windows include
application menus, right-click popup menus, notifications, things like
drop-down lists from combo box widgets, and icons shown during DND. 
Soeren has proposed having such windows get a type, because the
compositor will need to do special things with them.  If his proposal
becomes part of the spec (looks likely) then tooltips will have a type
of _NET_WM_WINDOW_TYPE_TOOLTIP.

> 3.  Would any problems arise if this was true? "Metacity treats a
>      window as an alert if both (1) it has _NET_WM_WINDOW_TYPE_DIALOG
>      (or if WM_TRANSIENT_FOR is set but not _NET_WM_WINDOW_TYPE), and
>      (2) it has no title. If an alert opens for a window that is not in
>      front, Metacity sets _NET_WM_STATE_DEMANDS_ATTENTION for the window
>      automatically."

Might break some Java apps.  Of course, they're already broken
(http://bugzilla.gnome.org/show_bug.cgi?id=160236), so maybe another
log on the fire will get the appropriate Java people to fix it --
right?  ;)  That's the only possible "problem" I can think of.