Re: Still need a hint for undecorated windows

[Bill Haneman <Bill Haneman Sun COM>]

Havoc Pennington wrote:

> 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. 
>  
At the moment, the desired focus behavior is the same too, and for the 
cases I can currently anticipate that need this "type", I think 
never-take-focus is correct.  The properties could be described as "stay 
in the topmost layer always, and don't take focus".  That's why I 
suggested "OVERLAY" because I think that noun roughly describes those 
semantics.  Another implied behavior of "don't take focus" may be that, 
if such a TYPE is decorated at all, it probably should not be decorated 
in the "normal" way, e.g. in most cases titlebars, close boxes, and the 
like are undesirable.

> 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.
>  
Okay, when I get back from vacation in a couple of weeks, I'll try to 
write up a short desription of the desired behaviors that these "AT" 
windows will have in common, using the list you provided above.  It 
looks like a good starting point.

Thanks for helping to define the issue(s) more clearly!

Bill

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