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
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
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|
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
On 19 February 2014 13:35, Daniel Stone dan...@fooishbar.org 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:
On 18 February 2014 07:09, Peter Hutterer peter.hutte...@who-t.net 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
Hi,
this patch still applies after the xwayland branch rebase. Pinging for review.
Thanks,
Rui
On 22 October 2013 16:52, Rui Matos tiagoma...@gmail.com 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
Review ping.
On 24 October 2013 19:28, Rui Matos tiagoma...@gmail.com 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
On 3 January 2014 20:59, Tobias Sarnowski tob...@sarnowski.io 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
Hi,
just replying to this part:
On 15 October 2013 22:05, Matthias Clasen matthias.cla...@gmail.com 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
Hi,
On 7 October 2013 16:27, Daniel Stone dan...@fooishbar.org 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
Hi,
On 7 October 2013 20:16, Ran Benita ran...@gmail.com 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
On 13 May 2011 18:59, Mike Paquette paquette...@gmail.com 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
13 matches
Mail list logo