Re: Still need a hint for undecorated windows



Havoc Pennington wrote:

On Tue, 2005-06-28 at 13:18 +0100, Bill Haneman wrote:
- onscreen keyboard, which we could never specify the behavior of
in enough detail to put in the spec, or maybe we just decided it was a dock, I don't remember


DOCK doesn't work because it means that the onscreen keyboard is liable to be obscured by other windows of type DOCK, in particular focussed popups. So we need something that is really truly in a higher layer : not just for onscreen keyboards, but also for magnifiers. The always-on-top hints don't seem to work because of the interpretation of how stacking within a layer is supposed to work, so the consensus was IIRC that we needed a new layer. I prefer TYPE_OVERLAY or TYPE_TOP (the latter implying that any future additions would be guaranteed to stack underneath this type).


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.

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?

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

Bill

(conceivably possible to generalize further) and imply things about
focus, decorations, etc. in addition to stacking order.

The problem with the STATE_REALLY_ON_TOP is that you may find people
other than the onscreen keyboard will use it rather than STATE_ABOVE,
and then you'll have to add STATE_REALLY_REALLY_REALLY_ON_TOP ;-)

Havoc






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]