Re: Allowing a11y windows to be on top - bug #136159



Lubos Lunak wrote:


... types like "DOCK" already are semantic.

And are you sure that the semantics of DOCK are the same like those of a onscreen keyboard or magnifier? Perhaps it should be first stated what the expected semantics of them are, because for one I don't know.
I mean that WM_TYPE_DOCK, and the word "DOCK", have semantic content. Therefore it makes no sense to me to say "don't use a WM_TYPENAME that implies semantics", since existing WM_TYPEs already do have semantics IMO

Things other than keyboards (for instance magnifiers) and even
non-accessibility windows (for instance overlays, transparent windows,
etc.) may want to declare this type as well.  The real requirement is
for a window type that's _above_ DOCK, therefore ABOVEALL makes the most
sense.

I disagree. If we go this way, we'll end up with ABOVE, ABOVEALL, REALLYABOVEALL, ABOVEEVERYTHING and hell knows what else, with unclear meaning. BTW, KWin does keep ABOVE windows above DOCK, I find it more logical that way.
WM_ABOVEALL still seems right to me. I think later adding ABOVEALL_NO_REALLY_I_MEANIT would just be random abuse; if we define ABOVEALL then that layer should be the top layer forever and any new layers defined in the spec would go underneath it.

I think TYPE_ACCESSIBILITY and TYPE_KEYBOARD are wrong because they actually give imply wrong semantic information (fi applied to
magnifiers, or non-accessibility-specific features).

I think it's simple to find out who to blame for strange things happening with e.g. a magnifier window with TYPE_KEYBOARD set.
But my point is that magnifiers and onscreen keyboards have the SAME NEEDS with respect to the window manager; defining separate types for these would be pointless. If we want to suggest in the WM_TYPE name what the uses for the type should be (which seems like semantics to me ;-), then the common feature of the usecases is, err, must-be-the-top-layer, i.e. ABOVEALL.

Havoc's suggestion of WM_TYPE_OVERLAY makes sense too; it has semantic content, and while it doesn't narrowly define the use cases, it does strongly suggest that using this type might cause unusual behavior if applied to a "normal" application window.

- Bill




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