Gregory Merchan wrote:
As before, I'm just laying it all out there. Brief summary:
1. All window management policies set focus without exception in
certain cases. (E.g. Alt+Tab, viewport changes.)
No. All the compositor can do is send a focus-request-event to the
client. The client is allowed to ignore it. The compositor has to
support this anyway because the client may be dead and not responding to
the focus change.
The reason is so that the client can atomically make changes to it's
display, window stacking, and visibility of windows to match the current
focus. This is a Wayland design requirement ("glitch free update") and
there is no way to do this unless the client has final say.
2. The policies may be distinguished first by additional cases in
which they set focus without exception. (The five I mentioned.)
The compositor is not allowed to "set focus without exception". However
the "policies" could be distinguished by when the compositor sends
focus-request-event. It is also possible that the "policy" must be known
by the client.
Windows has an elaborate kludge. Basically it acts like X in that clicks
always activate applications. However if the application manages to do the
right system calls so that Windows thinks something is being dragged it then
undoes the activation. This can botch up if the other active app dies just
at this moment.
Have you found a way to do it one Windows? I searched the API I could
find and saw nothing, hence I suppose it's a private thing for just
Explorer. (Or whatever their file manager is called.)
You may be right that it is a hidden API used by Explorer. I never found
a way. However it is very easy to make *no* clicks raise a window by
just not calling the "dispatch" function. I have not found any way get a
working application by calling "dispatch" sometimes (it seems if you
miss one call it ignores all others). But I felt this was close to a
working approach.
As the developer of a cross-platform toolkit, I would think you would
appreciate as much parity as possible between platforms. I know I've
seen comments in at least one toolkit's code where a developer
grumbled about some difference between systems that required extra
work or weird hacks. (I think it was Gtk, but the comment is not where
I remember it being.)
What I would like is for Wayland to allow maximum freedom for the client
to anything it wants. This then reduces the toolkit writers' pain to
only the *other* platforms, since they can simulate any result they
achieve there on Wayland.
In particular a client must be in absolute total final control over the
window stacking and visiblity and must be able to make it look like the
keyboard focus is on any window as long as the compositor thinks it is
on some window belonging to the same client.
Our notions of "entire and 100% in control" are different. For me that
would mean a client can raise its windows above all others any time
for whatever reason, or, in a word, chaos.
I mean that a window is not raised (or mapped or unmapped) unless the
client requests it. This is so that it is impossible for the compositor
to place windows in a stacking order different than the client wants.
The compositor is allowed to ignore requests. I hope this will be
designed to be very lenient, with the primary design goal to prevent
hostile clients, rather than trying to enforce user interface rules. But
the boundary is pretty vague.
No this is absolutely irrelevant. The compositor NEVER NEVER NEVER raises a
surface unless the client requests it. Therefore it does not need any
knowledge of the areas of the surface!
I'm inclined to NEVER NEVER NEVER respond to any email that puts
anything in all caps, especially when the person yelling hasn't
understood what I've said.
Sorry. However I am very concerned with any proposal that sounds like
the client does not have final say. This will violate the Wayland design
criteria of glitch-free update because the client will have to redraw
and map/unmap/restack windows to "fix" the result after the compositor
does it.
Jason has posted patches for frames in Wayland.
I think there will have to be support for compositor-supplied frames,
but I think the main reason is to support remote display on a legacy
system where it is impractical to remove the remote display's frames.
Also the current fullscreen already can tell the client to not draw
frames so this should be merged. And it may be useful for tiling and
tabbing and other experimental window management.
The "frame" and "titlebar" should be distinguished. A "maximized" app
should have a titlebar but no frame (this is currently ignored by
Wayland and lots of X window managers, I am unclear why people cannot
see this bug!).
I would limit the api to the compositor being able to tell the client
whether to draw the frame and titlebar. This may have to be merged with
the configure request event. And minimal information from the client: a
UTF-8 window name (null for no frame), an icon surface, and the window
parenting tree are all you get.
I am not at all happy with KDE's idea to replicate legacy systems
unnecessarily in a Wayland compositor. To correctly do compositor frames
an *enormous* amount of crap needs to be communicated from the client to
the compositor, which like ICCCM and _NET_WM_* will quickly become
bigger and more bug-ridden than the rest of the Wayland api.
Lowering below other clients' windows in the space of freely moving
windows (not desktop, not OSD, not "on the glass" etc.) is probably
best left to some equally obscure mouse and modifier combination
handled by the compositor.
I certainly rely on middle-mouse-click on title to lower all the time
and would not be happy if it is impossible. However it may be acceptable
if this is done by the compositor move/resize fallback for handling events.
Rearrange the windows of one's own client
is shouldn't be a problem. Something like XRestackWindows() comes to
mind. Of course, that allows the temporary surface trick.
I think a client can get any order it wants by changing the window
parent tree and then raising the bottommost window that is in the
"wrong" place. No other api is needed.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
