On Fri, Mar 02, 2018 at 06:16:34PM +1000, Peter Hutterer wrote:
> This makes it possible for callers to detect whether a touch device is
> single or multitouch (or even check for things like dual-touch vs real
> multi-touch) and adjust the interface accordingly.
>
> Note that this is for touch dev
On Wed, Mar 14, 2018 at 06:41:53AM -0400, Simon Ser wrote:
> On March 14, 2018 10:22 AM, Peter Hutterer wrote:
> > sorry about the delay, but better late than too late ;)
>
> No problem, thanks for your review!
>
> > On Sun, Mar 11, 2018 at 05:53:42PM -0400, Simon Ser wrote:
> > > This adds a ne
Semi-MT devices provide a bounding box of the fingers, and internally we don't
treat them as real MT device. Depending which finger currently provides
ABS_X/Y we may get a large jump when the other finger is released.
Basic sequence is finger 1 down, finger 2 down, finger 1 up.
On the last interact
How about:
If the client chooses not to use server-side decorations, it may be
responsible for its own window management operations.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland
>> If server and client do not negotiate the use of a server-side
>> decoration using this protocol, clients continue to self-decorate as
>> they see fit."
>
> The wording here is weird, and I want to avoid the word decorate. What
> the client does is not necessarily decorate. The reason why clien
On 2018-03-19 4:42 AM, Eike Hein wrote:
> How about:
>
>
>
+1
> And as description:
>
> "This interface allows a server to announce support for server-side
> decorations and optionally express a preference for using them.
>
> A client can use this protocol to request being decorated by a
>
How about:
And as description:
"This interface allows a server to announce support for server-side
decorations and optionally express a preference for using them.
A client can use this protocol to request being decorated by a
supporting server.
If server and client do not negotiate the use
To summarize the state of affairs here, the purpose of this protocol is
to communicate:
- The compositor's preference to use SSD or leave the client to its own
devices
- The choice of the client to have SSD displayed
We can completely remove CSD from the question because the term is
barely mean
On March 16, 2018 1:22 PM, Pekka Paalanen wrote:
> > > I'm missing a comment that describes what happens if the xdg_toplevel is
> > > destroyed. There is some object dependency here that needs to be stated.
> > > Do
> > > we need an event here? Or are we assuming that clients are smart enough to
Send a synthetic configure notify event to the reparented window to
update the position in Xwayland. This fixes menu positioning in clients
like VLC after moving the window.
---
xwayland/window-manager.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xwayland/wind
Some windows might get a create_notify event without the
override redirect flag set and then get a confiure_notify
event before map_request is received. This means that when
weston_wm_window_get_child_position is called in response
to configure_notify, the wrong offsets are computed resulting
in wr
Xwayland windows might be created with a different override redirect
flag than is given on map or configure notify. This causes confusion
about whether a window should be treated as override redirect or not.
Here we handle the changing override redirect flag in relevant notify
handlers so windows a
Hi Eike,
On 18 March 2018 at 16:35, Eike Hein wrote:
> On 03/18/2018 03:55 PM, Markus Ongyerth wrote:
>>> a) Change the definition of "decoration" to "window controls as deemed
>>> appropriate by the compositor, for example ...". This leaves what's in a
>>> server-side deco and what's in a client
Hi,
On 18 March 2018 at 16:22, Eike Hein wrote:
> On 03/18/2018 10:45 PM, Daniel Stone wrote:
>> That strikes me as a problem. So what can we do to bridge the gap
>> between these projects?
>
> FWIW, I agree this is a problem. KDE's Wayland contributor base is
> slowly growing, though - we have m
On 03/18/2018 03:55 PM, Markus Ongyerth wrote:
>> a) Change the definition of "decoration" to "window controls as deemed
>> appropriate by the compositor, for example ...". This leaves what's in a
>> server-side deco and what's in a client-side deco up to servers and
>> clients, respectively, and
On 03/18/2018 10:45 PM, Daniel Stone wrote:
> That strikes me as a problem. So what can we do to bridge the gap
> between these projects?
FWIW, I agree this is a problem. KDE's Wayland contributor base is
slowly growing, though - we have more people working on Wayland stuff
than we had previousl
Sorry, I messed up my quoting, cutting down the mail =.=
I wanted to keep the part that ended in:
> Yes, but I think this reinforces my point. If an IVI, phone or
> set-top-box compositor suddenly started sticking decorations on the
> surfaces it found, it wouldn't be useful. Saying 'but the clie
On 2018/3月/18 01:45, Daniel Stone wrote:
> Hi Drew,
>
> On 15 March 2018 at 16:53, Drew DeVault wrote:
> >> > In fact, I have done so. Before we started working on this protocol,
> >> > Sway did exactly this. We have provided users the means of overriding
> >> > the approach to decorations, inclu
On 2018-03-18 1:45 PM, Daniel Stone wrote:
> I don't think prolonging the argument is helpful. Just a fairly clear
> statement that in the absence of this extension and unless told
> otherwise, clients which can decorate themselves, should decorate
> themselves, would work for me. I don't want to
Hi Drew,
On 15 March 2018 at 16:53, Drew DeVault wrote:
>> Denying facts and being disingenuous doesn't help anyone, and it's
>> tiring. Tiring enough that I came into this thread with the intention
>> of giving this protocol a couple of suggestions and a push towards
>> getting it merged, becaus
20 matches
Mail list logo