Gregory Merchan wrote:
The beginning of a drag is not the only event which a client may deem
inappropriate for activation. A client, such as a drawing program,
with a free-floating palette would want for its primary window to
remain active when toggle buttons on the palette are clicked. A more
complicated program might have a palette with non-window-activating
toggle buttons, but other controls which are window activating.
The client itself is probably active and can activate it's main surface
and not the toolbox on clicks. I think compositors should allow a client
to claim any surface is the active one as long as it thinks some surface
belonging to the client can be active.
Clients may allow their scroll bars to be used without activating a
window.
This is a great example and shows that drag & drop is not the only place
that clients should be responsible for activation.
Most client authors will use a toolkit, and that toolkit can make the
right behavior easy.
Yes, toolkits are the proper place for setting the "this widget works
this way" controls. The problem with X and Windows (and maybe OS/X) is
too much of this setting must be communicated to the compositor through
some kind of ipc, slowing down initialization, making it sometimes
impossible to change the settings, and adding a huge amount of
complexity to the api.
A sometimes convenient way to handle some of this on X is to rely on
button event fall through. Where the client expresses no interest in
button events, they fall through to the window manager's frame window
and the window manager is then responsible. I don't think there's a
similar thing in Wayland, so that may be irrelevant. I think there is
something like this in Cocoa, but it's been to long since I grokked
that.
Wayland provides the compositor move + resize api. The client calls this
in response to button clicks in window borders. This is pretty much the
"fallback" api.
I think this could be improved a little by adding this:
1. A way to tell the compositor to choose whether to drag or resize, and
what borders, based on the mouse position. This is to allow the
compositor to be in charge of how thick the resize edges are.
2. Another call to "preview", indicating that the current mouse position
if clicked will in fact cause the move/resize api to be called. The
compositor can then change the cursor or highlight the edges to show
this. There also has to be a way to turn this preview off.
In the end I hope this will get rid of the need for resize edges and
title bars to take any pixels. Clients will just have to make sure there
is some place near the edges that when clicked cause the move/resize api
to be called. Compositors will still be in control of window edge
snapping, etc.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
