Batching text input protocol changes

2020-02-17 Thread Dorota Czaplejewicz
Hi all,

over the past month, the zwp_text_input_v3 protocol has moved to real devices 
and had seen unprecedented usage. Together with that, it also got a reality 
check, from which it didn't come unscathed. There are some issues identified:

- a hint that there's no need for an on-screen keyboard
- allow deleting text even when surrounding text is unknown
- making it harder for compositors to send uninformed updates 
https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/16
- possibly graceful switching within text inputs 
https://gitlab.gnome.org/GNOME/gtk/issues/2437
- sending control events (submit, next field, undo) to gain independence from a 
virtual keyboard protocol

I might have left something out.

Since they are all relatively unrelated, they can thankfully be discussed 
separately. But merging them in separately would create needlessly many 
combinations of possible supported versions.

A new integration branch on gitlab would keep related merge requests on the 
wayland-protocols repo, and it could be merged as one large update once it's 
sufficiently hardened. Or is there another way to do this?

Thanks,
Dorota Czaplejewicz


pgps4bzpQyeb6.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


Re: repaint after notify_button() ?

2020-02-17 Thread Pekka Paalanen
On Fri, 14 Feb 2020 17:25:49 +
Josh Simonot  wrote:

> Aha!  That's the problem:  I call notify_*() from my own thread which
> reads a socket fd from a remote server.  Sounds like the correct way
> to do this is use wl_event_loop_add_fd() to register the socket, and
> read from the fd in the callback?

Hi,

yes.

> I have some non-input messages that need to remain async from
> weston's event loop (ex. some setup during compositor start),  so I
> did a test by keeping the notify_*() event calls in my thread and
> then "dispatch" the event loop by sending a signal over a pipe which
> I registered with wl_event_loop_add_fd().  This appears to be
> working!  I just want to make sure there's no obvious
> problems/race-conditions that come to mind with calling notify_*()
> asynchronously?

Nothing in libweston is meant to be thread-safe, so I'm surprised it
didn't explode more spectacularly, but perhaps that is just a matter of
time.

I very much recommend to not call any libwayland-server or libweston
functions or access any data used by them from another thread.


Thanks,
pq


pgp5LUzl5gIGK.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel