Skip to content
  1. Dec 06, 2021
    • Dorota Czaplejewicz (Purism)'s avatar
      text-input: Add on_screen_input_provided hint · df315b11
      Dorota Czaplejewicz (Purism) authored and Simon Ser's avatar Simon Ser committed 
      The new hint is meant to indicate that the text input already provides an on-screen means to enter data, and that using the system provided input method may not be needed.

It should be used when the client presents the user with a custom on-screen 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 not 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: default avatarDorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
      df315b11
  3. Mar 22, 2021
  5. Jun 30, 2020
    • Peng Wu's avatar
      text-input: Add preedit_commit_mode event for mouse click event · 353ed023
      Peng Wu authored 
      IBus update_preedit_string_with_mode feature send the preedit text and
the commit mode to the input method module, use preedit_commit_mode event
to send the commit mode together with the preeedit text.

IBusInputContext specify how input context interact with the keyboard,
but sometimes mouse click also interacts with the input context, too.

For Firefox, if some preedit text is visible with ibus-hangul input method;
after mouse click, the preedit will be committed twice.

To fix this issue, ibus-hangul can send preedit text and commit mode
together; after mouse click, the preedit is handled directly in
input method module of Firefox, and the preedit is committed in
the current text widget.

For detailed analysis, please read the merge request comments.
URL: !30
      353ed023
  7. Jan 22, 2020
  9. Dec 18, 2019
    • Simon Ser's avatar
      Convert plaintext documents to Markdown · 733de762
      Simon Ser authored 
      

This converts GOVERNANCE, MEMBERS and README to Markdown documents.
These are only cosmetic changes, the actual contents and wording have
been retained.

GitLab pretty-prints Markdown and adds anchors. We can now add links
from one document to another.

Unfortunately GOVERNANCE lettered lists have been converted to numbered
lists, because Markdown doesn't support the former.

Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
Closes: #3
      733de762
  11. Nov 21, 2019
  13. Nov 20, 2019
  15. Sep 06, 2019
  17. Jul 25, 2019
  19. Jul 17, 2019
    • Jan-Marek Glogowski's avatar
      xdg-shell: use case to change the app ID at runtime · e0d6ad1d
      Jan-Marek Glogowski authored and Jonas Ådahl's avatar Jonas Ådahl committed 
      

LibreOffice is one big binary with explicit brandings for different
application modules. This is represented in X11 by a different
WM_CLASS setting for a window. The WM_CLASS is changed based on the
loaded document at runtime. As a result LibreOffice already offers
multiple desktop files with different icons, StartupWMClass
entries and application names.

This amendment of the set_app_id request just explicitly specifies
the use case to change a surfaces' app ID at runtime, so a compositor
implementor is made aware of it. Just as the WM_CLASS, a change of
the app ID should result in an update of the propertes of a surface
depending on the app ID, like the window icon specified in the
desktop file or a re-grouping of the surfaces in a task manager.

Signed-off-by: default avatarJan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: default avatarJonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      e0d6ad1d
    • Simon Ser's avatar
      pointer-gestures: add a release request · b9d427db
      Simon Ser authored and Jonas Ådahl's avatar Jonas Ådahl committed 
      

This allows clients to destroy a gesture object before they disconnect.

The request isn't named "destroy", as this would conflict with
wayland-scanner's auto-generated destructor (which just destroys the
client-side object without sending any request).

Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
Reviewed-by: default avatarJonas Ådahl <jadahl@gmail.com>
      b9d427db
    • Simon Ser's avatar
      xdg-output: deprecate the xdg_output.done event · 962dd535
      Simon Ser authored and Jonas Ådahl's avatar Jonas Ådahl committed 
      This commit makes it so a wl_output.done event is guaranteed to be sent with a
xdg_output.done event.

This protocol change has been discussed in a recent xorg-devel discussions [1].

First let's recap why a change is needed: Xwayland listens to both wl_output and
xdg_output changes. When an output's properties change, Xwayland expects to
receive both a wl_output.done event and an xdg_output.done event. If that's not
the case, Xwayland doesn't update its state (so old state is still exposed to
X11 clients).

Most of the time, both objects will be updated at the same time (e.g. the
current mode is changed, so both wl_output.mode and xdg_output.logical_size are
sent) so this won't be an issue. However in some situations only one of
wl_output or xdg_output changes. For instance:

- The mode is changed at the same time as the scale, resulting in the same
  logical_size.
- The compositor doesn't expose the outputs' position via wl_output, so whenever
  the position changes only xdg_output is updated.

Both KDE [2] and wlroots [3] have experienced this issue.

For this reason, I'd like to update the xdg-output protocol to make it mandatory
to always send a wl_output.done event after xdg_output changes. This effectively
makes wl_output.done atomically apply all output state (including the state of
add-on objects like xdg_output). This approach is pretty similar to
wl_surface.commit: this request will atomically apply surface state including
the state of e.g. the xdg_surface object tied to the wl_surface.

To update the protocol to reflect this new requirement we can either:

- **Bump xdg_output version**. The current protocol doesn't specify that
  wl_output.done must be sent, adding this new requirement would be a breaking
  change. We need to fix Xwayland for the current xdg_output version (maybe make
  it non-atomic for the current version, atomic for the new one?). Should we
  deprecate xdg_output.done in the new version?
- **Don't bump xdg_output version**. This clarifies what is expected in practice
  by Xwayland, a major xdg_output consumer, and what is currently implemented by
  all compositors.

There's one issue with the "don't bump" approach: indeed in practice compositors
always send wl_output.done and xdg_output.done in pairs, however the ordering
between those two events is not guaranteed. This means some compositors might
send this sequence:

    wl_output.geometry(…)
    wl_output.done()
    xdg_output.logical_position(…)
    xdg_output.done()

In this case the wl_output.done event fails to atomically apply the xdg_output
state.

For this reason, I think bumping the version is a better approach.

This commit also deprecates xdg_output.done, which doesn't have any purpose
anymore.

[1]: https://lists.x.org/archives/xorg-devel/2019-April/058148.html
[2]: https://phabricator.kde.org/D19253
[3]: https://github.com/swaywm/sway/issues/4064



Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
Reviewed-by: default avatarJonas Ådahl <jadahl@gmail.com>
      962dd535
  21. May 22, 2019
  23. May 02, 2019
  25. Jan 17, 2019
  27. Dec 14, 2018
  29. Nov 12, 2018
  31. Jul 31, 2018
  33. Jul 30, 2018
  35. Jul 16, 2018
  37. Jul 04, 2018
  39. Jun 18, 2018
  41. May 03, 2018