Hi,
thanks for sending this. I was actually going to start a discussion
about the existing protocol but let's go from here instead. Comments
inline:
First a question of scope: a client would only ever need to instance
one text_input object per wl_seat and then "associate" it with a
particular wl_
Hi,
Thanks for the update. I'm replying to both v4 and your reply to my
previous mail. Inline:
On Tue, Feb 2, 2016 at 2:33 PM, Jan Arne Petersen wrote:
> +
> +
> + Disable text input in a surface (typically when there is no focus on
> any
> + text entry inside the surface)
On Mon, Feb 8, 2016 at 7:07 PM, Bill Spitzak wrote:
> The x and y have to be signed. Imagine if the client is scrolled in such a
> way that the cursor rectangle is partially outside the surface.
Are you saying this is an acceptable case:
++
|compositor popup|
++
On Wed, Feb 17, 2016 at 6:13 AM, Jan Arne Petersen wrote:
>>> +
...
>>> +
>>> +
>>> +
>>> +
>>
>> These arguments could, and perhaps should, all be type="uint"
>
> Yes I guess for width/height.
As Jonas pointed out, just leave them as "int". One thing I now
noticed is
On 3 January 2014 20:59, Tobias Sarnowski wrote:
> does XWayland operate? From the highlevel documentation at
> http://wayland.freedesktop.org/xserver.html I conclude, that the X11 support
> is done via having a single Wayland client which then multiplexes the stuff
> internally to all X11 clients
Hi,
this patch still applies after the xwayland branch rebase. Pinging for review.
Thanks,
Rui
On 22 October 2013 16:52, Rui Matos wrote:
> This allows us to keep track of latched and locked modifiers as well
> as the XKB group while the keyboard focus is on another wayland
> client. Note that
Review ping.
On 24 October 2013 19:28, Rui Matos wrote:
> weston_xkb_info_create() takes ownership of the xkb_keymap instance so
> we should drop our reference or we would leak it later if the keymap
> was changed.
___
wayland-devel mailing list
wayland
On 11 February 2014 16:44, Axel Davy wrote:
> I have pending changes to this part to implement XWayland present support.
>
> Instead a having the wl_buffer attached to a window, I attach it to a
> pixmap.
>
> Could you test with this branch, and tell if you encounter the problems you
> have?
>
> h
On 18 February 2014 07:09, Peter Hutterer wrote:
> libevdev wraps the various peculiarities of the evdev kernel API into a
> type-safe API. It also buffers the device so checking for specific features at
> a later time is easier than re-issuing the ioctls. Plus, it gives us almost
> free support f
On 19 February 2014 13:35, Daniel Stone wrote:
> Can this be CLOCK_MONOTONIC_COARSE instead, to avoid griefing HPET and
> thus causing much higher power usage?
Makes sense and indeed the X server seems to use _COARSE if it's
available and has good enough resolution:
http://cgit.freedesktop.org/x
Hi,
On 7 October 2013 16:27, Daniel Stone wrote:
> But I'm really not sure about this. It's really hard to get this
> right, especially when you're changing modifier options. The only
> real workable solution I've seen is to pend the actual change until
> all keys have been released. So, in th
Hi,
On 7 October 2013 20:16, Ran Benita wrote:
> At least retaining the locked modifiers (and therefore the LED state in
> most cases) would be nice, and not too problematic I think (though some
> edge cases are expected).
Ok, the new version keeps both latched and locked modifiers.
> (Also, th
Hi,
just replying to this part:
On 15 October 2013 22:05, Matthias Clasen wrote:
> - input tweaks like slow keys or bounce keys or hover-to-click naturally fit
> in the event dispatching in the compositor
In the same spirit of having key repeat on the client side, I think
that slow, bounce and
On 13 May 2011 18:59, Mike Paquette wrote:
> I hope you guys don't mind my chiming in here.
Speaking only for myself as mostly a lurker on this list, I very much
welcome your insightful and experienced remarks. Thanks for sharing!
> The way I handled a window resize was to grow or shrink the win
14 matches
Mail list logo
