Re: Still need a hint for undecorated windows

[Havoc Pennington <hp redhat com>]

On Tue, 2005-06-28 at 17:47 +0100, Bill Haneman wrote:
> >TYPE_TOP would not be a type, it would be a state. </nitpick>
> >
> >If you want a type it would probably be TYPE_ONSCREEN_KEYBOARD
> >  
> >
> But since it would be the same behavior as required for a magnifier, 
> this doesn't seem right to me.  The desired behavior is not exclusive to 
> OSKs.

The desired *stacking behavior* yes, but there are lots of other
behaviors. I'd expect desirable focus behavior could be different for a
magnifier vs. OSK for example, though I don't know. 

Maybe these two things are the same type but "same stacking behavior"
isn't enough to make them the same. We need to be able to articulate
what property they have in common that will imply the same focus
behavior, same placement policy, same (non)decorations, etc.
If we can articulate that property, it's probably the name of the
_NET_WM_TYPE. If we can't, they are probably separate types.

The missing thing in my mind is really documenting how these AT windows
should be treated in all the places that the WM currently pays attention
to window type.

To give you an idea, according to a quick metacity grep the type
currently affects:

 - placement and size constraints
 - whether focus clicks are "eaten" in application-based mode
 - whether an EnterNotify focuses the window in mouse focus mode
 - whether EnterNotify raises the window in mouse focus mode
 - whether clicking focuses the window
 - whether the window has keybindings
 - details of the placement algorithm
 - window decoration style
 - default focus window
 - window stacking order in various ways
 - show desktop mode behavior
 - behavior with respect to workspaces
 - configure request honoring
 - available menu operations on the window

Most of these are about the DOCK, DESKTOP, or DIALOG types. But just to
give an idea how much the window types are _not_ just about stacking
order.

If there are any unique behaviors for the AT windows, then we'd probably
add those behaviors to the above list.

> I agree about the REALLY_ON_TOP, i.e. if non assistive technologies 
> start using it the whole thing falls apart.  But that's the current 
> problem with making 'on top' a 'state', IIRC.  We need a TYPE because 
> types map to "layers", don't they?

No, layers are an orthogonal concept. Sometimes types imply things about
layers, but only because of the specifics of a type such as DOCK.
There's no inherent connection.

> What's wrong with TYPE_OVERLAY (provided we document the fact that it's 
> needed by onscreen keyboards, magnifiers, and other assistive 
> technologies that need never to be obscured by other windows) ?

Because we don't know what else to do with TYPE_OVERLAY.

What we need to know is how these windows should work on all the many
dimensions I just mentioned, not only stacking order.

Havoc