Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

Hi,

Look, here's the thought experiment.

Say you want a window type that behaves as (just making some crap up):

 - stacking order always keeps it just above the desktop background
 - special single-pixel decoration matching the WM theme
 - only focused on ctrl+click
 - stays visible when showing desktop
 - not in tasklist
 - on all workspaces
 - automatically tiled to avoid other windows of this type
 - does not have the window manager alt-right-click menu
 - ...

You can implement some of that in an app today using bits of the WM spec
and assorted hacks, and you can't implement some other bits of it.

There are other examples. A good one is "drawers" as in OS X.

Conclusions:

  -> Given a human-centered top-down design of a given window type 
     or application, you can come up with arbitrary ways a window
     should look and act and relate to other windows. In a top-down
     design normally we'd ignore what X11 and window managers happen 
     to support today.

  -> There is absolutely no reason to expect that for a new design 
     of this kind, the WM specs and X protocol will just happen to 
     support some way to implement every single detail. In fact it 
     would be surprising if the specs did support that, since 
     it's a new design and nobody thought about it yet.

Now, if X11 and ICCCM had implemented window behavior in the
toolkit/app, you could expect that for any new design you came up with,
it was probably possible to implement largely by modifying your own
application; because the window manager would be a simple policy-free
display engine, similar to the X server itself.

However, this is not how X11 and the ICCCM implemented window behavior.
Instead they put it in a separate, global process.

The logical outcome is that this separate, global process knows about a
finite, predetermined number of window behaviors.

Now, we can specify those in an enum (like _NET_WM_WINDOW_TYPE) or we
can do it as combinations of parameters (like _NET_WM_STATE), but
however you specify the behaviors, they are _finite_.

I'm saying _it is a fact of the architecture_ that there's a fixed
number of window types.

When writing metacity, I did not provide a way to upload Lisp to the
window manager implementing new kinds of window.

On Wed, 2005-08-03 at 14:09 -0400, Adam Jackson wrote:
> These windows want to behave exactly like top-layer, full-screen windows.  And 
> the desired semantics are almost exactly what you'd get with TYPE_NORMAL 
> minus the decorations: place the window exactly where it asks, normal focus 
> and stacking policy, only visible on the current virtual desktop, hide it 
> when you hit Show Desktop, etc.  And I think (IANA toolkit guy, or even an 
> app guy) that's pretty close to what xmms wants too.

I would say what you're arguing here is that TYPE_NORMAL_BUT_UNDECORATED
should be one of the types the WM knows about. Or perhaps the WM should
know about 2x the number of types it knows today by multiplying each
_NET_WM_WINDOW_TYPE by a DECORATED flag - but this is just a shorthand
to prevent a huge enum, it's not a logically distinct proposal.

Advocating this specific set of types is _different_ from arguing that
there should not be a fixed set of window types.

If you're arguing there should not be a fixed set of window types, I'd
argue go join the flat earth club, because as long as the X architecture
stays as it is, and we don't implement uploading Lisp scripts to the WM,
there's going to be a fixed set of window types.

If you concede there's a fixed set of window types, then we have to
discuss what those types should be.

So my argument #2 is that TYPE_NORMAL_BUT_UNDECORATED is probably wrong.

For your example app, my guess is that most "typical" window managers
(kwin? metacity?) already do screw up some of the details of how this
app works; and the more unusual window managers (ion?) would hose it
entirely.

It also sounds like the app could be much _improved_ with WM support. If
you're tiling the windows together, the WM could guarantee they stay
that way and stick together in the stacking order, for example.

I'm not sure I understand exactly what the app is from your description,
though, and to decide what its type is we would need you to spell it out
in more detail with all the behaviors. Once it was spelled out that way,
we know how to extend the spec, possibly with
TYPE_NORMAL_BUT_UNDECORATED.

> There's no netwm hint for this; the spec really says "here's some semantic 
> types, they replace the mwm hints", which means if there's no type you want 
> then you're out of luck.  You do see how that's hostile, right?

I'm not making any kind of moral argument. I'm explaining reality.

The logical/engineering consequence of putting window behavior in
process A and desired-UI-design in process B is that process A has to
have support built-in for whatever UI design process B wants process A
to implement on its behalf. Otherwise process B will not get the UI it
wants.

I don't know how to write a process A that supports any UI design anyone
can imagine, short of the upload-Lisp strawman.

That's it.

Some people on this list _are_ making a moral argument, I grant you.
This argument is something like: policy has to be in the WM so users
have choice and blah blah. I think that's more or less nonsense, I
personally don't care whether geeks can do silly things and I'm known to
rant that "policy vs. mechanism" is a stupid slogan.

What I do care about is that it's possible to implement detailed,
polished UI designs in a robust way. And with the current X design, this
means the WM has to know about the possible kinds of window.

> OSK and other accessibility gadgets probably want something different, as do 
> output-only glitter windows or Wine windows or whatever.  Fine.  How purist 
> do you want to be here?  Do you really want netwm to be the holy enumeration 
> of all the valid semantic types?

My argument is that the WM specs must encode any type you want to have,
whether by semantic type or by variations on them (like all the
_NET_WM_STATE flags for stacking, etc.)

You imply that there's some alternative, and there isn't. The "apps can
do whatever they want" way _doesn't work_ as a matter of engineering.

>   If you do so, you're actively inhibiting 
> the creation and deployment of new types,

Which is mandated by reality unless we do the upload-Lisp-scripts thing.

Yes, this slows down ability to do certain things in apps. For example,
I've wanted to code OS X style drawers in GTK+, but it's going to
involve some complicated interaction with the window manager which gives
me pause. This will make it hard to deploy the new feature because the
WM spec and other WMs have to get on board. It sucks, but well,
sometimes life sucks. It's just an outcome of a design decision made 15
years ago. XMMS and so forth are pretty much the same situation.

Before we cry too much we might want to go read the Mac UI guidelines
which specify only around 4 kinds of window.

>  and you still haven't documented 
> the canonical way to get rid of the decorations.  They're nearly orthogonal 
> issues, but I would like to see at least one of them resolved.

There's a way to get rid of decorations now, which is the MWM hint. I'm
not being purist; I implemented the hint along with everyone else. The
short-term fix is in place. Great.

Now, let's talk about what the nice robust polished-UI fix would be.

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.

One of the reasons I'd like to avoid the MWM-hint approach is that it
keeps us from narrowing down TYPE_NORMAL; I'd like to really make this
type mean "main app window" and push things like XMMS into a separate,
clearly-marked type. This allows the WM to do nicer things with
TYPE_NORMAL since TYPE_NORMAL becomes more meaningful.

This is one reason I happen to think NORMAL_UNDECORATED is a hack. It's
an empirical question that can be hashed out by writing down the desired
behaviors and characterizing the different window types, though. It's
not a matter of reality or principle.

What _is_ a matter of reality is that yes, we have to characterize the
different window types app programmers can ask the WM to create, so the
WM authors can write code that implements these window types. When I say
apps can't make up window types, I mean they _can't_, not that they
_shouldn't_.

Havoc