Re: Should I port my custom UI toolkit to Wayland or GTK/QT?

[Dorota Czaplejewicz]

Hi Brad,

On Sat, 30 Oct 2021 10:58:59 +1100
Brad Robinson  wrote:

> 2. Are there options for IME and Accessibility for pure Wayland apps?

Yes, there are at least 2 approaches:

- embed the IME in your application, like GNOME/Mutter seems to be doing (I'm 
not super acquainted with that)
- use the text-input and related protocols. They are still far from perfect or 
complete, but they have some momentum.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/wip/text-input-next
 (also see the countless issues and merge requests in the same repo).

Cheers,
Dorota


pgpocTi2khQ_z.pgp
Description: OpenPGP digital signature

Re: Virtual keyboard changes system keyboard layout under sway - why?

[Dorota Czaplejewicz]

Hello Justus,

On Mon, 06 Apr 2020 14:36:03 +0200
justus-...@piater.name wrote:

> Hello,
> 
> In my quest for an on-screen keyboard (OSK) for sway, the closest I've
> found are Purism's squeekboard and virtboard.  They both use the Wayland
> virtual keyboard protocol.  Surprisingly (to me), they affect my
> installed keyboard layout:
> 
> 1. They install a session-wide keyboard layout and leave it behind, at
>least if terminated improperly.
> 
> 2. Afterwards, I cannot reset my keyboard layout using 'swaymsg input
>... xkb_layout de'; it silently runs without taking effect.
>Running 'swaymsg reload' does restore it though.
> 
> The second phenomenon is surely a defect? In sway, wlroots, or
> {virt|squeek}board? Or is it just that I am trying to abuse Purism's
> OSKs outside their purpose of serving as the only keyboard present on a
> system?
> 
The OSKs are meant to be universal as much as possible, and not tied to any 
particular system (just Wayland).

> How about the first point? In my naive world view, the OSK should use
> any layout I tell it to use, but it should leave intact the layout of
> any other keyboard I happen to have on my system.  I can attach an
> external keyboard with en_US layout to my laptop with de layout.  Why
> can't I additionally run a French azerty OSK? And yet another Greek
> OSK at the same time?
> 
My understanding of how layouts work on Linux is a bit different than what you 
present here. I've observed that there is a global layout switch, and with 
multiple physical keyboards, I found that switching the layout affects all of 
them. Therefore, to make the on-screen keyboard work "as expected", I decided 
to make it follow that central authority (gnome input method setting).

Following the central authority only works well when it's done consistently, so 
I tied the keyboard language switch back to the system layout. This is simpler 
than having a different global layout and a different layout for a single 
keyboard, and hopefully spares users confusion (e.g. "I selected de in the 
system settings but my keyboard is still ru").

Frankly, what you're saying sounds sensible, but I don't know how to solve it 
on the application level without making things overly complicated. If you do, 
then the best channel to discuss that would be the Squeekboard issue tracker: 
https://source.puri.sm/Librem5/squeekboard/issues/

> I clearly lack understanding of how Wayland input protocols work, and
> hope someone over here will enlighten me.  In particular, is the
> behavior I describe above intentional or accidental?
> 
> My motivation is that I am trying to understand what it minimally takes
> to inject characters into applications under Wayland (specifically
> sway).  For example, for my touchscreen I would like to have an OSK and
> dasher [1].  For my scripted password manager, formerly based on
> xdotool, I wrote uinputchars [2], which works perfectly for me but is
> only a crutch until I have a proper Wayland solution.
> 
The solutions are the virtual-keyboard protocol 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/11
and the input-method protocol 
https://source.puri.sm/Librem5/squeekboard/blob/master/protocols/input-method-unstable-v2.xml
which depends on the text-input protocol 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/19

Best,
Dorota

> Thanks,
> Justus
> 
> 
> [1] https://github.com/dasher-project/dasher
> [2] https://github.com/piater/uinputchars
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: Batching text input protocol changes

[Dorota Czaplejewicz]

On Tue, 18 Feb 2020 16:20:08 +0100
Jonas Ådahl  wrote:

> On Tue, Feb 18, 2020 at 04:14:50PM +0100, Dorota Czaplejewicz wrote:
> > On Tue, 18 Feb 2020 10:12:11 +0200
> > Pekka Paalanen  wrote:
> >   
> > > On Mon, 17 Feb 2020 19:58:43 +0100
> > > Dorota Czaplejewicz  wrote:
> > >   
> > > > 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?
> > > 
> > > Hi Dorota,
> > > 
> > > sounds like you have a good reason to have an upstream branch like
> > > that, so that the work in progress won't stop the master branch from
> > > releasing. I would be fine with that.
> > > 
> > > Another way could be to start a new major version XML file, and exclude
> > > it from install by default. No-one could use it until you make it
> > > installable, so there would be no need to maintain implementations of
> > > the intermediate steps.
> > > 
> > > Mind the wayland-protocols governance rules.
> > > 
> > > 
> > > Thanks,
> > > pq  
> > 
> > Hi,
> > 
> > seeing the answers so far, I think starting a new branch is a good idea. In 
> > case there are major changes, a new major version could be created out of 
> > the new branch anyway.
> > 
> > Currently, there's only one change that's important and potentially 
> > backwards-incompatible, but that depends on the future discussion (deleting 
> > text being broke), so a new version might not be necessary yet.
> > 
> > Could someone with the permissions create such a branch?  
> 
> I created a branch called `wip/text-input-next`:
> 
> https://gitlab.freedesktop.org/wayland/wayland-protocols/commits/wip/text-input-next
> 
Thank you!
--Dorota

> 
> Jonas
> 
> > 
> > Thanks,
> > Dorota  


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

Re: Batching text input protocol changes

[Dorota Czaplejewicz]

On Tue, 18 Feb 2020 10:12:11 +0200
Pekka Paalanen  wrote:

> On Mon, 17 Feb 2020 19:58:43 +0100
> Dorota Czaplejewicz  wrote:
> 
> > 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?  
> 
> Hi Dorota,
> 
> sounds like you have a good reason to have an upstream branch like
> that, so that the work in progress won't stop the master branch from
> releasing. I would be fine with that.
> 
> Another way could be to start a new major version XML file, and exclude
> it from install by default. No-one could use it until you make it
> installable, so there would be no need to maintain implementations of
> the intermediate steps.
> 
> Mind the wayland-protocols governance rules.
> 
> 
> Thanks,
> pq

Hi,

seeing the answers so far, I think starting a new branch is a good idea. In 
case there are major changes, a new major version could be created out of the 
new branch anyway.

Currently, there's only one change that's important and potentially 
backwards-incompatible, but that depends on the future discussion (deleting 
text being broke), so a new version might not be necessary yet.

Could someone with the permissions create such a branch?

Thanks,
Dorota


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

Batching text input protocol changes

[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: Floating windows in input-method

[Dorota Czaplejewicz]

Hi Silvan,

On Mon, 16 Dec 2019 20:56:12 +0100
"Silvan Jegen"  wrote:

> Hi
> 
> Simon Ser  wrote:
> > Hi Dorota,
> > 
> > On Sunday, December 15, 2019 7:55 PM, Dorota Czaplejewicz 
> >  wrote:
> >   
> > > Hi all,
> > >
> > > in order to give this change more traction, I've been thinking about
> > > slimming down the protocol, and removing floating windows from this
> > > revision.
> > >
> > > This would make the protocol easier to implement, and since we
> > > already have an implementation missing this feature in wlroots, also
> > > effectively verified. We've been successfully using the protocol on
> > > the Librem 5, and completion windows seem like something possible to
> > > mimic using a protocol like layer-shell, and in the phone case, this
> > > would be the desirable way to do it.
> > >
> > > Since floating windows are usually used for CJK languages on the
> > > desktop, can I get some opinions? Do you think the protocol would be
> > > useful and an improvement over the v1 even if it didn't initially
> > > include floating windows?  
> > 
> > I think this is a good idea.
> > 
> > Doing this would ease protocol review and make it so the implementation
> > matches the protocol. The extra floating window bits can be added
> > later anyway, and we'll be able to discuss what's the best way to
> > implement them.  
> 
> Would the floating windows be added in a new version of the input-method
> protocol or do you think a new protocol would be used for that?
> 
It belongs to the same protocol, the input popup doesn't make sense if it isn't 
a response to an earlier activation of a text input, so a any floating window 
protocol would have to be tightly bound to input_method anyway.

> As Dorota mentioned, for CJK languages those are very
> important. Unfortunately I didn't get very far trying to implement a
> version of the input_popup [0][1] but I would like to know where their
> protocol should be added in your opinion.
> 
Hope that clarifies it.

Cheers,
Dorota
> 
> Cheers,
> 
> Silvan
> 
> 
> [0] https://github.com/Shugyousha/wlroots/commits/popupsurface
> [1] 
> https://lists.sr.ht/~sircmpwn/public-inbox/%3C2DLX6MQ13DS0R.25O72Q0XN9BGC%40homearch.localdomain%3E
> 
> 
> > Btw, we are now using GitLab for wayland-protocols development: feel
> > free to submit your patch there (and potentially your earlier pending
> > patches too!).
> > 
> > Thanks,
> > 
> > Simon
> >   
> > > Thanks,
> > > Dorota Czaplejewicz
> > >
> > > On Thu, 4 Oct 2018 20:00:13 +
> > > Dorota Czaplejewicz dorota.czaplejew...@puri.sm wrote:
> > >  
> > > > This protocol is based on v1, current text-input-v3, and wl_keyboard 
> > > > version 6.
> > > > The pieces passing data relevant to the application on the other side 
> > > > of the compositor are a mirror copy of text-input-v3 events and 
> > > > requests.
> > > > Compared to input-method-v1:
> > > >
> > > > -   assumes that once preedit is displayed, no selection can be active, 
> > > > removing some selection handling
> > > > -   follow text-input and removes language indicators
> > > > -   explicitly attaches to seats
> > > > -   removes "commit" text which would replace the preedit string 
> > > > automatically in case it wasn't "confirmed" (whatever it means)
> > > > -   adds double-buffering in the same places as text-input-v3
> > > > -   drops input_method_context and places its functionality directly in 
> > > > input_method
> > > > -   removes the ability to move the cursor position outside of preedit. 
> > > > It still allows to delete a larger chunk of text and replace it with a 
> > > > preedit
> > > > -   doesn't allow for sending of keyboard events to the compositor
> > > > -   doesn't define any surfaces except for a special 
> > > > compositor-positioned popup
> > > >
> > > > Hi,
> > > > continuing the RFC, I think this protocol is actually workable now, and 
> > > > I'm sending this with the PATCH qualifier.
> > > > The practical verification came in the form of a partial wlroots 
> > > > implementation [0]. The formal issues (chiefly stemming from 
> > > > copy-pasting things at night) have been pointed out to me by Simon, and 
> > > > corrected.
> > > > The major unverifi

Floating windows in input-method

[Dorota Czaplejewicz]

Hi all,

in order to give this change more traction, I've been thinking about slimming 
down the protocol, and removing floating windows from this revision.

This would make the protocol easier to implement, and since we already have an 
implementation missing this feature in wlroots, also effectively verified. 
We've been successfully using the protocol on the Librem 5, and completion 
windows seem like something possible to mimic using a protocol like 
layer-shell, and in the phone case, this would be the desirable way to do it.

Since floating windows are usually used for CJK languages on the desktop, can I 
get some opinions? Do you think the protocol would be useful and an improvement 
over the v1 even if it didn't initially include floating windows?

Thanks,
Dorota Czaplejewicz

On Thu,  4 Oct 2018 20:00:13 +
Dorota Czaplejewicz  wrote:

> This protocol is based on v1, current text-input-v3, and wl_keyboard version 
> 6.
> 
> The pieces passing data relevant to the application on the other side of the 
> compositor are a mirror copy of text-input-v3 events and requests.
> 
> Compared to input-method-v1:
> - assumes that once preedit is displayed, no selection can be active, 
> removing some selection handling
> - follow text-input and removes language indicators
> - explicitly attaches to seats
> - removes "commit" text which would replace the preedit string automatically 
> in case it wasn't "confirmed" (whatever it means)
> - adds double-buffering in the same places as text-input-v3
> - drops input_method_context and places its functionality directly in 
> input_method
> - removes the ability to move the cursor position outside of preedit. It 
> still allows to delete a larger chunk of text and replace it with a preedit
> - doesn't allow for sending of keyboard events to the compositor
> - doesn't define any surfaces except for a special compositor-positioned popup
> ---
> Hi,
> 
> continuing the RFC, I think this protocol is actually workable now, and I'm 
> sending this with the PATCH qualifier.
> 
> The practical verification came in the form of a partial wlroots 
> implementation [0]. The formal issues (chiefly stemming from copy-pasting 
> things at night) have been pointed out to me by Simon, and corrected.
> 
> The major unverified parts are keyboard grabs and popup surfaces, which I 
> will verify next.
> 
> Changes compared to the RFC:
> 
> - fixed so many confusing typos
> - renamed preedit_text request to set_preedit_text
> - described what happens when things get destroyed
> - defined the role of input_popup sorface and forbade it from being deleted
> - copied wl_keyboard to serve as the keyboard grab interface
> 
> I hope you can help me find the remaining issues and turn this interface into 
> reality!
> 
> Cheers,
> Dorota Czaplejewicz
> 
>  Makefile.am|   1 +
>  unstable/input-method/input-method-unstable-v2.xml | 490 
> +
>  2 files changed, 491 insertions(+)
>  create mode 100644 unstable/input-method/input-method-unstable-v2.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 6394e26..f3b9f80 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -7,6 +7,7 @@ unstable_protocols =  
> \
>   unstable/text-input/text-input-unstable-v1.xml  
> \
>   unstable/text-input/text-input-unstable-v3.xml  
> \
>   unstable/input-method/input-method-unstable-v1.xml  
> \
> + unstable/input-method/input-method-unstable-v2.xml  
> \
>   unstable/xdg-shell/xdg-shell-unstable-v5.xml
> \
>   unstable/xdg-shell/xdg-shell-unstable-v6.xml
> \
>   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> \
> diff --git a/unstable/input-method/input-method-unstable-v2.xml 
> b/unstable/input-method/input-method-unstable-v2.xml
> new file mode 100644
> index 000..62be9d9
> --- /dev/null
> +++ b/unstable/input-method/input-method-unstable-v2.xml
> @@ -0,0 +1,490 @@
> +
> +
> +
> +  
> +Copyright © 2008-2011 Kristian Høgsberg
> +Copyright © 2010-2011 Intel Corporation
> +Copyright © 2012-2013 Collabora, Ltd.
> +Copyright © 2012, 2013 Intel Corporation
> +Copyright © 2015, 2016 Jan Arne Petersen
> +Copyright © 2017, 2018 Red Hat, Inc.
> +Copyright © 2018   Purism SPC
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal i

Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

[Dorota Czaplejewicz]

n.
> +
> +- Window raising/activation: The presented surface may be another 
> previously
> +  existing one, which might require bringing it to focus.

"may be another" - is there a word like "related to" missing?

> +
> +A client that wishes to present another surface (of its own or from 
> another
> +client) will call wp_presentation_manager.create_presenter to create a
> +presentation request. Compositors may use this object to track the 
> source of
> +the request in order to apply its policies when mapping the surface or
> +bringing an existing one to focus.
> +
> +In the presented surface side, the request token will be notified upon
> +through the wp_presentation_manager.acknowledge request. The method to 
> pass
> +the token across clients is considered an implementation detail, and is
> +explicitly not observed here.
> +
> +Upon a successfully acknowledged presentation token, the client will 
> receive
> +a wp_presenter.done event. In the rare cases that launching an 
> application
> +would fail, the compositor may emit a wp_presenter.cancelled event
> +after a reasonable timeout.
> +  
> +
> +  
> +
> +  
> + Creates a new presenter.
> +
> + The surface argument is the toplevel that initiated the presentation
> + request through user input. Compositors may want to place the presented
> + surface relative to the presenter.
> +
> + Compositors that desire to implement focus stealing prevention
> + may use this request to find out the request time.
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> + Acknowledges that the calling client handled the presentation token.
> +
> + Applications will typically receive this through the DESKTOP_STARTUP_ID
> + environment variable as set by its launcher, and should unset the
> + environment variable right after this request, in order to avoid
> + propagating it to child processes.
> +
> + Compositors will ignore unknown presentation tokens.
> +
> + Presentation tokens may be transferred across clients through means not
> + described in this protocol.
> +  
> +  
> +  
> +
> +
> +
> +  
> + Destroy the wp_presentation_manager object. Objects created from this
> + object are unaffected and should be destroyed separately.
> +  
> +
> +  
> +
> +  
> +
> +  The wp_presenter object allows clients to get the necessary context to
> +  request that another surface or client should be presented to the user.
> +
> +
> +
> +  
> + Sets the app ID of the application to be launched, the compositor
> + may use this information to look up other miscellaneous information
> + about it (eg. translatable name, icon, …).
> +
> + Clients do not need to set an app ID for presentation requests
> + meant to map surfaces owned by the same client.
> +
> + As a best practice, it is suggested to select app
> + ID's that match the basename of the application's .desktop file.
> + For example, "org.freedesktop.FooViewer" where the .desktop file is
> + "org.freedesktop.FooViewer.desktop".
> +
> + See the desktop-entry specification [0] for more details on
> + application identifiers and how they relate to .desktop files.
> +
> + [0] http://standards.freedesktop.org/desktop-entry-spec/
> +  
> +
> +
> +
> +  
> + Destroys this zwp_presenter object.
> +  
> +
> +
> +
> +  
> + Notifies of an unique presentation token (eg. UUIDs) to be used for the
> + application about to be launched.
> +
> + In order to guarantee interoperation with the XDG Startup Notification
> + spec, this launch_id is recommended to be transmitted to the launched
> + application through the DESKTOP_STARTUP_ID environment variable. The
> + launch ID may be passed to a running client through other means not
> + observed in this protocol.
> +  
> +  
> +
> +
> +
> +  
> + Notifies that the compositor is no longer watching this launched
> + application. This may indicate failure (eg. launchee crashed) or
> + may simply be the result of the launchee not replying properly
> + (eg. does not implement this protocol).
> +  
> +
> +
> +
> +  
> + Notifies that the launched application successfully called
> + zwp_presentation_manager.acknowledge.
> +  
> +
> +  
> +

It looks okay, with the caveat that startup notification and 
positioning/focusing seem like two separate beasts to me.

Cheers,
Dorota Czaplejewicz


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

[PATCH v7 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Provides the ability to emulate keyboards by applications. Complementary to 
input-method protocol.

The interface is a mirror copy of wl_keyboard, with removed serials, and added 
seat binding.

Signed-off-by: Dorota Czaplejewicz 
---
Hello,

I've updated this patch with feedback from Petter Hutterer. The only changes 
are in the descriptions.

Regards,
Dorota Czaplejewicz

 Makefile.am   |   1 +
 unstable/virtual-keyboard/README  |   2 +
 .../virtual-keyboard-unstable-v1.xml  | 114 ++
 3 files changed, 117 insertions(+)
 create mode 100644 unstable/virtual-keyboard/README
 create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..d62c380 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,6 +20,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \

unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
 \
unstable/primary-selection/primary-selection-unstable-v1.xml
\
diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README
new file mode 100644
index 000..a2c646d
--- /dev/null
+++ b/unstable/virtual-keyboard/README
@@ -0,0 +1,2 @@
+Virtual keyboard protocol
+
diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
new file mode 100644
index 000..9eae804
--- /dev/null
+++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
@@ -0,0 +1,114 @@
+
+
+  
+Copyright © 2008-2011  Kristian Høgsberg
+Copyright © 2010-2013  Intel Corporation
+Copyright © 2012-2013  Collabora, Ltd.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  The virtual keyboard provides an application with requests which emulate
+  the behaviour of a physical keyboard.
+
+  This interface can be used by clients on its own to provide raw input
+  events, or it can accompany the input method protocol.
+
+
+
+  
+Provide a file descriptor to the compositor which can be memory-mapped
+to provide a keyboard mapping description.
+  
+  
+  
+  
+
+
+
+  
+
+
+
+  
+A key was pressed or released.
+
+The time argument is a timestamp with millisecond granularity, with an
+undefined base. All requests regarding a single object must share the
+same clock.
+
+Keymap must be set before issuing this request.
+  
+  
+  
+  
+
+
+
+  
+Notifies the compositor that the modifier and/or group state has
+changed, and it should update state.
+
+Keymap must be set before issuing this request.
+  
+  
+  
+  
+  
+
+
+
+  
+
+  
+
+  
+
+  A virtual keyboard manager allows an application to provide keyboard
+  input events as if they came from a physical keyboard.
+
+  If the compositor enables a keyboard to perform arbitrary actions, it
+  should prevent untrusted clients from using this interface.
+
+
+
+  
+Creates a new virtual keyboard associated to a seat.
+  
+  
+  
+
+
+
+  
+Destroys the virtual keyboard manager.
+
+Existing zwp_virtual_keyboard_v1 objects remain valid.
+  
+ 

[PATCH] text-input: Add input_provided hint

[Dorota Czaplejewicz]

The new hint is meant to indicate that the text input already provides a means 
to enter data, and that using the system input method is optional.

It should be used when the client presents the user with a custom input method, 
like an on-screen keyboard, or perhaps a dropdown list.

The new hint is meant to address the issue when the system input method is an 
on-screen keyboard. Without the hint, the input method would not know that it's 
not needed, unless the client refrained from using the input method protocol at 
all.

With the hint, the input method can still be enabled, while never displaying a 
second on-screen keyboard. This allows for the system input method to still 
provide accessibility services, as well as text completion or prediction.

Based on discussion in https://gitlab.gnome.org/GNOME/gtk/merge_requests/978

Signed-off-by: Dorota Czaplejewicz 
---
Hi,

here's a patch that bumps the text-input interface in order to introduce a new 
enum value. I think the commit message explains the reasoning, so I'm happy to 
hear feedback.

While writing this change, I decided not to go overboard and ignore things like 
the input method communicating whether it did pop up the on-screen keyboard 
after all.

Cheers,
Dorota Czaplejewicz

 unstable/text-input/text-input-unstable-v3.xml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
index 8b710fd..ec60b6f 100644
--- a/unstable/text-input/text-input-unstable-v3.xml
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -47,7 +47,7 @@
 interface version number is reset.
   
 
-  
+  
 
   The zwp_text_input_v3 interface represents text input and input methods
   associated with a seat. It provides enter/leave events to follow the
@@ -205,6 +205,9 @@
   
   
   
+  
 
 
 
-- 
2.20.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v6 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

On Sat, 20 Jul 2019 18:12:10 +
Simon Ser  wrote:

> Anybody has thoughts about this protocol? This should probably go in
> before input-method.
> 
> Dorota, can your reply with a Signed-off-by tag? It seems like it's
> missing from the commit message. Thanks!
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Here you go, sorry for not paying attantion:

Signed-off-by: Dorota Czaplejewicz 


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

Re: [PATCH wayland-protocols] input-method: Add zwp-input-method-v2

[Dorota Czaplejewicz]

Hi Roman,

I've been shown your KWin work last week - thanks for picking it up!

The tested parts of input_method_v2 are the parts which text-input-v3 is using 
[0]. There's an application [1] and a compositor [0] with examples [2,3] that 
you can use for verifying the KWin implementation. I think they are 
well-tested, but that may just mean I haven't seen 80% of the problems.

The untested-in-practice parts are about popups and keyboard grabs.

I hope this can help you.

Cheers,
Dorota Czaplejewicz

[0] https://github.com/swaywm/wlroots/pull/1203
[1] https://source.puri.sm/Librem5/virtboard
[2] https://github.com/swaywm/wlroots/blob/master/examples/input-method.c
[3] https://github.com/swaywm/wlroots/blob/master/examples/text-input.c

On Fri, 9 Nov 2018 18:26:18 +0100
Roman Gilg  wrote:

> Hi,
> 
> what's the current state of this patch?
> 
> I have a KWin patch up for review to implement the text-input v3
> protocol, so I would be interested in pushing forward the input_method
> v2 here.
> 
> If there are already some test applications speaking both ends of the
> pipeline I could try it out in KWin.
> 
> Cheers
> On Thu, Oct 4, 2018 at 10:01 PM Dorota Czaplejewicz
>  wrote:
> >
> > This protocol is based on v1, current text-input-v3, and wl_keyboard 
> > version 6.
> >
> > The pieces passing data relevant to the application on the other side of 
> > the compositor are a mirror copy of text-input-v3 events and requests.
> >
> > Compared to input-method-v1:
> > - assumes that once preedit is displayed, no selection can be active, 
> > removing some selection handling
> > - follow text-input and removes language indicators
> > - explicitly attaches to seats
> > - removes "commit" text which would replace the preedit string 
> > automatically in case it wasn't "confirmed" (whatever it means)
> > - adds double-buffering in the same places as text-input-v3
> > - drops input_method_context and places its functionality directly in 
> > input_method
> > - removes the ability to move the cursor position outside of preedit. It 
> > still allows to delete a larger chunk of text and replace it with a preedit
> > - doesn't allow for sending of keyboard events to the compositor
> > - doesn't define any surfaces except for a special compositor-positioned 
> > popup
> > ---
> > Hi,
> >
> > continuing the RFC, I think this protocol is actually workable now, and I'm 
> > sending this with the PATCH qualifier.
> >
> > The practical verification came in the form of a partial wlroots 
> > implementation [0]. The formal issues (chiefly stemming from copy-pasting 
> > things at night) have been pointed out to me by Simon, and corrected.
> >
> > The major unverified parts are keyboard grabs and popup surfaces, which I 
> > will verify next.
> >
> > Changes compared to the RFC:
> >
> > - fixed so many confusing typos
> > - renamed preedit_text request to set_preedit_text
> > - described what happens when things get destroyed
> > - defined the role of input_popup sorface and forbade it from being deleted
> > - copied wl_keyboard to serve as the keyboard grab interface
> >
> > I hope you can help me find the remaining issues and turn this interface 
> > into reality!
> >
> > Cheers,
> > Dorota Czaplejewicz
> >
> >  Makefile.am|   1 +
> >  unstable/input-method/input-method-unstable-v2.xml | 490 
> > +
> >  2 files changed, 491 insertions(+)
> >  create mode 100644 unstable/input-method/input-method-unstable-v2.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 6394e26..f3b9f80 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -7,6 +7,7 @@ unstable_protocols =
> > \
> > unstable/text-input/text-input-unstable-v1.xml  
> > \
> > unstable/text-input/text-input-unstable-v3.xml  
> > \
> > unstable/input-method/input-method-unstable-v1.xml  
> > \
> > +   unstable/input-method/input-method-unstable-v2.xml  
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > \
> > unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> > \
> > diff --git a/unstable/input-method/input-method-unstable-v2.xml 
> > b/unstable/input-

[PATCH wayland-protocols] input-method: Add zwp-input-method-v2

[Dorota Czaplejewicz]

This protocol is based on v1, current text-input-v3, and wl_keyboard version 6.

The pieces passing data relevant to the application on the other side of the 
compositor are a mirror copy of text-input-v3 events and requests.

Compared to input-method-v1:
- assumes that once preedit is displayed, no selection can be active, removing 
some selection handling
- follow text-input and removes language indicators
- explicitly attaches to seats
- removes "commit" text which would replace the preedit string automatically in 
case it wasn't "confirmed" (whatever it means)
- adds double-buffering in the same places as text-input-v3
- drops input_method_context and places its functionality directly in 
input_method
- removes the ability to move the cursor position outside of preedit. It still 
allows to delete a larger chunk of text and replace it with a preedit
- doesn't allow for sending of keyboard events to the compositor
- doesn't define any surfaces except for a special compositor-positioned popup
---
Hi,

continuing the RFC, I think this protocol is actually workable now, and I'm 
sending this with the PATCH qualifier.

The practical verification came in the form of a partial wlroots implementation 
[0]. The formal issues (chiefly stemming from copy-pasting things at night) 
have been pointed out to me by Simon, and corrected.

The major unverified parts are keyboard grabs and popup surfaces, which I will 
verify next.

Changes compared to the RFC:

- fixed so many confusing typos
- renamed preedit_text request to set_preedit_text
- described what happens when things get destroyed
- defined the role of input_popup sorface and forbade it from being deleted
- copied wl_keyboard to serve as the keyboard grab interface

I hope you can help me find the remaining issues and turn this interface into 
reality!

Cheers,
Dorota Czaplejewicz

 Makefile.am|   1 +
 unstable/input-method/input-method-unstable-v2.xml | 490 +
 2 files changed, 491 insertions(+)
 create mode 100644 unstable/input-method/input-method-unstable-v2.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..f3b9f80 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,6 +7,7 @@ unstable_protocols =
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
+   unstable/input-method/input-method-unstable-v2.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
diff --git a/unstable/input-method/input-method-unstable-v2.xml 
b/unstable/input-method/input-method-unstable-v2.xml
new file mode 100644
index 000..62be9d9
--- /dev/null
+++ b/unstable/input-method/input-method-unstable-v2.xml
@@ -0,0 +1,490 @@
+
+
+
+  
+Copyright © 2008-2011 Kristian Høgsberg
+Copyright © 2010-2011 Intel Corporation
+Copyright © 2012-2013 Collabora, Ltd.
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+This protocol allows applications to act as input methods for compositors.
+
+An input method context is used to manage the state of the input method.
+
+Text strings are UTF-8 encoded, their indices and lengths are in bytes.
+
+This document adheres to the RFC 2119 when using words like "must",
+"shou

Re: [RFC wayland-protocols] input-method: Add zwp-input-method-v2

[Dorota Czaplejewicz]

Thank you Simon for reading the proposal so carefully!

My replies are inline.

On Fri, 07 Sep 2018 11:54:36 +
Simon Ser  wrote:

> On 6 August 2018 3:00 PM, Dorota Czaplejewicz  
> wrote:
> > This protocol is based on v1, and current text-input-v3.
> >
> > The pieces passing data relevant to the application on the other side of the
> > compositor are a mirror copy of text-input-v3 events and requests.
> >
> > Compared to input-method-v1:
> > - assumes that once preedit is displayed, no selection can be active, 
> > removing
> >   some selection handling
> > - follow text-input and removes language indicators
> > - explicitly attaches to seats
> > - removes "commit" text which would replace the preedit string automatically
> >   in case it wasn't "confirmed" (whatever it means)
> > - adds double-buffering in the same places as text-input-v3
> > - drops input_method_context and places its functionality directly in
> >   input_method
> > - removes the ability to move the cursor position outside of preedit. It 
> > still
> >   allows to delete a larger chunk of text and replace it with a preedit
> > - doesn't allow for sending of keyboard events to the compositor
> > - Doesn't define any surfaces except for a special compositor-positioned 
> > popup
> > ---
> > Hi,
> >
> > the third item on the path to well-supported virtual keyboard experience 
> > under
> > Wayland comes from Purism. This one allows the compositor to delegate text
> > input and composition duties to an application instead of handling it 
> > itself.
> > Input-method-delegating compositor would typically become only a broker
> > between the input method client and other applications.
> >
> > I took the existing input-method protocol, and after dissecting it with the
> > help of wlroots developers, I came up with an improved version, which is
> > attached for your (re)viewing pleasure.
> >
> > A large part of this protocol was taken from recent text-input-v3, and some
> > description text was improved. Still, the protocol has a couple of rough
> > edges, which is why it's titled RFC and not a patch.
> >
> > The issues I have had most trouble with are related to the handling of
> > keyboard grabs. These are meant to allow traditional, keyboard-based input
> > methods, to take over keyboard input in order to compose text in a different
> > way.
> >
> > First, keyboard grabs are defined as unreliable. I'm not sure whether this 
> > is
> > the right choice, but given that making them more reliable seems rather
> > complicated, this is the default one.
> >
> > In addition, handling the keyboard events themselves is troublesome, because
> > an input method, even if it has a surface, is not meant to have keyboard 
> > focus
> > while it's in operation. Returning wl_keyboard as new_id seems not to be
> > possible due to versioning. Should the request make an existing wl_keyboard
> > instance change behaviour? Or perhaps there should be a new
> > zwp_input_method_keyboard mimicking the wl_keyboard interface?
> >
> > I'm interested in your opinions.
> >
> > Thank you,
> > Dorota Czaplejewicz  
> 
> Thansk for your RFC!
> 
> >  Makefile.am|   1 +
> >  unstable/input-method/input-method-unstable-v2.xml | 403 
> > +
> >  2 files changed, 404 insertions(+)
> >  create mode 100644 unstable/input-method/input-method-unstable-v2.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 6394e26..f3b9f80 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -7,6 +7,7 @@ unstable_protocols =
> > \
> > unstable/text-input/text-input-unstable-v1.xml  
> > \
> > unstable/text-input/text-input-unstable-v3.xml  
> > \
> > unstable/input-method/input-method-unstable-v1.xml  
> > \
> > +   unstable/input-method/input-method-unstable-v2.xml  
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > \
> > unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> > \
> > diff --git a/unstable/input-method/input-method-unstable-v2.xml 
> > b/unstable/input-method/input-method-unstable-v2.xml
> > new file mode 100644
>

[RFC wayland-protocols] input-method: Add zwp-input-method-v2

[Dorota Czaplejewicz]

This protocol is based on v1, and current text-input-v3.

The pieces passing data relevant to the application on the other side of the 
compositor are a mirror copy of text-input-v3 events and requests.

Compared to input-method-v1:
- assumes that once preedit is displayed, no selection can be active, removing 
some selection handling
- follow text-input and removes language indicators
- explicitly attaches to seats
- removes "commit" text which would replace the preedit string automatically in 
case it wasn't "confirmed" (whatever it means)
- adds double-buffering in the same places as text-input-v3
- drops input_method_context and places its functionality directly in 
input_method
- removes the ability to move the cursor position outside of preedit. It still 
allows to delete a larger chunk of text and replace it with a preedit
- doesn't allow for sending of keyboard events to the compositor
- Doesn't define any surfaces except for a special compositor-positioned popup
---
Hi,

the third item on the path to well-supported virtual keyboard experience under 
Wayland comes from Purism. This one allows the compositor to delegate text 
input and composition duties to an application instead of handling it itself. 
Input-method-delegating compositor would typically become only a broker between 
the input method client and other applications.

I took the existing input-method protocol, and after dissecting it with the 
help of wlroots developers, I came up with an improved version, which is 
attached for your (re)viewing pleasure.

A large part of this protocol was taken from recent text-input-v3, and some 
description text was improved. Still, the protocol has a couple of rough edges, 
which is why it's titled RFC and not a patch.

The issues I have had most trouble with are related to the handling of keyboard 
grabs. These are meant to allow traditional, keyboard-based input methods, to 
take over keyboard input in order to compose text in a different way.

First, keyboard grabs are defined as unreliable. I'm not sure whether this is 
the right choice, but given that making them more reliable seems rather 
complicated, this is the default one.

In addition, handling the keyboard events themselves is troublesome, because an 
input method, even if it has a surface, is not meant to have keyboard focus 
while it's in operation. Returning wl_keyboard as new_id seems not to be 
possible due to versioning. Should the request make an existing wl_keyboard 
instance change behaviour? Or perhaps there should be a new 
zwp_input_method_keyboard mimicking the wl_keyboard interface?

I'm interested in your opinions.

Thank you,
Dorota Czaplejewicz 

 Makefile.am|   1 +
 unstable/input-method/input-method-unstable-v2.xml | 403 +
 2 files changed, 404 insertions(+)
 create mode 100644 unstable/input-method/input-method-unstable-v2.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..f3b9f80 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,6 +7,7 @@ unstable_protocols =
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
+   unstable/input-method/input-method-unstable-v2.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
diff --git a/unstable/input-method/input-method-unstable-v2.xml 
b/unstable/input-method/input-method-unstable-v2.xml
new file mode 100644
index 000..8cf8e29
--- /dev/null
+++ b/unstable/input-method/input-method-unstable-v2.xml
@@ -0,0 +1,403 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILIT

[PATCH v6 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Provides the ability to emulate keyboards by applications. Complementary to 
input-method protocol.

The interface is a mirror copy of wl_keyboard, with removed serials, and added 
seat binding.
---
Hello,

this is the change I wanted to send previously (sorry).

Regards,
Dorota Czaplejewicz

 Makefile.am|   1 +
 unstable/virtual-keyboard/README   |   2 +
 .../virtual-keyboard-unstable-v1.xml   | 114 +
 3 files changed, 117 insertions(+)
 create mode 100644 unstable/virtual-keyboard/README
 create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..d67aa1b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,6 +20,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
$(NULL)
 
diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README
new file mode 100644
index 000..a2c646d
--- /dev/null
+++ b/unstable/virtual-keyboard/README
@@ -0,0 +1,2 @@
+Virtual keyboard protocol
+
diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
new file mode 100644
index 000..9eae804
--- /dev/null
+++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
@@ -0,0 +1,114 @@
+
+
+  
+Copyright © 2008-2011  Kristian Høgsberg
+Copyright © 2010-2013  Intel Corporation
+Copyright © 2012-2013  Collabora, Ltd.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  The virtual keyboard provides an application with requests which emulate
+  the behaviour of a physical keyboard.
+
+  This interface can be used by clients on its own to provide raw input
+  events, or it can accompany the input method protocol.
+
+
+
+  
+Provide a file descriptor to the compositor which can be memory-mapped
+to provide a keyboard mapping description.
+  
+  
+  
+  
+
+
+
+  
+
+
+
+  
+A key was pressed or released.
+
+The time argument is a timestamp with millisecond granularity, with an
+undefined base. All requests regarding a single object must share the
+same clock.
+
+Keymap must be set before issuing this request.
+  
+  
+  
+  
+
+
+
+  
+Notifies the compositor that the modifier and/or group state has
+changed, and it should update state.
+
+Keymap must be set before issuing this request.
+  
+  
+  
+  
+  
+
+
+
+  
+
+  
+
+  
+
+  A virtual keyboard manager allows an application to provide keyboard
+  input events as if they came from a physical keyboard.
+
+  If the compositor enables a keyboard to perform arbitrary actions, it
+  should prevent untrusted clients from using this interface.
+
+
+
+  
+Creates a new virtual keyboard associated to a seat.
+  
+  
+  
+
+
+
+  
+Destroys the virtual keyboard manager.
+
+Existing zwp_virtual_keyboard_v1 objects remain valid.
+  
+
+  
+
-- 
2.14.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v5 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Provides the ability to emulate keyboards by applications. Complementary to 
input-method protocol.

The interface is a mirror copy of wl_keyboard, with removed serials, and added 
seat binding.
---
Hello again,

I'm sending this patch to bring virtual-keyboard back in line with the v3 of 
the patch. This version doesn't contain any functional changes, but it's better 
formatted, and properties are referenced in a more idiomatic way.

Having only minimal fixes compared to v3 (which is now also part of sway [0]), 
v5 looks pretty complete to me.

Regards,
Dorota Czaplejewicz

[0] https://github.com/swaywm/sway/pull/2376

 Makefile.am|   1 +
 unstable/virtual-keyboard/README   |   2 +
 .../virtual-keyboard-unstable-v1.xml   | 154 +
 3 files changed, 157 insertions(+)
 create mode 100644 unstable/virtual-keyboard/README
 create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..d67aa1b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,6 +20,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
$(NULL)
 
diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README
new file mode 100644
index 000..a2c646d
--- /dev/null
+++ b/unstable/virtual-keyboard/README
@@ -0,0 +1,2 @@
+Virtual keyboard protocol
+
diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
new file mode 100644
index 000..173f3bc
--- /dev/null
+++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
@@ -0,0 +1,154 @@
+
+
+  
+Copyright © 2008-2011  Kristian Høgsberg
+Copyright © 2010-2013  Intel Corporation
+Copyright © 2012-2013  Collabora, Ltd.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  The virtual keyboard provides an application with requests which emulate
+  the behaviour of a physical keyboard.
+
+  This interface can be used by clients on its own to provide raw input
+  events, or it can accompany the input method protocol.
+
+
+
+  
+Provide a file descriptor to the compositor which can be memory-mapped
+to provide a keyboard mapping description.
+  
+  
+  
+  
+
+
+
+  
+
+
+
+  
+A key was pressed or released.
+The time argument is a timestamp with millisecond granularity, with an
+undefined base. All requests regarding a single object must share the
+same clock.
+
+Keymap must be set before issuing this request.
+  
+  
+  
+  
+
+
+
+  
+Notifies the compositor that the modifier and/or group state has
+changed, and it should update state.
+
+Keymap must be set before issuing this request.
+  
+  
+  
+  
+  
+
+
+
+  
+
+  
+
+  
+
+  A virtual keyboard manager allows an application to provide keyboard
+  input events as if they came from a physical keyboard.
+
+  If the compositor enables a keyboard to perform arbitrary actions, it
+  should prevent untrusted clients from using this interface.
+
+
+
+  
+Asks to create a new virtual keyboard associated to a seat.
+
+If the client is found unauthorized to creat

Re: [ANNOUNCE] wayland-protocols 1.16

[Dorota Czaplejewicz]

On Mon, 30 Jul 2018 18:42:01 +0200
Jonas Ådahl  wrote:

> wayland-protocols 1.16 is now available.
> 
> This version includes a new version of the unstable text-input protocol. The
> new version is not compatible with the old version. Please check the commit
> adding the new protocols for more details about the introduced changes.
> 
> The stable xdg-shell protocol got some clarifications about expectations
> regarding state requested by the client and what is configured by the
> compositor.
> 
> The xdg-output protocol got some clarifications about how transforms are
> handled.
> 
> The test suite was improved to catch issues detected by wayland-scanner.
> 
> 
> Here is the shortlog:
> 
> Carlos Garnacho (1):
>   text-input: Add v3 of the text-input protocol
> 
> Jonas Ådahl (3):
>   tests: Use public-code and private-code instead of code
>   tests: Make wayland-scanner strict
>   configure.ac: Bump version to 1.16
> 
> Markus Ongyerth (2):
>   xdg-shell: move maximized state definition together
>   xdg-shell: Make sure wording reflects expectations
> 
> Simon Ser (1):
>   xdg-output: add a transform example for the logical size
> 
> 
> git tag: 1.16
> 
> http://wayland.freedesktop.org/releases/wayland-protocols-1.16.tar.xz
> MD5:  e0b523ff162e30bab46be1d65d527683  wayland-protocols-1.16.tar.xz
> SHA1: b8d8ddce816b928364ed2c8f0e4a54d7dd398c15  wayland-protocols-1.16.tar.xz
> SHA256: 6b1485951fdcd36a960c870c46f28b03a3e5121fb46246916333ed07f78c98c5  
> wayland-protocols-1.16.tar.xz
> PGP:  
> http://wayland.freedesktop.org/releases/wayland-protocols-1.16.tar.xz.sig

Thanks everyone for reviewing!

After text-input, I intend to submit input-method-v2, and I encourage everyone 
to review that one as well.

Cheers,
Dorota Czapejewicz


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

[PATCH v11 wayland_protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is an evolution of v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---
Hi,

this version adds a short protocol description and moves some text from 
text_input description there (most of it is still directly relevant to 
text_input only).

It also fixes the done argument by placing it outside the description.

--Dorota

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 441 +
 2 files changed, 442 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..95af0e2
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,441 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+This protocol allows compositors to act as input methods and to send text
+to applications. A text input object is used to manage state of what are
+typically text entry fields in the application.
+  
+This document adheres to the RFC 2119 when using words like "must",
+"should", "may", etc.
+
+Warning! The protocol described in this file is experimental and
+backward incompatible changes may be made. Backward compatible changes
+may be added together with the corresponding interface version bump.
+Backward incompatible changes are done by bumping the version number in
+the protocol and interface names and resetting the interface version.
+Once the protocol is to be declared stable, the 'z' prefix and the
+version number in the protocol and interface names are removed and the
+interface version number is reset.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the

[PATCH v10 wayland_protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is an evolution of v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---
Hi,

this patch applies most recent advice from Jonas. The changes are in commit and 
done messages and spelled out in my previous email.

Cheers,
Dorota 

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 435 +
 2 files changed, 436 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..acf5674
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,435 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the preedit_string and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  must not point to middle bytes inside a code point: they must either
+  point to the first byte of a code point or to the end of the buffer.
+  Lengths must be measured between two valid indices.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must commit zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the keyboard focus moves across
+  editable and non-editable elements of the UI. Those two requests are not
+  expected to be paired with each other, the compositor must be able to
+  handle consecutive series of the same request.
+
+  State is sent by the state requests (set_surrounding_text,
+  set_content_type and set_cursor_rectangle) and a commit request. After an
+  enter event or disable r

Re: [PATCH v9 wayland_protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Mon, 30 Jul 2018 15:20:05 +0200
Jonas Ådahl  wrote:

> On Mon, Jul 30, 2018 at 02:44:47PM +0200, Dorota Czaplejewicz wrote:
> > From: Carlos Garnacho 
> > 
> > This new protocol description is an evolution of v2.
> > 
> > - All pre-edit text styling is gone.
> > - Pre-edit cursor can span characters.
> > - No events regarding input panel (OSK) state nor covered rectangle.
> >   Compositors are still free to handle situations where the keyboard
> >   focus rectangle is covered by the input panel.
> > - No set_preferred_language request for clients.
> > - There is no event to send keysyms. Compositors can use wl_keyboard
> >   interface instead.
> > - All state is double-buffered, with specified defaults.
> > - The compositor can be notified about external changes to the state.
> > - The client can detect outdated requests.
> > 
> > Signed-off-by: Dorota Czaplejewicz 
> > Signed-off-by: Carlos Garnacho 
> > ---
> > Hi,
> > 
> > this patch includes feedback received from Jonas.
> > 
> > Changes over v8:
> > 
> > - removed a mention of an input method protocol in the introduction
> > - synchronization happens not via arbitrary serials but via counting of 
> > commit requests
> > - disable request needs to be committed
> > - improved clarity of commit request
> > 
> > Thanks for reviewing!  
> 
> I think we're almost there now.. I just a few nits below:
> 
> > 
> > --Dorota
> > 
> >  Makefile.am|   1 +
> >  unstable/text-input/text-input-unstable-v3.xml | 434 
> > +
> >  2 files changed, 435 insertions(+)
> >  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..86d7ca9 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -3,6 +3,7 @@ unstable_protocols =
> > \
> > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
> > \
> > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
> > \
> > unstable/text-input/text-input-unstable-v1.xml  
> > \
> > +   unstable/text-input/text-input-unstable-v3.xml  
> > \
> > unstable/input-method/input-method-unstable-v1.xml  
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > \
> > diff --git a/unstable/text-input/text-input-unstable-v3.xml 
> > b/unstable/text-input/text-input-unstable-v3.xml
> > new file mode 100644
> > index 000..f2163a5
> > --- /dev/null
> > +++ b/unstable/text-input/text-input-unstable-v3.xml
> > @@ -0,0 +1,434 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2012, 2013 Intel Corporation
> > +Copyright © 2015, 2016 Jan Arne Petersen
> > +Copyright © 2017, 2018 Red Hat, Inc.
> > +Copyright © 2018   Purism SPC
> > +
> > +Permission to use, copy, modify, distribute, and sell this
> > +software and its documentation for any purpose is hereby granted
> > +without fee, provided that the above copyright notice appear in
> > +all copies and that both that copyright notice and this permission
> > +notice appear in supporting documentation, and that the name of
> > +the copyright holders not be used in advertising or publicity
> > +pertaining to distribution of the software without specific,
> > +written prior permission.  The copyright holders make no
> > +representations about the suitability of this software for any
> > +purpose.  It is provided "as is" without express or implied
> > +warranty.
> > +
> > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> > +THIS SOFTWARE.
> > +  
> > +
> > +  
> > +
> > +  The zwp_text_input_v3 interface represents text input an

[PATCH v9 wayland_protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is an evolution of v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---
Hi,

this patch includes feedback received from Jonas.

Changes over v8:

- removed a mention of an input method protocol in the introduction
- synchronization happens not via arbitrary serials but via counting of commit 
requests
- disable request needs to be committed
- improved clarity of commit request

Thanks for reviewing!

--Dorota

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 434 +
 2 files changed, 435 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..f2163a5
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,434 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the preedit_string and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  must not point to middle bytes inside a code point: they must either
+  point to the first byte of a code point or to the end of the buffer.
+  Lengths must be measured between two valid indices.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must commit zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the keyboard focus moves across
+  editable and non-editable elements of the UI. Those two requests are not
+  expected to be paired with each other, the compositor must be able to
+  handle consecutive series of the sa

Re: [PATCH v8 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Mon, 30 Jul 2018 13:09:06 +0200
Jonas Ådahl  wrote:

> On Mon, Jul 30, 2018 at 12:57:52PM +0200, Dorota Czaplejewicz wrote:
> > On Mon, 30 Jul 2018 12:36:45 +0200
> > Jonas Ådahl  wrote:
> >   
> > > On Sat, Jul 28, 2018 at 08:17:56PM +0200, Dorota Czaplejewicz wrote:  
> > > > From: Carlos Garnacho 
> > > > 
> > > > This new protocol description is an evolution of v2.
> > > > 
> > > > - All pre-edit text styling is gone.
> > > > - Pre-edit cursor can span characters.
> > > > - No events regarding input panel (OSK) state nor covered rectangle.
> > > >   Compositors are still free to handle situations where the keyboard
> > > >   focus rectangle is covered by the input panel.
> > > > - No set_preferred_language request for clients.
> > > > - There is no event to send keysyms. Compositors can use wl_keyboard
> > > >   interface instead.
> > > > - All state is double-buffered, with specified defaults.
> > > > - The compositor can be notified about external changes to the state.
> > > > - The client can detect outdated requests.
> > > > 
> > > > Signed-off-by: Dorota Czaplejewicz 
> > > > Signed-off-by: Carlos Garnacho 
> > > > ---
> > > > Hello all,
> > > > 
> > > > this new change stems from real experiences developing an 
> > > > implementation of text-input. Under Carlos' guidance, I've been 
> > > > developing support in GTK3, as well as wlroots [0]. There were lessons 
> > > > to be learned, and they are incorporated into this new patch revision.
> > > > 
> > > > The one significant change consists of adding a serial number to each 
> > > > state sent by the client. The input method (e.g. the compositor) will 
> > > > then update its beliefs about the text field state, and send new 
> > > > requests, along with the serial number. This allows the client to 
> > > > detect requests based on outdated states and handle them in a special 
> > > > way, i.e. ignore requests for permanent changes.
> > > > 
> > > > At the same time, the enable request becomes effective only after a 
> > > > commit, to allow the client to send a state bundle together with it.
> > > > 
> > > > The second important change regards passing set_surrounding_text 
> > > > metadata in the set_text_change_cause request. It's necessary for the 
> > > > input method to understand when the user stopped using it to back off. 
> > > > The change_cause enumeration could be extended in the future with 
> > > > causes such as "navigation", "typing", or "redaction" to achieve better 
> > > > granularity than a catchall "other".
> > > > 
> > > > Apart from these changes, some descriptions have been clarified, and 
> > > > circumstances were under which set_surrounding_text should be sent were 
> > > > spelled out.
> > > > 
> > > > I hope that you enjoy the read!
> > > 
> > > I've had a read through, and looks pretty solid to me. A few minor
> > > comments are inlined below.  
> > 
> > Hi, thanks for the review!
> > 
> > Replies inline.  
> > >   
> 
> 
> ... snip ...
> 
> > > > +
> > > > +
> > > > +  
> > > > +Atomically applies state changes recently sent to the 
> > > > compositor.
> > > > +
> > > > +The commit request establishes and updates the state of the 
> > > > client, and
> > > > +must be issued immediately after before the compositor
> > > > +
> > > > +Text input state (enabled status, content purpose, content 
> > > > hint,
> > > > +surrounding text and change cause, cursor rectangle) is 
> > > > conceptually
> > > > +double-buffered within the context of a text input, i.e. 
> > > > between an
> > > > +enable request and the following enable or disable request.
> > > > +
> > > > +Protocol requests modify the pending state, as opposed to the 
> > > > current
> > > > +state in use by the input method. A commit request atomically 
> > > > applies
> > > > +all pending state, replacing the current state. After commit, 
> > > > the new
> > > > + 

Re: [PATCH v8 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Mon, 30 Jul 2018 12:36:45 +0200
Jonas Ådahl  wrote:

> On Sat, Jul 28, 2018 at 08:17:56PM +0200, Dorota Czaplejewicz wrote:
> > From: Carlos Garnacho 
> > 
> > This new protocol description is an evolution of v2.
> > 
> > - All pre-edit text styling is gone.
> > - Pre-edit cursor can span characters.
> > - No events regarding input panel (OSK) state nor covered rectangle.
> >   Compositors are still free to handle situations where the keyboard
> >   focus rectangle is covered by the input panel.
> > - No set_preferred_language request for clients.
> > - There is no event to send keysyms. Compositors can use wl_keyboard
> >   interface instead.
> > - All state is double-buffered, with specified defaults.
> > - The compositor can be notified about external changes to the state.
> > - The client can detect outdated requests.
> > 
> > Signed-off-by: Dorota Czaplejewicz 
> > Signed-off-by: Carlos Garnacho 
> > ---
> > Hello all,
> > 
> > this new change stems from real experiences developing an implementation of 
> > text-input. Under Carlos' guidance, I've been developing support in GTK3, 
> > as well as wlroots [0]. There were lessons to be learned, and they are 
> > incorporated into this new patch revision.
> > 
> > The one significant change consists of adding a serial number to each state 
> > sent by the client. The input method (e.g. the compositor) will then update 
> > its beliefs about the text field state, and send new requests, along with 
> > the serial number. This allows the client to detect requests based on 
> > outdated states and handle them in a special way, i.e. ignore requests for 
> > permanent changes.
> > 
> > At the same time, the enable request becomes effective only after a commit, 
> > to allow the client to send a state bundle together with it.
> > 
> > The second important change regards passing set_surrounding_text metadata 
> > in the set_text_change_cause request. It's necessary for the input method 
> > to understand when the user stopped using it to back off. The change_cause 
> > enumeration could be extended in the future with causes such as 
> > "navigation", "typing", or "redaction" to achieve better granularity than a 
> > catchall "other".
> > 
> > Apart from these changes, some descriptions have been clarified, and 
> > circumstances were under which set_surrounding_text should be sent were 
> > spelled out.
> > 
> > I hope that you enjoy the read!  
> 
> I've had a read through, and looks pretty solid to me. A few minor
> comments are inlined below.

Hi, thanks for the review!

Replies inline.
> 
> > 
> > Regards,
> > Dorota Czaplejewicz
> > 
> > [0] https://gitlab.gnome.org/GNOME/gtk/merge_requests/272
> > 
> >  Makefile.am|   1 +
> >  unstable/text-input/text-input-unstable-v3.xml | 441 
> > +
> >  2 files changed, 442 insertions(+)
> >  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..86d7ca9 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -3,6 +3,7 @@ unstable_protocols =
> > \
> > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
> > \
> > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
> > \
> > unstable/text-input/text-input-unstable-v1.xml  
> > \
> > +   unstable/text-input/text-input-unstable-v3.xml  
> > \
> > unstable/input-method/input-method-unstable-v1.xml  
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > \
> > diff --git a/unstable/text-input/text-input-unstable-v3.xml 
> > b/unstable/text-input/text-input-unstable-v3.xml
> > new file mode 100644
> > index 000..2e8b72f
> > --- /dev/null
> > +++ b/unstable/text-input/text-input-unstable-v3.xml
> > @@ -0,0 +1,441 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2012, 2013 Intel Corporation
> > +Copyright © 2015, 2016 Jan Arne Petersen
> > +Copyright © 2017, 2018 Red Hat, Inc.
> > +Copyright © 2018   Purism SPC
> > +
> > +Permission to use, copy, modify, distribute, and sell 

Re: [PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

On Tue, 24 Jul 2018 15:10:29 +0200
Dorota Czaplejewicz  wrote:

> On Thu, 12 Jul 2018 18:15:32 -0400
> Simon Ser  wrote:
> 
> > Hi,
> > 
> > Sorry for the delay.
> > 
> > I'm not sure I like this new design.
> > 
> > Finally, I'm not even sure this security mechanism belongs here. I think 
> > adding
> > this mechanism to potentially all privileged protocols will result in 
> > duplicated
> > code and "pollutes" protocols. Here are some other solutions:
> > 

--- snip ---

> > * Allow other clients to use this interface too, and use another protocol to
> >   manage authorizations. Basically the idea would be not to expose this
> >   interface, and require the client to request access to this privileged
> >   interface through an authorizer protocol. Someone already mentioned it, 
> > this
> >   is Orbital's approach [2]. This allows the compositor to spawn a dialog 
> > asking
> >   to the user "do you want to allow  to create a virtual keyboard?".
> > 
> > What do you think?
> >   
> I'm in favor of option 3, which will be useful for other protocols as well, 
> which are not necessarily in position to be kept in a permanent privileged 
> process, e.g. screen recording.
> 
> It would also make me happier as a protocol author, because the protocol 
> becomes more compact and easier to maintain without explicit managing.
> 

Thinking a bit more about the topic, this patch with the authentication 
features removed would end up exactly the same as patch v3. Patch v3 is already 
implemented in wlroots too.

Hereby I withdraw this update. Please refer to 
20180622152045.10563-1-dorota.czaplejew...@puri.sm which can be read here: 
https://lists.freedesktop.org/archives/wayland-devel/2018-June/038629.html

Regards,
Dorota Czaplejewicz


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

[PATCH v8 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is an evolution of v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---
Hello all,

this new change stems from real experiences developing an implementation of 
text-input. Under Carlos' guidance, I've been developing support in GTK3, as 
well as wlroots [0]. There were lessons to be learned, and they are 
incorporated into this new patch revision.

The one significant change consists of adding a serial number to each state 
sent by the client. The input method (e.g. the compositor) will then update its 
beliefs about the text field state, and send new requests, along with the 
serial number. This allows the client to detect requests based on outdated 
states and handle them in a special way, i.e. ignore requests for permanent 
changes.

At the same time, the enable request becomes effective only after a commit, to 
allow the client to send a state bundle together with it.

The second important change regards passing set_surrounding_text metadata in 
the set_text_change_cause request. It's necessary for the input method to 
understand when the user stopped using it to back off. The change_cause 
enumeration could be extended in the future with causes such as "navigation", 
"typing", or "redaction" to achieve better granularity than a catchall "other".

Apart from these changes, some descriptions have been clarified, and 
circumstances were under which set_surrounding_text should be sent were spelled 
out.

I hope that you enjoy the read!

Regards,
Dorota Czaplejewicz

[0] https://gitlab.gnome.org/GNOME/gtk/merge_requests/272

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 441 +
 2 files changed, 442 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..2e8b72f
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,441 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+   

Re: [PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

mage where the compositor doesn't want the keyboard to exist any more, e.g. 
because the user revoked permission, or because it was turned off by the user.

If it was only about permissions, it would seem like a good idea for the 
authorization protocol to handle disabling the virtual keyboard. Unfortunately, 
it seems to be only possible to render the global inert. That gets complicated 
because the global is a factory and its children need to be implicitly inert as 
well.

There are other protocols which implement an event that notifies the client 
that an object is inert, e.g. zwp_linux_buffer_params_v1.{created,failed} or 
zwp_confined_pointer_v1.unconfined. Some objects that sound like they should be 
force-destroyable don't have this, e.g. zxdg_toplevel_v6. It's not clear to me 
what the separation is and where virtual-keyboard falls.

I won't be adding such an event now, but I'm happy to get educated and then do 
the right thing.

> Everything else looks good to me. Thanks for your work!

Thank you for reviewing!

--Dorota


> 
> Simon
> 
> [1]: 
> http://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html
> [2]: 
> https://github.com/giucam/orbital/blob/master/protocol/orbital-authorizer.xml
> 


> > Cheers,
> > Dorota Czaplejewicz
> >
> >  Makefile.am|   1 +
> >  unstable/virtual-keyboard/README   |   2 +
> >  .../virtual-keyboard-unstable-v1.xml   | 154 
> > +
> >  3 files changed, 157 insertions(+)
> >  create mode 100644 unstable/virtual-keyboard/README
> >  create mode 100644 
> > unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 1aa13cf..17cedc1 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -19,6 +19,7 @@ unstable_protocols =  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > +   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
> > $(NULL)
> >
> >  stable_protocols = 
> > \
> > diff --git a/unstable/virtual-keyboard/README 
> > b/unstable/virtual-keyboard/README
> > new file mode 100644
> > index 000..a2c646d
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/README
> > @@ -0,0 +1,2 @@
> > +Virtual keyboard protocol
> > +
> > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
> > b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > new file mode 100644
> > index 000..173f3bc
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > @@ -0,0 +1,154 @@
> > +
> > +
> > +  
> > +Copyright © 2008-2011  Kristian Høgsberg
> > +Copyright © 2010-2013  Intel Corporation
> > +Copyright © 2012-2013  Collabora, Ltd.
> > +Copyright © 2018   Purism SPC
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice (including the 
> > next
> > +paragraph) shall be included in all copies or substantial portions of 
> > the
> > +Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > EXPRESS OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > SHALL
> > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > +DEALINGS IN THE SOFTWARE.
> > +  
> > +
> > +  
> > +
&g

[PATCH v7 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is a simplification over v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified state.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---
This change introduces whitespace and typo fixes.

Cheers,
Dorota


 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 374 +
 2 files changed, 375 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..64824ea
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,374 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the preedit_string and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  must not point to middle bytes inside a code point: they must either
+  point to the first byte of a code point or to the end of the buffer.
+  Lengths must be measured between two valid indices.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must perform zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the keyboard focus moves across
+  editable and non-editable elements of the UI. Those two requests are not
+  expected to be paired with each other, the compositor must be able to
+  handle consecutive series of the same request.
+
+  State is sent by the state requests (set_surrounding_text,
+  set_content_type and set_cursor_rectangle) and a commit request. After an
+  enter event or disable request all state information is invalidated and
+  needs to be resent by the client.
+
+  This protocol defines requests and events necessary for regular clients
+  to communicate wit

[PATCH v6 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is a simplification over v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified state.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---
Hi again,

I'm removing the line about Unicode from the commit message.

Thanks,
Dorota Czaplejewicz

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 374 +
 2 files changed, 375 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..80058a5
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,374 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the preedit_string and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  must not point to middle bytes inside a code point: they must either
+  point to the first byte of a code point or to the end of the buffer.
+  Lengths must be measured between two valid indices.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must perform zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the keyboard focus moves across
+  editable and non-editable elements of the UI. Those two requests are not
+  expected to be paired with each other, the compositor must be able to
+  handle consecutive series of the same request.
+
+  State is sent by the state requests (set_surrounding_text,
+  set_content_type and set_cursor_rectangle) and a commit request.
+  After an enter event or disable request all state information is
+  invalidated and needs to be resent by the client.
+
+  This protocol defines requests and events necessary for regul

[PATCH v5 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho 

This new protocol description is a simplification over v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified state.
- Use Unicode codepoints to measure strings.

Signed-off-by: Dorota Czaplejewicz 
Signed-off-by: Carlos Garnacho 
---

Hi all,

thanks for the feedback on the previous patch. The most controversial part was 
my switch from measuring bytes to code points when passing around Unicode 
strings.

This v5 of the patch reverses that and we're in bytes land again. I hope that 
this version passes scrutiny and gets accepted to the Wayland family.

Cheers,
Dorota

PS. Right now I'm working on getting wlroots and GTK to use this protocol.

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 374 +
 2 files changed, 375 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..80058a5
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,374 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018   Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the preedit_string and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  must not point to middle bytes inside a code point: they must either
+  point to the first byte of a code point or to the end of the buffer.
+  Lengths must be measured between two valid indices.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must perform zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the keyboard focus moves across
+  editable and non-editable elements of the UI. Those two requests are not
+  expected to be paired with each other, the compositor must be able to
+  handle consecutive series o

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

Hi Carlos,

thanks for reviewing!

On Tue, 17 Jul 2018 19:18:36 +0200
Carlos Garnacho  wrote:

> Hi!,
> 
> (Way way late, trying to revive the conversation...)
> 
> On Thu, May 3, 2018 at 9:22 PM, Dorota Czaplejewicz
>  wrote:
> > On Thu, 3 May 2018 20:47:27 +0200
> > Silvan Jegen  wrote:
> >  
> >> Hi Dorota
> >>
> >> Some comments and typo fixes below.
> >>
> >> On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:  
> >> > This new protocol description is a simplification over v2.
> >> >
> >> > - All pre-edit text styling is gone.
> >> > - Pre-edit cursor can span characters.
> >> > - No events regarding input panel (OSK) state nor covered rectangle.
> >> >   Compositors are still free to handle situations where the keyboard
> >> >   focus rectangle is covered by the input panel.
> >> > - No set_preferred_language request for clients.
> >> > - There is no event to send keysyms. Compositors can use wl_keyboard
> >> >   interface instead.
> >> > - All state is double-buffered, with specified state.
> >> > - Use Unicode codepoints to measure strings.
> >> >
> >> > Signed-off-by: Dorota Czaplejewicz 
> >> > Signed-off-by: Carlos Garnacho 
> >> > ---
> >> > This is the next update coming from Purism to perfect the text input 
> >> > protocol.
> >> >
> >> > The following changes added on top of PATCHv3:
> >> >
> >> > - Fixed whitespaces.
> >> > - Removed enable flags - the same information can be gathered from the 
> >> > first requests after enter.
> >> > - Changed offsets inside UTF-8 strings to use Unicode character counts 
> >> > in order to remove the possibility of communicating invalid state.
> >> > - Specified the exact lifetime of double-buffered state, and initial 
> >> > values.
> >> > - Made changes requested by the IM double-buffered.
> >> >
> >> > Some questions remain open. One is: how to specify how much text to 
> >> > capture in set_surrounding_text, and how often to update?  
> 
> IMHO the only reason to state it here is that it's more likely that a
> lazy implementation will try to squeeze a full book here, than eg. an
> application setting an insanely long title. But certainly other
> messages across protocols may hit this limit (the long title issue
> wasn't made up :).
> 
> As for how much, I think it ultimately depends on the IM behind. Text
> correction probably just wants the current word, any sort of
> prediction will probably require phrases to paragraphs, char
> composition can probably do without. Sounds like this could be some
> sort of hint, but I don't think IMs can tell you today how much text
> do they want...
> 
> >> >
> >> > A possible change that I decided against for now is to replace 
> >> > enable/disable events by create/destroy of a new object, which would 
> >> > make more state lifetimes encoded in the protocol.
> >> >
> >> > After reading a blog post on fcitx [0], I got the impression that 
> >> > letting the compositor know some persistent ID of a text edit instance 
> >> > could be useful, however I'm not sure what the use cases are.
> >> >
> >> > As always, I'm happy to hear feedback.
> >> >
> >> > Cheers,
> >> > Dorota Czaplejewicz
> >> >
> >> > [0] 
> >> > https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/
> >> >
> >> >  Makefile.am|   1 +
> >> >  unstable/text-input/text-input-unstable-v3.xml | 362 
> >> > +
> >> >  2 files changed, 363 insertions(+)
> >> >  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
> >> >
> >> > diff --git a/Makefile.am b/Makefile.am
> >> > index 4b9a901..86d7ca9 100644
> >> > --- a/Makefile.am
> >> > +++ b/Makefile.am
> >> > @@ -3,6 +3,7 @@ unstable_protocols = 
> >> >\
> >> > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml   
> >> >\
> >> > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml   
> >> >\
> >> > unstable/text-input/text-input-unstable-v1.xml 

[PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Provides the ability to emulate keyboards by applications. Complementary to 
input-method protocol.

The interface is a mirror copy of wl_keyboard, with removed serials, and added 
seat binding.
---
Hello,

thank you for giving me a lot of useful feedback in the last round. I applied 
the suggestions and this is the new incarnation of the protocol. Changes to v3, 
in no particular order:

- added clarification to the destructor
- namespaced enum references
- made virtual keyboard creation non-fatal

The responses about keeping a virtual keyboard on a separate connection and 
about using protocol errors as part of the authentication mechanism were all in 
agreement, and they made sense to me too. As a result, there is a whole new 
mechanism for that.

The client now requests a creation of a virtual keyboard, but does not 
immediately get a valid instance. It must wait for one of two events in 
virtual_keyboard_manager: `virtual_keyboard_create_failed` for a failure or 
`virtual_keyboard_created` for success. I deliberately kept them inside the 
manager instead of virtual_keyboard, since I don't like the idea of creating an 
object and immediately sending a message that it's useless (in case of failure).

I also deliberately kept the names long in order not to forget what's being 
manipulated.

The serial number is there to match up requests on different seats with 
failures. I imagine that a compositor might spam the user(s) with a number of 
permission requests for different seats, and the user would deal with them in a 
random order. Serials prevent the answers from getting mixed up.

I am not happy only with one aspect of this: the amount of time between create 
request and response is indefinite, opening a loophole for the compositor never 
to reply. I decided that it doesn't warrant a protocol error however.

As usual, feedback is welcome.

Cheers,
Dorota Czaplejewicz

 Makefile.am|   1 +
 unstable/virtual-keyboard/README   |   2 +
 .../virtual-keyboard-unstable-v1.xml   | 154 +
 3 files changed, 157 insertions(+)
 create mode 100644 unstable/virtual-keyboard/README
 create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 1aa13cf..17cedc1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README
new file mode 100644
index 000..a2c646d
--- /dev/null
+++ b/unstable/virtual-keyboard/README
@@ -0,0 +1,2 @@
+Virtual keyboard protocol
+
diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
new file mode 100644
index 000..173f3bc
--- /dev/null
+++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
@@ -0,0 +1,154 @@
+
+
+  
+Copyright © 2008-2011  Kristian Høgsberg
+Copyright © 2010-2013  Intel Corporation
+Copyright © 2012-2013  Collabora, Ltd.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  The virtual keyboard provides an application with requests which emulate
+  the behaviour of a physical keyboard.
+
+  This interface can be used by clients on its own to provide raw input
+  events, or it can accomp

Re: [PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

On Fri, 22 Jun 2018 12:36:16 -0400
Simon Ser  wrote:

> On June 22, 2018 4:20 PM, Dorota Czaplejewicz  
> wrote:
> > Provides the ability to emulate keyboards by applications. Complementary to 
> > input-method protocol.
> >
> > The interface is a mirror copy of wl_keyboard, with removed serials, and 
> > added seat binding.
> > ---
> > Hi,
> >
> > this patch is another improvement to the previously sent virtual keyboard 
> > protocol. Changes compared to v2:
> >
> > - readded enum names
> > - removed suggestion to listen to modifiers
> > - clarified untrusted client behaviour
> > - added destructor on virtual_keyboard_manager
> > - fixed text wrapping
> >
> > First off, the new version of wayland-scanner looks up enums found in other 
> > xml files, so the textual reference are gone and actual enum values are 
> > used.
> >
> > Secondly, there was a suggestion that if the client wants to know global 
> > modifiers, it should listen to wl_keyboard.modifiers. In reality, this can 
> > only be done when the client has keyboard focus. I decided to remove this 
> > suggestion.
> >
> > Clarified that create_virtual_keyboard must error out with unauthorized 
> > when an untrusted client connects. That doesn't preclude making the whole 
> > virtual_keyboard_manager interface unavailable when the client is 
> > determined as untrusted ahead of time.
> >
> > Lastly, added a missing destructor as per Simon Ser's suggestion.
> >
> > I hope that we're getting closer to perfect with this revision! As usual, 
> > feedback is welcome.
> >
> > Cheers,
> > Dorota Czaplejewicz  
> 
> Hi,
> 
> Thanks for this updated version. A few comments below.
> 
 snip 
> > +
> > +  
> > +
> > +  A virtual keyboard manager allows an application to provide keyboard
> > +  input events as if they came from a physical keyboard.
> > +
> > +  If the compositor enables a keyboard to perform arbitrary actions, it
> > +  should prevent untrusted clients from using this interface.
> > +
> > +
> > +
> > +   > +summary="client not authorized to use the interface"/>
> > +  
> 
> This is more of a general metaphorical question than anything else: I wonder 
> how
> we should handle unauthorized clients, and if adding an error for them is a 
> good
> idea. Generally errors are meant for protocol violations: it's clear from the
> protocol spec that e.g. sending a request with a negative value will trigger a
> protocol error. Also, errors are unrecoverable, they abort the whole client
> (though this is being worked on).
> 
> So here we use an error, and the conditions in which the error is sent are
> implementation-defined. I wonder if there's a better way to handle this
> situation?
> 
Speaking from a position of someone without a lot of Wayland experience: are 
Wayland errors meant to be recoverable by a client? It's obvious that if an 
application doing its primary task and then trying to use a restricted protocol 
as a secondary action crashes, that's undesireable.

As a more concrete example, an automation application may use e.g. DBus API to 
automate tasks, and display a window to control it. It may request a virtual 
keyboard to extend its possibilities, but it shouldn't suddenly stop working if 
it's refused by the compositor.

That brings me to the question: should applications using restricted protocols 
create additional connections which may be broken and recovered from 
individually or should they rather use one connection? If the latter is 
required for some use cases, then authorization and probing/graceful rejection 
should be specified inside protocols. Unfortunately, I'm not sure where to look 
for examples. Perhaps chat applications where screen sharing may be decided ad 
hoc check the marks?

> > +
> > +  
> > +Creates a new virtual keyboard associated to a seat.
> > +
> > +If an untrusted client issues this request, it should receive the
> > +unauthorized error in return.
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +   
> >  
> 
> This description should probably specify what happens to keyboards created 
> with
> the manager when the manager is destroyed. A common practice is not to destroy
> objects when the manager is destroyed, so that one can easily create the
> manager, use the factory request, and immediately destroy the manager (see 
> e.g.
> wl_subcompositor).

This is an oversight and 

[PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Provides the ability to emulate keyboards by applications. Complementary to 
input-method protocol.

The interface is a mirror copy of wl_keyboard, with removed serials, and added 
seat binding.
---
Hi,

this patch is another improvement to the previously sent virtual keyboard 
protocol. Changes compared to v2:

- readded enum names
- removed suggestion to listen to modifiers
- clarified untrusted client behaviour
- added destructor on virtual_keyboard_manager
- fixed text wrapping

First off, the new version of wayland-scanner looks up enums found in other xml 
files, so the textual reference are gone and actual enum values are used.

Secondly, there was a suggestion that if the client wants to know global 
modifiers, it should listen to wl_keyboard.modifiers. In reality, this can only 
be done when the client has keyboard focus. I decided to remove this suggestion.

Clarified that create_virtual_keyboard must error out with unauthorized when an 
untrusted client connects. That doesn't preclude making the whole 
virtual_keyboard_manager interface unavailable when the client is determined as 
untrusted ahead of time.

Lastly, added a missing destructor as per Simon Ser's suggestion.

I hope that we're getting closer to perfect with this revision! As usual, 
feedback is welcome.

Cheers,
Dorota Czaplejewicz

 Makefile.am|   1 +
 unstable/virtual-keyboard/README   |   2 +
 .../virtual-keyboard-unstable-v1.xml   | 116 +
 3 files changed, 119 insertions(+)
 create mode 100644 unstable/virtual-keyboard/README
 create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 1aa13cf..17cedc1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/virtual-keyboard/README b/unstable/virtual-keyboard/README
new file mode 100644
index 000..a2c646d
--- /dev/null
+++ b/unstable/virtual-keyboard/README
@@ -0,0 +1,2 @@
+Virtual keyboard protocol
+
diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
new file mode 100644
index 000..bde55e8
--- /dev/null
+++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
@@ -0,0 +1,116 @@
+
+
+  
+Copyright © 2008-2011  Kristian Høgsberg
+Copyright © 2010-2013  Intel Corporation
+Copyright © 2012-2013  Collabora, Ltd.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  The virtual keyboard provides an application with requests which emulate
+  the behaviour of a physical keyboard.
+
+  This interface can be used by clients on its own to provide raw input
+  events, or it can accompany the input method protocol.
+
+
+
+  
+Provide a file descriptor to the compositor which can be memory-mapped
+to provide a keyboard mapping description.
+  
+  
+  
+  
+
+
+
+  
+
+
+
+  
+A key was pressed or released.
+The time argument is a timestamp with millisecond granularity, with an
+undefined base. All requests regarding a single object must share the
+same clock.
+
+Keymap must be set before 

Re: [PATCH_v2] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

On Wed, 30 May 2018 14:28:12 +1000
Peter Hutterer  wrote:

> On Thu, May 24, 2018 at 08:27:29PM +0200, Dorota Czaplejewicz wrote:
> > Provides the ability to emulate keyboards by applications. Complementary to 
> > input-method protocol.
> > 
> > The interface is a mirror copy of wl_keyboard, with removed serials, and 
> > added seat binding.
> > ---
> > This is the slightly improved version of the virtual-keyboard-v1 protocol 
> > from Purism.
> > 
> > Changes done:
> > - fixed typos
> > - enum arguments don't have the "enum" key in them, in order not to trip up 
> > wayland-scanner
> > - added errors
> > 
> > The test client is at 
> > https://code.puri.sm/Librem5/weston/src/virtual_keyboard - please use the 
> > weston-keyboard program:
> > 
> > ./configure --enable-clients
> > ./weston-keyboard
> > 
> > A working wlroots implementation is available here:
> > 
> > https://github.com/swaywm/wlroots/pull/999
> > 
> > Thanks for feedback,
> > Dorota Czaplejewicz  
> 
> just one nitpick over Simon's comments, the copyright list starting at 2008
> seems excessive.
> 
> However, I wonder what you're really trying to achieve here. For virtual
> keyboards the mapping to a normal keyboard's physical buttons, then mapped
> to the glyph elsewhere seems strange and limiting. On a virtual keyboard,
> I'm not hitting KEY_A, I'm clicking on the button currently labelled with
> 'A'. There's a million things we could do to virtual keyboard that make the
> assumption of virtual keyboard == physical keyboards go boom quite quickly.
> e.g. on my phone once the emoticons are selected I don't get the normal
> qwerty layout anymore but just a row/column arrangement of smileys.
> 
> I read your v1 email about splitting input-method and virtual-keyboard but
> it's still not quite clear to me, sorry.
> 
> Cheers,
>Peter
> 

Hi Peter,

copyrights go back to 2008 because I used chunks of input-method and 
wayland.xml as the base.

This virtual keyboard protocol is just that - a way to provide an emulated 
input device. It's not expected to be a complete solution for what an actual 
on-screen keyboard is doing, but it's a necessary part. It allows for keyboard 
shortcuts to be used to interact with the compositor for example.

The second part of responsibilities of an on-screen keyboard is providing text 
composition capabilities, which covers the emojis you mentioned, but is also 
limited to text composition scenarios. As an example, it doesn't make sense to 
control the window manager by sending it text but they usually care about 
keyboard shortcuts.

These use cases both look like "a keyboard" as they were traditionally done 
with keyboards, but are really something completely different. To exaggerate 
the difference, the virtual-keyboard protocol is similar to using a game 
controller, and input-method is much closer to handwriting recognition than 
pressing buttons.

I hope that cleared it up a little. Either way, I will be submitting an 
input-method update soon to show the implementation.

Cheers,
Dorota
>  
> >  Makefile.am|   1 +
> >  unstable/virtual-keyboard/README   |   2 +
> >  .../virtual-keyboard-unstable-v1.xml   | 113 
> > +
> >  3 files changed, 116 insertions(+)
> >  create mode 100644 unstable/virtual-keyboard/README
> >  create mode 100644 
> > unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..fcd4572 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -17,6 +17,7 @@ unstable_protocols =  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > +   unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml  \
> > $(NULL)
> >  
> >  stable_protocols = 
> > \
> > diff --git a/unstable/virtual-keyboard/README 
> > b/unstable/virtual-keyboard/README
> > new file mode 100644
> > index 000..a2c646d
> > --- /dev/null
> > +++ b/unstable/virtual-keyboard/README
> > @@ -0,0 +1,2 @@
> > +Virtual keyboard protocol
> > +
> > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
> > b/unstable/virtual-keyboard/virtual-keyboard

Re: [PATCH] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Hello Roderick,

On Fri, 18 May 2018 19:23:15 +
<roderick.colenbran...@sony.com> wrote:

> Hi Dorota,
> 
> Thanks for sharing your proposal. Ourselves we have interest in this 
> kind of capability as well. Looking at our own use cases, I wonder if 
> this proposal goes far enough.
> 
> We are basically interested in the ability to inject keyboard, mouse, 
> touch (and gamepad). On regular X some of that worked through XTest 
> protocol. From my perspective any virtual keyboard proposal, would make 
> sense to be flexible enough to handle other input devices as well.

I thought about adding mouse or game controller support in the same protocol, 
but I came to the conclusion that they would be better off as dedicated 
protocols. We already have an input method protocol, which can be considered an 
input device, then the separate keyboard protocol already, and using a 
dedicated one for any other type of device would follow this trend.

The main reason to keep separate, however, is to keep it simple to develop. 
Personally, I don't have much of an idea about approaching a mouse or gamepad 
protocol, because they are not in the scope of what I'm doing. That puts a 
damper on my efforts regarding virtual keyboard. In the same way, I expect 
protocol designers of the future to only have experience in a subset of 
devices, and they will probably want to avoid worrying about possible changes 
to other devices when they update what they care about.
> 
> On the other hand some may bring up, why virtual device support should 
> be in Wayland as input devices can also be spoofed through uinput.
> 
Wayland can still be a good place for these kinds of protocols, due to how it 
handles seat assignment. I would not be able to ensure that an input method and 
a virtual keyboard is assigned the same seat if I tried to emulate the keyboard 
in a lower layer. I suspect that this is not the only possible issue in this 
area. The effect of a single standard interface is also important – 
applications don't have to rely on system-specific libraries any more, and make 
things like nested sessions much more palatable.

> Thanks,
> 
> Roderick Colenbrander
> Sr Manager Hardware & Systems Engineering
> Sony Interactive Entertainment
> 

Have a nice day,
Dorota Czaplejewicz

> On 05/17/2018 09:55 AM, Dorota Czaplejewicz wrote:
> > Provides the ability to emulate keyboards by applications. Complementary to 
> > input-method protocol.
> > 
> > The interface is a mirror copy of wl_keyboard, with removed serials, and 
> > added seat binding.
> > ---
> > 
> > This proposal is another one needed by Purism to support on screen 
> > keyboards on a phone screen.
> > 
> > Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
> > events. The need for this protocol comes from the fact that the 
> > input-method protocol combines two separate input responsibilities. It 
> > currently deals both with text input and raw keyboard events. I hope to 
> > split input-method along this line into virtual-keyboard and the rest of 
> > input-method. I'm going to submit the updated input-method for review soon.
> > 
> > Applications should be able to control both interfaces at the same time. A 
> > screen keyboard supporting autocorrect (input-method) still wants to send 
> > arrow keys (vityual-keyboard) correctly. Because of this, both kinds of 
> > events at minimum must be sent to the same seat. I made the seat binding 
> > explicitly done by the application, taking inspiration from text-input 
> > protocol, which assumes per-seat binding as well.
> > 
> > Input welcome.
> > 
> > Cheers,
> > Dorota
> > 
> >   Makefile.am|  1 +
> >   .../virtual-keyboard-unstable-v1.xml   | 97 
> > ++
> >   2 files changed, 98 insertions(+)
> >   create mode 100644 
> > unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..51a47a2 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -17,6 +17,7 @@ unstable_protocols =  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > +   nstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml   \
> > $(NULL)
> >   
> >   stable_protocols =

Re: [PATCH] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

On Thu, 17 May 2018 18:53:10 +0200
Dorota Czaplejewicz <dorota.czaplejew...@puri.sm> wrote:

> Provides the ability to emulate keyboards by applications. Complementary to 
> input-method protocol.
> 
> The interface is a mirror copy of wl_keyboard, with removed serials, and 
> added seat binding.
> ---
> 
> This proposal is another one needed by Purism to support on screen keyboards 
> on a phone screen.
> 
> Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
> events. The need for this protocol comes from the fact that the input-method 
> protocol combines two separate input responsibilities. It currently deals 
> both with text input and raw keyboard events. I hope to split input-method 
> along this line into virtual-keyboard and the rest of input-method. I'm going 
> to submit the updated input-method for review soon.
> 
> Applications should be able to control both interfaces at the same time. A 
> screen keyboard supporting autocorrect (input-method) still wants to send 
> arrow keys (vityual-keyboard) correctly. Because of this, both kinds of 
> events at minimum must be sent to the same seat. I made the seat binding 
> explicitly done by the application, taking inspiration from text-input 
> protocol, which assumes per-seat binding as well.
> 
> Input welcome.
> 
> Cheers,
> Dorota


Apart from the typo that Silvan spotted, I have also encountered the issue 
where the .c/.h generator complained about undefined key_state and 
keymap_format enums which are defined in wayland.xml. I'm not sure what the 
correct way to solve this - should they be copied into this protocol?

Cheers,
Dorota


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

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Thu, 17 May 2018 18:05:34 +0100
Daniel Stone <dan...@fooishbar.org> wrote:

> Hi Dorota,
> 
> On 3 May 2018 at 16:41, Dorota Czaplejewicz <dorota.czaplejew...@puri.sm> 
> wrote:
> > - There is no event to send keysyms. Compositors can use wl_keyboard
> >   interface instead.  
> 
> The reason we explicitly chose to have a keysym (really, 'Unicode
> codepoint') event, is to support characters which don't appear in any
> keymap. As a trivial example, emoji keyboards will want to send
> symbols which appear in no sane keymap. Similarly, CJK input methods
> may offer streams of characters pre-composed from component runs; it
> is not practical to insert the entire CJK unicode space into a keymap.
> 
> Cheers,
> Daniel


Hi Daniel,

I think that anyone wanting to support inserting arbitrary Unicode characters 
should use the text composition requests instead (commit_string and friends). 
Input methods, especially CJK ones, will make use of that functionality anyway. 
If removing keysyms makes something impossible, I would rather fix the text 
composition portion of the protocol.

Cheers,
Dorota


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

[PATCH] virtual-keyboard: Add new virtual keyboard protocol

[Dorota Czaplejewicz]

Provides the ability to emulate keyboards by applications. Complementary to 
input-method protocol.

The interface is a mirror copy of wl_keyboard, with removed serials, and added 
seat binding.
---

This proposal is another one needed by Purism to support on screen keyboards on 
a phone screen.

Virtual-keyboard is a protocol to let applications send arbitrary keyboard 
events. The need for this protocol comes from the fact that the input-method 
protocol combines two separate input responsibilities. It currently deals both 
with text input and raw keyboard events. I hope to split input-method along 
this line into virtual-keyboard and the rest of input-method. I'm going to 
submit the updated input-method for review soon.

Applications should be able to control both interfaces at the same time. A 
screen keyboard supporting autocorrect (input-method) still wants to send arrow 
keys (vityual-keyboard) correctly. Because of this, both kinds of events at 
minimum must be sent to the same seat. I made the seat binding explicitly done 
by the application, taking inspiration from text-input protocol, which assumes 
per-seat binding as well.

Input welcome.

Cheers,
Dorota

 Makefile.am|  1 +
 .../virtual-keyboard-unstable-v1.xml   | 97 ++
 2 files changed, 98 insertions(+)
 create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..51a47a2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -17,6 +17,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   nstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml   \
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml 
b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
new file mode 100644
index 000..18130e2
--- /dev/null
+++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml
@@ -0,0 +1,97 @@
+
+
+  
+Copyright © 2008-2011  Kristian Høgsberg
+Copyright © 2010-2013  Intel Corporation
+Copyright © 2012-2013  Collabora, Ltd.
+Copyright © 2018   Purism SPC
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  The virtual keyboard provides an application with requests which emulate
+  the behaviour of a physical keyboard.
+
+  This interface can be used by clients on its own to provide raw input
+  events, or it can accompany the input method protocol.
+
+
+
+  
+Provide a file descriptor to the compositor which can be
+memory-mapped to provide a keyboard mapping description.
+  
+  
+  
+  
+
+
+
+  
+A key was pressed or released.
+The time argument is a timestamp with millisecond granularity, with an
+undefined base. All requests regarding a single object must share the
+same clock.
+  
+  
+  
+  
+
+
+
+  
+Notifies the compositor that the modifier and/or group state has
+changed, and it should update state.
+
+The client should use wl_keyboard.modifiers event to synchronize its
+internal state with seat state.
+  
+  
+  
+  
+  
+
+
+
+  
+
+  
+
+  
+
+  A virtual keyboard manager allows an application to provide keyboard
+  input events as if they came from a physical keyboard.
+
+
+
+  
+Creates a new virtual keyboard associated to a seat.
+
+If the 

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Thu, 10 May 2018 11:43:12 +0200
Dorota Czaplejewicz <dorota.czaplejew...@puri.sm> wrote:

> On Tue, 08 May 2018 07:07:24 +
> Silvan Jegen <s.je...@gmail.com> wrote:
> 
> > On Mon, May 7, 2018 at 5:11 AM Joshua Watt <jpewhac...@gmail.com> wrote:  
> > > IMHO, if you are doing UTF-8 (which you should), you should *always*
> > > specify any offset in the string as a byte offset. I have a few
> > > reasons for this justification:
> > 
> > I agree with this as well. I thought some more about how to spell out my
> > gut feeling on this matter in more technical terms.
> > 
> > UTF-8 is a byte (sequence) representation of Unicode code points. This
> > indicates to me that an offset within an UTF-8-encoded string should also
> > be given in bytes. Specifying the offset in Unicode points mixes the
> > abstraction of the Unicode code point with (one of) its representations as
> > a byte sequence. This is reflected in the fact that an offset in Unicode
> > code points is not applicable to the UTF-8 string without first processing
> > the string.
> > 
> > Unicode code points do not give us that much either since what we most
> > likely want are grapheme clusters anyway (which, like any more advanced
> > Unicode processing, should be handled by a specialised library):
> > http://utf8everywhere.org/#myth.strlen
> > 
> > 
> > Cheers,
> > 
> > Silvan  
> 
> This message made me feel obliged to turn my own gut feeling into words. This 
> is not to be construed as an argument, but more of an explanation.
> 
> I view wayland protocols as rather high level: their responsibility is to 
> specify the type and the purpose of the data they are transporting. In this 
> case, the data is a Unicode string, and the purpose is display. Or, the data 
> is a number and the purpose is indexing.
> 
> I think that when a protocol starts to specify the type and purpose, it can 
> no longer be thought as high level. In this view, indexing a Unicode string 
> in terms of bytes would be akin to indexing any other vector of Foo in bytes. 
> (I didn't actually check if there is any other vector, or bytes type 
> available in wayland).
> 
> As you noted, there is some mixing between abstraction levels in the 
> protocol. Hardcoding that it's not *just* Unicode, but also the particular 
> encoding (UTF-8) eliminates problems with byte indexing we would have 
> encountered if we decided to use things like Punycode (München => 
> Mnchen-3ya). Knowing that it's always UTF-8 allows the protocol to use a 
> tailoring indexing scheme. While I consider this a layer-breaking hack, 
> nevertheless, this property partially counters the above reasoning.
> 
> * * *
> 
> To be honest, neither Unicode code points nor graphemes nor clusters are what 
> we're truly looking for here. To understand what I mean, I recommend to play 
> with this grapheme cluster:
> 
> नमस्ते
> 
> According to the Rust book [0], it's composed of 6 code points: ['न', 'म', 
> 'स', '्', 'त', 'े'], but moving the cursor around, I would be led to believe 
> it's 4 "pieces" long only.
> 
> Cheers,
> Dorota
> 
> [0] https://doc.rust-lang.org/book/second-edition/ch08-02-strings.html

On a second thought, perhaps graphemes are actually the relevant thing here...


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

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Tue, 08 May 2018 07:07:24 +
Silvan Jegen  wrote:

> On Mon, May 7, 2018 at 5:11 AM Joshua Watt  wrote:
> > IMHO, if you are doing UTF-8 (which you should), you should *always*
> > specify any offset in the string as a byte offset. I have a few
> > reasons for this justification:  
> 
> I agree with this as well. I thought some more about how to spell out my
> gut feeling on this matter in more technical terms.
> 
> UTF-8 is a byte (sequence) representation of Unicode code points. This
> indicates to me that an offset within an UTF-8-encoded string should also
> be given in bytes. Specifying the offset in Unicode points mixes the
> abstraction of the Unicode code point with (one of) its representations as
> a byte sequence. This is reflected in the fact that an offset in Unicode
> code points is not applicable to the UTF-8 string without first processing
> the string.
> 
> Unicode code points do not give us that much either since what we most
> likely want are grapheme clusters anyway (which, like any more advanced
> Unicode processing, should be handled by a specialised library):
> http://utf8everywhere.org/#myth.strlen
> 
> 
> Cheers,
> 
> Silvan

This message made me feel obliged to turn my own gut feeling into words. This 
is not to be construed as an argument, but more of an explanation.

I view wayland protocols as rather high level: their responsibility is to 
specify the type and the purpose of the data they are transporting. In this 
case, the data is a Unicode string, and the purpose is display. Or, the data is 
a number and the purpose is indexing.

I think that when a protocol starts to specify the type and purpose, it can no 
longer be thought as high level. In this view, indexing a Unicode string in 
terms of bytes would be akin to indexing any other vector of Foo in bytes. (I 
didn't actually check if there is any other vector, or bytes type available in 
wayland).

As you noted, there is some mixing between abstraction levels in the protocol. 
Hardcoding that it's not *just* Unicode, but also the particular encoding 
(UTF-8) eliminates problems with byte indexing we would have encountered if we 
decided to use things like Punycode (München => Mnchen-3ya). Knowing that it's 
always UTF-8 allows the protocol to use a tailoring indexing scheme. While I 
consider this a layer-breaking hack, nevertheless, this property partially 
counters the above reasoning.

* * *

To be honest, neither Unicode code points nor graphemes nor clusters are what 
we're truly looking for here. To understand what I mean, I recommend to play 
with this grapheme cluster:

नमस्ते

According to the Rust book [0], it's composed of 6 code points: ['न', 'म', 'स', 
'्', 'त', 'े'], but moving the cursor around, I would be led to believe it's 4 
"pieces" long only.

Cheers,
Dorota

[0] https://doc.rust-lang.org/book/second-edition/ch08-02-strings.html


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

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Sun, 6 May 2018 22:11:32 -0500
Joshua Watt <jpewhac...@gmail.com> wrote:

> On Sun, May 6, 2018 at 3:37 PM, Dorota Czaplejewicz
> <dorota.czaplejew...@puri.sm> wrote:
> > On Sat, 5 May 2018 13:37:44 +0200
> > Silvan Jegen <s.je...@gmail.com> wrote:
> >  
> >> On Sat, May 05, 2018 at 11:09:10AM +0200, Dorota Czaplejewicz wrote:  
> >> > On Fri, 4 May 2018 22:32:15 +0200
> >> > Silvan Jegen <s.je...@gmail.com> wrote:
> >> >  
> >> > > On Thu, May 03, 2018 at 10:46:47PM +0200, Dorota Czaplejewicz wrote:  
> >> > > > On Thu, 3 May 2018 21:55:40 +0200
> >> > > > Silvan Jegen <s.je...@gmail.com> wrote:
> >> > > >  
> >> > > > > On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz 
> >> > > > > wrote:  
> >> > > > > > On Thu, 3 May 2018 20:47:27 +0200
> >> > > > > > Silvan Jegen <s.je...@gmail.com> wrote:
> >> > > > > >  
> >> > > > > > > Hi Dorota
> >> > > > > > >
> >> > > > > > > Some comments and typo fixes below.
> >> > > > > > >
> >> > > > > > > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz 
> >> > > > > > > wrote:  
> >> > > > > > > > +  Text is valid UTF-8 encoded, indices and lengths are 
> >> > > > > > > > in code points. If a
> >> > > > > > > > +  grapheme is made up of multiple code points, an index 
> >> > > > > > > > pointing to any of
> >> > > > > > > > +  them should be interpreted as pointing to the first 
> >> > > > > > > > one.  
> >> > > > > > >
> >> > > > > > > That way we make sure we don't put the cursor/anchor between 
> >> > > > > > > bytes that
> >> > > > > > > belong to the same UTF-8 encoded Unicode code point which is 
> >> > > > > > > nice. It
> >> > > > > > > also means that the client has to parse all the UTF-8 encoded 
> >> > > > > > > strings
> >> > > > > > > into Unicode code points up to the desired cursor/anchor 
> >> > > > > > > position
> >> > > > > > > on each "preedit_string" event. For each 
> >> > > > > > > "delete_surrounding_text" event
> >> > > > > > > the client has to parse the UTF-8 sequences before and after 
> >> > > > > > > the cursor
> >> > > > > > > position up to the requested Unicode code point.
> >> > > > > > >
> >> > > > > > > I feel like we are processing the UTF-8 string already in the
> >> > > > > > > input-method. So I am not sure that we should parse it again 
> >> > > > > > > on the
> >> > > > > > > client side. Parsing it again would also mean that the client 
> >> > > > > > > would need
> >> > > > > > > to know about UTF-8 which would be nice to avoid.
> >> > > > > > >
> >> > > > > > > Thoughts?  
> >> > > > > >
> >> > > > > > The client needs to know about Unicode, but not necessarily about
> >> > > > > > UTF-8. Specifying code points is actually an advantage here, 
> >> > > > > > because
> >> > > > > > byte offsets are inherently expressed relative to UTF-8. By 
> >> > > > > > counting
> >> > > > > > with code points, client's internal representation can be UTF-16 
> >> > > > > > or
> >> > > > > > maybe even something else.  
> >> > > > >
> >> > > > > Maybe I am misunderstanding something but the protocol specifies 
> >> > > > > that
> >> > > > > the strings are valid UTF-8 encoded and the cursor/anchor offsets 
> >> > > > > into
> >> > > > > the strings are specified in Unicode points. To me that indicates 
> >> > > > > that
> >> > > > > the application *has to parse* the UTF-8 strin

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Sat, 5 May 2018 13:37:44 +0200
Silvan Jegen <s.je...@gmail.com> wrote:

> On Sat, May 05, 2018 at 11:09:10AM +0200, Dorota Czaplejewicz wrote:
> > On Fri, 4 May 2018 22:32:15 +0200
> > Silvan Jegen <s.je...@gmail.com> wrote:
> >   
> > > On Thu, May 03, 2018 at 10:46:47PM +0200, Dorota Czaplejewicz wrote:  
> > > > On Thu, 3 May 2018 21:55:40 +0200
> > > > Silvan Jegen <s.je...@gmail.com> wrote:
> > > > 
> > > > > On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz wrote:  
> > > > >   
> > > > > > On Thu, 3 May 2018 20:47:27 +0200
> > > > > > Silvan Jegen <s.je...@gmail.com> wrote:
> > > > > >   
> > > > > > > Hi Dorota
> > > > > > > 
> > > > > > > Some comments and typo fixes below.
> > > > > > > 
> > > > > > > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz 
> > > > > > > wrote:  
> > > > > > > > +  Text is valid UTF-8 encoded, indices and lengths are in 
> > > > > > > > code points. If a
> > > > > > > > +  grapheme is made up of multiple code points, an index 
> > > > > > > > pointing to any of
> > > > > > > > +  them should be interpreted as pointing to the first one. 
> > > > > > > >
> > > > > > > 
> > > > > > > That way we make sure we don't put the cursor/anchor between 
> > > > > > > bytes that
> > > > > > > belong to the same UTF-8 encoded Unicode code point which is 
> > > > > > > nice. It
> > > > > > > also means that the client has to parse all the UTF-8 encoded 
> > > > > > > strings
> > > > > > > into Unicode code points up to the desired cursor/anchor position
> > > > > > > on each "preedit_string" event. For each 
> > > > > > > "delete_surrounding_text" event
> > > > > > > the client has to parse the UTF-8 sequences before and after the 
> > > > > > > cursor
> > > > > > > position up to the requested Unicode code point.
> > > > > > > 
> > > > > > > I feel like we are processing the UTF-8 string already in the
> > > > > > > input-method. So I am not sure that we should parse it again on 
> > > > > > > the
> > > > > > > client side. Parsing it again would also mean that the client 
> > > > > > > would need
> > > > > > > to know about UTF-8 which would be nice to avoid.
> > > > > > > 
> > > > > > > Thoughts?  
> > > > > > 
> > > > > > The client needs to know about Unicode, but not necessarily about
> > > > > > UTF-8. Specifying code points is actually an advantage here, because
> > > > > > byte offsets are inherently expressed relative to UTF-8. By counting
> > > > > > with code points, client's internal representation can be UTF-16 or
> > > > > > maybe even something else.  
> > > > > 
> > > > > Maybe I am misunderstanding something but the protocol specifies that
> > > > > the strings are valid UTF-8 encoded and the cursor/anchor offsets into
> > > > > the strings are specified in Unicode points. To me that indicates that
> > > > > the application *has to parse* the UTF-8 string into Unicode points
> > > > > when receiving the event otherwise it doesn't know after which Unicode
> > > > > point to draw the cursor. Of course the application can then decide to
> > > > > convert the UTF-8 string into another encoding like UTF-16 for 
> > > > > internal
> > > > > processing (for whatever reason) but that doesn't change the fact that
> > > > > it still would have to parse the incoming UTF-8 (and thus know about
> > > > > UTF-8).
> > > > > 
> > > > Can you see any way to avoid parsing UTF-8 in order to draw the
> > > > cursor? I tried to come up with a way to do that, but even with
> > > > specifying byte strings, I believe that calculating the position of
> > > > the cursor - either in pixels or in glyphs - requires full parsing of
> > > > the input str

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Fri, 4 May 2018 22:32:15 +0200
Silvan Jegen <s.je...@gmail.com> wrote:

> On Thu, May 03, 2018 at 10:46:47PM +0200, Dorota Czaplejewicz wrote:
> > On Thu, 3 May 2018 21:55:40 +0200
> > Silvan Jegen <s.je...@gmail.com> wrote:
> >   
> > > On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz wrote:  
> > > > On Thu, 3 May 2018 20:47:27 +0200
> > > > Silvan Jegen <s.je...@gmail.com> wrote:
> > > > 
> > > > > Hi Dorota
> > > > > 
> > > > > Some comments and typo fixes below.
> > > > > 
> > > > > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:  
> > > > >   
> > > > > > +  Text is valid UTF-8 encoded, indices and lengths are in code 
> > > > > > points. If a
> > > > > > +  grapheme is made up of multiple code points, an index 
> > > > > > pointing to any of
> > > > > > +  them should be interpreted as pointing to the first one. 
> > > > > >  
> > > > > 
> > > > > That way we make sure we don't put the cursor/anchor between bytes 
> > > > > that
> > > > > belong to the same UTF-8 encoded Unicode code point which is nice. It
> > > > > also means that the client has to parse all the UTF-8 encoded strings
> > > > > into Unicode code points up to the desired cursor/anchor position
> > > > > on each "preedit_string" event. For each "delete_surrounding_text" 
> > > > > event
> > > > > the client has to parse the UTF-8 sequences before and after the 
> > > > > cursor
> > > > > position up to the requested Unicode code point.
> > > > > 
> > > > > I feel like we are processing the UTF-8 string already in the
> > > > > input-method. So I am not sure that we should parse it again on the
> > > > > client side. Parsing it again would also mean that the client would 
> > > > > need
> > > > > to know about UTF-8 which would be nice to avoid.
> > > > > 
> > > > > Thoughts?
> > > > 
> > > > The client needs to know about Unicode, but not necessarily about
> > > > UTF-8. Specifying code points is actually an advantage here, because
> > > > byte offsets are inherently expressed relative to UTF-8. By counting
> > > > with code points, client's internal representation can be UTF-16 or
> > > > maybe even something else.
> > > 
> > > Maybe I am misunderstanding something but the protocol specifies that
> > > the strings are valid UTF-8 encoded and the cursor/anchor offsets into
> > > the strings are specified in Unicode points. To me that indicates that
> > > the application *has to parse* the UTF-8 string into Unicode points
> > > when receiving the event otherwise it doesn't know after which Unicode
> > > point to draw the cursor. Of course the application can then decide to
> > > convert the UTF-8 string into another encoding like UTF-16 for internal
> > > processing (for whatever reason) but that doesn't change the fact that
> > > it still would have to parse the incoming UTF-8 (and thus know about
> > > UTF-8).
> > >   
> > Can you see any way to avoid parsing UTF-8 in order to draw the
> > cursor? I tried to come up with a way to do that, but even with
> > specifying byte strings, I believe that calculating the position of
> > the cursor - either in pixels or in glyphs - requires full parsing of
> > the input string.  
> 
> Yes, I don't think it's avoidable either. You just don't have to do
> it twice if your text rendering library consumes UTF-8 strings with
> byte-offsets though. See my response below.
> 
> 
> > > > There's no avoiding the parsing either. What the application cares
> > > > about is that the cursor falls between glyphs. The application cannot
> > > > know that in all cases. Unicode allows the same sequence to be
> > > > displayed in multiple ways (fallback):
> > > > 
> > > > https://unicode.org/emoji/charts/emoji-zwj-sequences.html
> > > > 
> > > > One could make an argument that byte offsets should never be close
> > > > to ZWJ characters, but I think this decision is better left to the
> > > > application, which knows what exactly it is presenting to the user.
> > > 
> > > The idea of the previous 

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Thu, 3 May 2018 21:55:40 +0200
Silvan Jegen <s.je...@gmail.com> wrote:

> On Thu, May 03, 2018 at 09:22:46PM +0200, Dorota Czaplejewicz wrote:
> > On Thu, 3 May 2018 20:47:27 +0200
> > Silvan Jegen <s.je...@gmail.com> wrote:
> >   
> > > Hi Dorota
> > > 
> > > Some comments and typo fixes below.
> > > 
> > > On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:  
> > > > +  Text is valid UTF-8 encoded, indices and lengths are in code 
> > > > points. If a
> > > > +  grapheme is made up of multiple code points, an index pointing 
> > > > to any of
> > > > +  them should be interpreted as pointing to the first one.
> > > 
> > > That way we make sure we don't put the cursor/anchor between bytes that
> > > belong to the same UTF-8 encoded Unicode code point which is nice. It
> > > also means that the client has to parse all the UTF-8 encoded strings
> > > into Unicode code points up to the desired cursor/anchor position
> > > on each "preedit_string" event. For each "delete_surrounding_text" event
> > > the client has to parse the UTF-8 sequences before and after the cursor
> > > position up to the requested Unicode code point.
> > > 
> > > I feel like we are processing the UTF-8 string already in the
> > > input-method. So I am not sure that we should parse it again on the
> > > client side. Parsing it again would also mean that the client would need
> > > to know about UTF-8 which would be nice to avoid.
> > > 
> > > Thoughts?  
> > 
> > The client needs to know about Unicode, but not necessarily about
> > UTF-8. Specifying code points is actually an advantage here, because
> > byte offsets are inherently expressed relative to UTF-8. By counting
> > with code points, client's internal representation can be UTF-16 or
> > maybe even something else.  
> 
> Maybe I am misunderstanding something but the protocol specifies that
> the strings are valid UTF-8 encoded and the cursor/anchor offsets into
> the strings are specified in Unicode points. To me that indicates that
> the application *has to parse* the UTF-8 string into Unicode points
> when receiving the event otherwise it doesn't know after which Unicode
> point to draw the cursor. Of course the application can then decide to
> convert the UTF-8 string into another encoding like UTF-16 for internal
> processing (for whatever reason) but that doesn't change the fact that
> it still would have to parse the incoming UTF-8 (and thus know about
> UTF-8).
> 
Can you see any way to avoid parsing UTF-8 in order to draw the cursor? I tried 
to come up with a way to do that, but even with specifying byte strings, I 
believe that calculating the position of the cursor - either in pixels or in 
glyphs - requires full parsing of the input string.

> 
> > There's no avoiding the parsing either. What the application cares
> > about is that the cursor falls between glyphs. The application cannot
> > know that in all cases. Unicode allows the same sequence to be
> > displayed in multiple ways (fallback):
> > 
> > https://unicode.org/emoji/charts/emoji-zwj-sequences.html
> > 
> > One could make an argument that byte offsets should never be close
> > to ZWJ characters, but I think this decision is better left to the
> > application, which knows what exactly it is presenting to the user.  
> 
> The idea of the previous version of the protocol (from my understanding)
> was to make sure that only valid UTF-8 and valid byte-offsets (== not
> falling between bytes of a Unicode code point) into the string will be
> sent to the client. If you just get a byte-offset into a UTF-8 encoded
> string you trust the sender to honor the protocol and thus you can just
> pass the UTF-8 encoded string unprocessed to your text rendering library
> (provided that the library supports UTF-8 strings which is what I am
> assuming) without having to parse the UTF-8 string into Unicode code
> points.
> 
> Of course the Unicode code points will have to be parsed at some point
> if you want to render them. Using byte-offsets just lets you do that at
> a later stage if your libraries support UTF-8.
> 
> 
Doesn't that chiefly depend on what kind of the text rendering library though? 
As far as I understand, passing text to rendering is necessary to calculate the 
cursor position. At the same time, it doesn't matter much for the calculations 
whether the cursor offset is in bytes or code points - the library does the 
parsing in the last step anyway.

I think you mean that if the rendering library a

Re: [PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Thu, 3 May 2018 20:47:27 +0200
Silvan Jegen <s.je...@gmail.com> wrote:

> Hi Dorota
> 
> Some comments and typo fixes below.
> 
> On Thu, May 03, 2018 at 05:41:21PM +0200, Dorota Czaplejewicz wrote:
> > This new protocol description is a simplification over v2.
> > 
> > - All pre-edit text styling is gone.
> > - Pre-edit cursor can span characters.
> > - No events regarding input panel (OSK) state nor covered rectangle.
> >   Compositors are still free to handle situations where the keyboard
> >   focus rectangle is covered by the input panel.
> > - No set_preferred_language request for clients.
> > - There is no event to send keysyms. Compositors can use wl_keyboard
> >   interface instead.
> > - All state is double-buffered, with specified state.
> > - Use Unicode codepoints to measure strings.
> > 
> > Signed-off-by: Dorota Czaplejewicz <dorota.czaplejew...@puri.sm>
> > Signed-off-by: Carlos Garnacho <carl...@gnome.org>
> > ---
> > This is the next update coming from Purism to perfect the text input 
> > protocol.
> > 
> > The following changes added on top of PATCHv3:
> > 
> > - Fixed whitespaces.
> > - Removed enable flags - the same information can be gathered from the 
> > first requests after enter.
> > - Changed offsets inside UTF-8 strings to use Unicode character counts in 
> > order to remove the possibility of communicating invalid state.
> > - Specified the exact lifetime of double-buffered state, and initial values.
> > - Made changes requested by the IM double-buffered.
> > 
> > Some questions remain open. One is: how to specify how much text to capture 
> > in set_surrounding_text, and how often to update?
> > 
> > A possible change that I decided against for now is to replace 
> > enable/disable events by create/destroy of a new object, which would make 
> > more state lifetimes encoded in the protocol.
> > 
> > After reading a blog post on fcitx [0], I got the impression that letting 
> > the compositor know some persistent ID of a text edit instance could be 
> > useful, however I'm not sure what the use cases are.
> > 
> > As always, I'm happy to hear feedback.
> > 
> > Cheers,
> > Dorota Czaplejewicz
> > 
> > [0] 
> > https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/
> > 
> >  Makefile.am|   1 +
> >  unstable/text-input/text-input-unstable-v3.xml | 362 
> > +
> >  2 files changed, 363 insertions(+)
> >  create mode 100644 unstable/text-input/text-input-unstable-v3.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..86d7ca9 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -3,6 +3,7 @@ unstable_protocols =
> > \
> > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
> > \
> > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
> > \
> > unstable/text-input/text-input-unstable-v1.xml  
> > \
> > +   unstable/text-input/text-input-unstable-v3.xml  
> > \
> > unstable/input-method/input-method-unstable-v1.xml  
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > \
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > \
> > diff --git a/unstable/text-input/text-input-unstable-v3.xml 
> > b/unstable/text-input/text-input-unstable-v3.xml
> > new file mode 100644
> > index 000..ed5204f
> > --- /dev/null
> > +++ b/unstable/text-input/text-input-unstable-v3.xml
> > @@ -0,0 +1,362 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2012, 2013 Intel Corporation
> > +Copyright © 2015, 2016 Jan Arne Petersen
> > +Copyright © 2017, 2018 Red Hat, Inc.
> > +Copyright © 2018 Purism SPC
> > +
> > +Permission to use, copy, modify, distribute, and sell this
> > +software and its documentation for any purpose is hereby granted
> > +without fee, provided that the above copyright notice appear in
> > +all copies and that both that copyright notice and this permission
> > +notice appear in supporting documentation, and that the name of
> > +the copyright holders not be used in advertising or publicity
> > +pertaining to distribution of the software without specific,
>

[PATCHv4 wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

From: Carlos Garnacho <carl...@gnome.org>

This new protocol description is a simplification over v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.
- All state is double-buffered, with specified state.
- Use Unicode codepoints to measure strings.

Signed-off-by: Dorota Czaplejewicz <dorota.czaplejew...@puri.sm>
Signed-off-by: Carlos Garnacho <carl...@gnome.org>
---
This is the next update coming from Purism to perfect the text input protocol.

The following changes added on top of PATCHv3:

- Fixed whitespaces.
- Removed enable flags - the same information can be gathered from the first 
requests after enter.
- Changed offsets inside UTF-8 strings to use Unicode character counts in order 
to remove the possibility of communicating invalid state.
- Specified the exact lifetime of double-buffered state, and initial values.
- Made changes requested by the IM double-buffered.

Some questions remain open. One is: how to specify how much text to capture in 
set_surrounding_text, and how often to update?

A possible change that I decided against for now is to replace enable/disable 
events by create/destroy of a new object, which would make more state lifetimes 
encoded in the protocol.

After reading a blog post on fcitx [0], I got the impression that letting the 
compositor know some persistent ID of a text edit instance could be useful, 
however I'm not sure what the use cases are.

As always, I'm happy to hear feedback.

Cheers,
Dorota Czaplejewicz

[0] 
https://www.csslayer.info/wordpress/fcitx-dev/gaps-between-wayland-and-fcitx-or-all-input-methods/

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 362 +
 2 files changed, 363 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..ed5204f
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,362 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018 Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the ente

[PATCH wayland-protocols v3] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

This new protocol description is a simplification over v2.

- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
  Compositors are still free to handle situations where the keyboard
  focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
  interface instead.

Signed-off-by: Dorota Czaplejewicz <dorota.czaplejew...@puri.sm>
Signed-off-by: Carlos Garnacho <carl...@gnome.org>
Reviewed-by: Drew DeVault <s...@cmpwn.com>
---
This patch introduces an updated text input protocol. The only content
change compared to v2 of the patch is that the cursor can span multiple
characters. This change is meant to accommodate for input methods where
pieces of pre-edit text can be adjusted separately.

To show an example, cursor_begin and cursor_end of preedit_string event
would mark the bounds of the blue highlight in the screenshot [0],
ignoring the vertical line which I've been told is not relevant in
Asian input methods.

This patch also fixes the metadata by correctly attributing Carlos
Garnacho in the commit, and makes the patch apply.

Thanks for the feedback.

Dorota Czaplejewicz

[0] https://i.imgur.com/MpibNVi.png

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v3.xml | 308 +
 2 files changed, 309 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v3.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v3.xml 
b/unstable/text-input/text-input-unstable-v3.xml
new file mode 100644
index 000..f5d43e7
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v3.xml
@@ -0,0 +1,308 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+Copyright © 2017, 2018 Red Hat, Inc.
+Copyright © 2018 Purism SPC
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v3 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the pre-edit and commit_string events.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  have to always point to the first byte of an UTF-8 encoded code point.
+  Lengths are not allowed to contain just a part of an UTF-8 encoded code
+  point.
+
+  Focus moving throughout surfaces will result in the emission of
+  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
+  surface must perform zwp_text_input_v3.enable and
+  zwp_text_input_v3.disable requests as the

Re: [PATCHv2] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Thu, 12 Apr 2018 21:26:08 +0200
Silvan Jegen <s.je...@gmail.com> wrote:

> Hi Dorota
> 
> On Wed, Apr 11, 2018 at 03:03:58PM +0200, Dorota Czaplejewicz wrote:
> > This new protocol description is a simplification over v2.
> > 
> > - All pre-edit text styling is gone.
> > - No events regarding input panel (OSK) state nor covered rectangle.
> >   Compositors are still free to handle situations where the keyboard
> >   focus rectangle is covered by the input panel.
> > - No set_preferred_language request for clients.
> > - There is no event to send keysyms. Compositors can use wl_keyboard
> >   interface instead.
> > 
> > Reviewed-by: Drew DeVault <s...@cmpwn.com>
> > ---
> > 
> > Hi,
> > 
> > This patch follows the original proposal by Carlos Garnacho. It's the
> > result of my work on behalf of Purism to get good on-screen keyboard
> > support in Wayland. It incorporates changes coming from discussions
> > with Sway/wlroots developers [0], as well as issues pointed out in
> > response to the original proposal.
> > 
> > Changes over the original:
> > - typos, whitespace and naming as pointed out by Silvan Jegen
> > - an explicit description of what happens to state: it's conceptually
> >   double-buffered, and is not altered between focus events
> > - removed the serial number on enter/leave events, as it's unambiguous
> >   which surface has focus
> > 
> > This protocol has already been implemented: in wlroots [0], rootston
> > [1], and GTK3 [2]. We're counting on more projects to upstream support
> > in order to settle on a single protocol for text input in the long
> > term. Help and feedback appreciated!
> > 
> > Cheers,
> > Dorota Czaplejewicz
> > 
> > PS. Sorry about the misformatted email on Monday.
> > 
> > [0] https://github.com/swaywm/wlroots/pull/776
> > [1] https://code.puri.sm/dorota.czaplejewicz/gtk
> > [2] https://code.puri.sm/dorota.czaplejewicz/wlroots/src/text_input_test  
> 
> The last two references seem to be switched.
> 
> I also might be dense but when I am trying to build the text_input_test
> branch of your wlroots repo I get the following error because of a
> missing text_input.h header file:
> 
> [41/132] Compiling C object 'rootston/rootston@exe/main.c.o'.
> FAILED: rootston/rootston@exe/main.c.o
> cc  -Irootston/rootston@exe -Irootston -I../rootston -Iinclude -I../include 
> -I/usr/include/libdrm -I/usr/include/libevdev-1.0/ 
> -I/usr/include/libwacom-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 
> -I/home/silvan/builds/wlroots-dorota/build -fdiagnostics-color=always -pipe 
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O0 -g 
> -Wno-unused-parameter '-DWLR_SRC_DIR="/home/silvan/builds/wlroots-dorota"' 
> -DWL_HIDE_DEPRECATED -MD -MQ 'rootston/rootston@exe/main.c.o' -MF 
> 'rootston/rootston@exe/main.c.o.d' -o 'rootston/rootston@exe/main.c.o' -c 
> ../rootston/main.c
> In file included from ../include/rootston/cursor.h:4:0,
>  from ../include/rootston/input.h:9,
>  from ../include/rootston/server.h:15,
>  from ../rootston/main.c:13:
> ../include/rootston/seat.h:7:10: fatal error: rootston/text_input.h: No such 
> file or directory
>  #include "rootston/text_input.h"
>   ^~~
> compilation terminated.
> [42/132] Compiling C object 'rootston/rootston@exe/output.c.o'.
> FAILED: rootston/rootston@exe/output.c.o
> cc  -Irootston/rootston@exe -Irootston -I../rootston -Iinclude -I../include 
> -I/usr/include/libdrm -I/usr/include/libevdev-1.0/ 
> -I/usr/include/libwacom-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 
> -I/home/silvan/builds/wlroots-dorota/build -fdiagnostics-color=always -pipe 
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O0 -g 
> -Wno-unused-parameter '-DWLR_SRC_DIR="/home/silvan/builds/wlroots-dorota"' 
> -DWL_HIDE_DEPRECATED -MD -MQ 'rootston/rootston@exe/output.c.o' -MF 
> 'rootston/rootston@exe/output.c.o.d' -o 'rootston/rootston@exe/output.c.o' -c 
> ../rootston/output.c
> In file included from ../include/rootston/cursor.h:4:0,
>  from ../include/rootston/input.h:9,
>  from ../include/rootston/server.h:15,
>  from ../rootston/output.c:18:
> ../include/rootston/seat.h:7:10: fatal error: rootston/text_input.h: No such 
> file or directory
>  #include "rootston/text_input.h"
> 
> ... etc.
> 
> Am I supposed to generate that file myself somehow?
> 
> 
> Cheers,
> 
> Silvan

Hi Silvan,

thank you for noticing, I apparently didn't check in that file. That has been 
hopefully fixed - I recreated and pushed it to the repository.

Sorry about the silly mistake.

Cheers,
Dorota


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

Re: [wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Thu, 12 Apr 2018 10:35:04 +0200
Jonas Ådahl <jad...@gmail.com> wrote:

> On Thu, Apr 12, 2018 at 12:13:49AM +0200, Carlos Garnacho wrote:
> > Hi!,
> > 
> > On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian <wen...@gmail.com> wrote:  
> > > (forgot to reply to the list)
> > >
> > > On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:  
> > >> On Wed, 11 Apr 2018 11:26:22 -0700
> > >>
> > >> Weng Xuetian <wen...@gmail.com> wrote:  
> > >> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:  
> > >> > > On Sun, 11 Mar 2018 20:30:14 +0100
> > >> > >
> > >> > > Carlos Garnacho <carl...@gnome.org> wrote:  
> > >> > > > This new protocol description is a vast simplification over v2,
> > >> > > > highlights
> > >> > > > are:
> > >> > > > - All pre-edit text styling is gone, the protocol doesn't seem the
> > >> > > > place
> > >> > > >
> > >> > > >   to convey UI state. Clients are in better knowledge of how to 
> > >> > > > make
> > >> > > >   the
> > >> > > >   pre-edit string distinguishable from regular text.  
> > >> >
> > >> > As an long-time input method developer and CJK user, I'd prefer to keep
> > >> > the
> > >> > styling. In Chinese or Japanese, partially converted text are common 
> > >> > and
> > >> > styling is useful to help user to distinguish which text is currently
> > >> > being
> > >> > converted. [1] But for the sake of in-app consistency, I'd say we don't
> > >> > need that much capability about styling though. Among all input methods
> > >> > supported by fcitx [2], only underline/highlight is being commonly 
> > >> > used.
> > >> > Recently I started to use some strike style in only one single input
> > >> > method though, it can also be useful in certain cases.  
> > >>
> > >> I think this use case is covered. For indicating what's currently being
> > >> changed, this protocol is using "preedit string". In GTK, the preedit 
> > >> text
> > >> is displayed with an underline, making is always clear what the 
> > >> suggestion
> > >> pertains to.  
> > > I think you can take a closer look at [1].
> > >
> > > "葵あ" is the complete preedit text. The input method is converting "葵" and
> > > giving the candidates for it, the あ part is not yet handled by input 
> > > method
> > > (but typed by user and appears in the preedit). That's why "葵" is being
> > > highlighted.  
> > 
> > IIUC, is あ simply unhighlighted till handled by the IM (and the
> > suggestion menu changes accordingly)? do preedit text styles in other
> > fcitx IMs convey the same or different info?  
> 
> "葵あ" is both part of the pre-edit string, thus would be highlighted by
> e.g. GTK+ as far as I know, what we probably want is a semantical way to
> communicate that one part of the pre-edit string is currently being
> "fine grained". For example, take the following longer string:
> 
> 賣煎盤
> 
> Which means "sell frying pan". What I meant to write, however, was "buy
> keyboard", which with some input method is typed in exactly the same
> way. To correct the pre-edit string, I'll need to go through the various
> parts of the pre-edit string, and a way to highlight what is being fine
> grained I think is what is being asked for by Xuetian.
> 
> In the above, what the input method might do is first let me correct
> 賣, letting me select 買. This should be indicated by somehow making me
> aware I'm poking at the first character. If it's smart enough, it'd
> later let me fine grain the last two characters as one "word", letting
> me select "鍵盤", and in this case, both the second and third character
> should be highlighted in some way.
> 
> Currently in GTK+ with I-bus under gnome-shell, this is currently done
> by guessing what character I'm correcting.
> 
> > 
> > I wonder if we are missing some on-the-wire state, rather than text
> > styling support per se. And given the can of worms styling brings in
> > (hard to know how to stand out from the IM side, a11y and color
> > blindness issues, ...), I would personally rather have a hint system
> > than let the IM meddle

Re: [wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Wed, 11 Apr 2018 11:26:22 -0700
Weng Xuetian <wen...@gmail.com> wrote:

> On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> > On Sun, 11 Mar 2018 20:30:14 +0100
> > 
> > Carlos Garnacho <carl...@gnome.org> wrote:  
> > > This new protocol description is a vast simplification over v2, highlights
> > > are:
> > > - All pre-edit text styling is gone, the protocol doesn't seem the place
> > > 
> > >   to convey UI state. Clients are in better knowledge of how to make the
> > >   pre-edit string distinguishable from regular text.  
> As an long-time input method developer and CJK user, I'd prefer to keep the 
> styling. In Chinese or Japanese, partially converted text are common and 
> styling is useful to help user to distinguish which text is currently being 
> converted. [1] But for the sake of in-app consistency, I'd say we don't need 
> that much capability about styling though. Among all input methods supported 
> by fcitx [2], only underline/highlight is being commonly used. Recently I 
> started to use some strike style in only one single input method though, it 
> can also be useful in certain cases.

I think this use case is covered. For indicating what's currently being 
changed, this protocol is using "preedit string". In GTK, the preedit text is 
displayed with an underline, making is always clear what the suggestion 
pertains to.
> 
> > > 
> > > - No input panel (OSK) state nor covered rectangle events. This leaks
> > > 
> > >   assumptions about the coordinate space of windows, and clients aren't
> > >   fully capable of handling all possible situations (eg. if the OSK fully
> > >   covers the surface). At the very least it could be split into a generic
> > >   protocol of its own, this version of the protocol simply doesn't get
> > >   into this business, compositors are still free to handle situations
> > >   where
> > >   the keyboard focus rectangle is covered by the input panel.
> > > 
> > > - Less state is to be kept on compositors. Clients must now reissue all
> > > 
> > >   applying IM state whenever the surface gains focus (or internal focus
> > >   changes), instead of state requests being independent from focus.
> > > 
> > > - No set_preferred_language request for clients, modern desktops have
> > > 
> > >   generally moved towards session-wide IM settings, it seems hard to
> > >   conciliate this piece of information flowing in both directions.
> > > 
> > > - There is no event to send keysyms. The handling ought to be by all means
> > > 
> > >   identical to wl_keyboard's, compositors might just use that interface.  
> Let input method itself to send any key event is somewhat an important 
> feature. Common use cases includes "sending backspace key via OSK", or 
> "simulating another keyboard layout". Fcitx (5, which is under developlment) 
> provides ability to use a keyboard layout without changing the system global 
> layout, which can be extremely helpful for users using multiple layout. For 
> example,  the hotkey key binding would keep the same while they can still 
> using the custom layout (e.g. position of ctrl + z is different under us/de).
> 
> I assume that you mean that it is replaced by creating sythatical key event  
> via compositor and sending them via wl_keyboard? I'm not so sure if that 
> works, especially when there is no real phyiscal keyboard.
> 
I read it the same way. At the same time, I also don't see a reason to 
duplicate the keyboard interface in another protocol - the compositor can tell 
the application that there's a regular (but virtual) keyboard connected and 
send events using the regular wl_keyboard protocol.

Cheers,
Dorota

> [1] https://i.imgur.com/MpibNVi.png
> [2] https://fcitx-im.org/
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: [wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Sun, 11 Mar 2018 20:30:14 +0100
Carlos Garnacho  wrote:

> This new protocol description is a vast simplification over v2, highlights
> are:
> - All pre-edit text styling is gone, the protocol doesn't seem the place
>   to convey UI state. Clients are in better knowledge of how to make the
>   pre-edit string distinguishable from regular text.
> - No input panel (OSK) state nor covered rectangle events. This leaks
>   assumptions about the coordinate space of windows, and clients aren't
>   fully capable of handling all possible situations (eg. if the OSK fully
>   covers the surface). At the very least it could be split into a generic
>   protocol of its own, this version of the protocol simply doesn't get
>   into this business, compositors are still free to handle situations where
>   the keyboard focus rectangle is covered by the input panel.
> - Less state is to be kept on compositors. Clients must now reissue all
>   applying IM state whenever the surface gains focus (or internal focus
>   changes), instead of state requests being independent from focus.
> - No set_preferred_language request for clients, modern desktops have
>   generally moved towards session-wide IM settings, it seems hard to
>   conciliate this piece of information flowing in both directions.
> - There is no event to send keysyms. The handling ought to be by all means
>   identical to wl_keyboard's, compositors might just use that interface.
> 
> Signed-off-by: Carlos Garnacho 
> ---
> 
> Hey,
> 
> Belatedly, here's my proposed v3 of the text-input protocol, a rename of
> what is implemented on gnome-shell/gtk+. It basically is a
> (over?)simplification compared to v2, the main difference besides the
> punted functionality is the simplified messaging flow, state is considered
> reset after enter/leave, or on .disable requests from the client, all
> new state must be submitted afterwards.
> 
> Some of the removed things are maybe debatable (eg. the keysym event,
> or language preference request/signal, although I don't see that working
> out of the box widely, highly toolkit specific at best). For stuff like
> the old input_panel_state request to do client-side UI magic to keep
> keyboard focus visible I'm personally more opinionated though :).
> 
> Comments?
> 
> Cheers,
>   Carlos

Hi,

this proposal sparked some interest on Purism side and led to brainstorming in 
the Sway project.

https://github.com/swaywm/wlroots/pull/776

We managed to implement the protocol and test it out with a simple demo. As a 
result, the original proposal changed shape a bit (attached), and both wlroots 
[0,1] and GTK [2] gained branches supporting the new version.

Speaking for Purism, we're interested in getting this text protocol finalized 
and support upstreamed into libraries. Comments very welcome.

Cheers,
Dorota

[0] https://github.com/swaywm/wlroots/pull/776
[1] rootston demo: 
https://code.puri.sm/dorota.czaplejewicz/wlroots/src/text_input_test
[2] https://code.puri.sm/dorota.czaplejewicz/gtk

---
 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v1.xml | 459 ++---
 2 files changed, 192 insertions(+), 268 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..86d7ca9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
diff --git a/unstable/text-input/text-input-unstable-v1.xml 
b/unstable/text-input/text-input-unstable-v1.xml
index 29a217e..f5d43e7 100644
--- a/unstable/text-input/text-input-unstable-v1.xml
+++ b/unstable/text-input/text-input-unstable-v1.xml
@@ -1,51 +1,68 @@
 
-
 
+
   
 Copyright © 2012, 2013 Intel Corporation
-
-Permission is hereby granted, free of charge, to any person obtaining a
-copy of this software and associated documentation files (the "Software"),
-to deal in the Software without restriction, including without limitation
-the rights to use, copy, modify, merge, publish, distribute, sublicense,
-and/or sell copies of the Software, and to permit persons to whom the
-Software is furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice (including the next
-paragraph) shall be included in all copies or substantial portions of the
-Software.
-

Re: [wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Sun, 11 Mar 2018 20:30:14 +0100
Carlos Garnacho  wrote:

> This new protocol description is a vast simplification over v2, highlights
> are:
> - All pre-edit text styling is gone, the protocol doesn't seem the place
>   to convey UI state. Clients are in better knowledge of how to make the
>   pre-edit string distinguishable from regular text.
> - No input panel (OSK) state nor covered rectangle events. This leaks
>   assumptions about the coordinate space of windows, and clients aren't
>   fully capable of handling all possible situations (eg. if the OSK fully
>   covers the surface). At the very least it could be split into a generic
>   protocol of its own, this version of the protocol simply doesn't get
>   into this business, compositors are still free to handle situations where
>   the keyboard focus rectangle is covered by the input panel.
> - Less state is to be kept on compositors. Clients must now reissue all
>   applying IM state whenever the surface gains focus (or internal focus
>   changes), instead of state requests being independent from focus.
> - No set_preferred_language request for clients, modern desktops have
>   generally moved towards session-wide IM settings, it seems hard to
>   conciliate this piece of information flowing in both directions.
> - There is no event to send keysyms. The handling ought to be by all means
>   identical to wl_keyboard's, compositors might just use that interface.
> 
> Signed-off-by: Carlos Garnacho 
> ---
> 
> Hey,
> 
> Belatedly, here's my proposed v3 of the text-input protocol, a rename of
> what is implemented on gnome-shell/gtk+. It basically is a
> (over?)simplification compared to v2, the main difference besides the
> punted functionality is the simplified messaging flow, state is considered
> reset after enter/leave, or on .disable requests from the client, all
> new state must be submitted afterwards.
> 
> Some of the removed things are maybe debatable (eg. the keysym event,
> or language preference request/signal, although I don't see that working
> out of the box widely, highly toolkit specific at best). For stuff like
> the old input_panel_state request to do client-side UI magic to keep
> keyboard focus visible I'm personally more opinionated though :).
> 
> Comments?
> 
> Cheers,
>   Carlos

...

> +  Focus moving throughout surfaces will result in the emission of
> +  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
> +  surface must perform zwp_text_input_v3.enable and
> +  zwp_text_input_v3.disable requests as the keyboard focus moves across
> +  editable and non-editable elements of the UI. Those two requests are 
> not
> +  expected to be paired with each other, the compositor must be able to
> +  handle consecutive series of the same request.
What does it mean if there are several consecutive "enable" events? Should the 
compositor treat the second and next as an implicit "disable" events? Or should 
the input method stay open, which makes some sense if the input method presents 
a popup?

...

> +
> +  
> +   Notification that this seat's text-input focus is on a certain 
> surface.
> +
> +   When the seat has the keyboard capability the text-input focus follows
> +   the keyboard focus.
> +  
> +  
> +  
> +
> +
> +
> +  
> +   Notification that this seat's text-input focus is no longer on
> +   a certain surface. The client should reset any preedit string 
> previously
> +   set.
> +
> +   The leave notification is sent before the enter notification
> +   for the new focus.
I read this to mean that there can be only one surface in the "entered" state 
at a time. What is the purpose of serial number in the enter and leave events 
if there's only one surface to keep track of?

Cheers,
Dorota


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