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 _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
