1. 09 Aug, 2022 1 commit
    • Mike Blumenkrantz's avatar
      staging: Add xdg-session-management protocol · 45a767e3
      Mike Blumenkrantz authored and Jonas Ådahl's avatar Jonas Ådahl committed
      
      
      For a variety of cases it's desirable to have a method for negotiating
      the restoration of previously-used states for a client's windows. This
      helps for e.g., a compositor/client crashing (definitely not due to
      bugs) or a backgrounded client deciding to temporarily destroy its
      surfaces in order to conserve resources.
      
      This protocol adds a method for managing such negotiation and is loosely
      based on the Enlightenment "session recovery" protocol which has been
      implemented and functional for roughly two years.
      
      Signed-off-by: Mike Blumenkrantz's avatarMike Blumenkrantz <michael.blumenkrantz@gmail.com>
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      45a767e3
  2. 07 Jul, 2022 3 commits
  3. 27 Jun, 2022 1 commit
  4. 04 Jun, 2022 1 commit
  5. 01 Jun, 2022 2 commits
  6. 11 Apr, 2022 1 commit
    • Kenny Levinsen's avatar
      viewport: Remove mention of wl_surface.attach x/y · 2398378c
      Kenny Levinsen authored and Simon Ser's avatar Simon Ser committed
      
      
      This paragraph contains an incomplete definition of how
      wl_surface.attach x/y arguments functions, and makes no reference to the
      similar wl_surface.offset.
      
      The paragraph states that there is no effect on the behavior of
      wl_surface.attach. Rather than elaborating on its definition and adding
      wl_surface.offset, remove the paragraph and let their definition be up
      to wl_surface itself.
      
      Signed-off-by: Kenny Levinsen's avatarKenny Levinsen <kl@kl.wtf>
      2398378c
  7. 06 Apr, 2022 1 commit
  8. 29 Mar, 2022 2 commits
    • Simon Ser's avatar
      members: add Simon Zeni for wlroots/Sway · db85bc14
      Simon Ser authored
      
      
      Simon Zeni has stepped up as a member for wlroots/Sway.
      
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      db85bc14
    • Carlos Garnacho's avatar
      text-input: Reword the interpretation of serials to be more specific · 37fa0f4a
      Carlos Garnacho authored and Jonas Ådahl's avatar Jonas Ådahl committed
      Here's a long story. The serial is formerly described as:
      
        When the client receives a done event with a serial different than the
        number of past commit requests, it must proceed as normal, except it
        should not change the current state of the zwp_text_input_v3 object.
      
      Upon first reading it might be obvious to interpret "proceed as normal"
      as "apply the changes made by the done event" and "not change the current
      state" as "do not make requests on it until serial matches with
      expectations again". This would turn the serial into a flow control
      mechanism to avoid pushing state changes that we know might be stale.
      
      GTK however makes another outlandish interpretation, where "proceed as
      normal" means "ignore the changes made by the done event" and "not change
      state of the zwp_text_input_v3 object" is "not change client state". This
      makes the serial a full synchronization mechanism where IM commands that
      are deemed out of sync are symply ignored.
      
      This would seem a misinterpretation of the protocol, and I proceeded to
      change the behavior in GTK. Then some deja vu feeling struck me and I found
      https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/384#note_344864
      
      , this
      change was already done and discussed in the past. Not just that, it is
      the right interpretation.
      
      However, there's some notable disadvantages, there's 2 easy ways to
      completely break the synchronization between compositor and client:
      Having the IM push new state too often (i.e. multiple consecutive
      .done events), or having the client .commit too often. If any of both
      peers gets ahead of the other slightly, the end result is ignored input.
      More specifically, IBus has no provision for this kind of transactional
      behavior (probably other IMs too), so implementing "emit .done once after
      a set of changes" is not quite possible.
      
      Arguably, ignoring IM input is also a bad thing. IMs expect all commands
      to be respected and applied in order and might even rely on that in
      their own internal state. Since only state changes are flushed on .done
      events, partially ignoring IM commands will end up with the client IM state
      out of sync.
      
      The usecase described at that GNOME gitlab comment (edited text changes
      happening in parallel to IM interaction) trades the handling of an
      inherently racy corner case with the worst kind of mishandling (ignoring
      user input) if IM/client don't perfectly sync up.
      
      On the other hand, the flow control approach is more lenient with IMs and
      clients "getting a step ahead", and more importantly does not punish the
      user whenever either IM/client happens to do that. Double down on this
      (already intuitively correct) description, and specify further what it
      implies.
      
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      37fa0f4a
  9. 25 Mar, 2022 1 commit
  10. 25 Feb, 2022 1 commit
  11. 11 Jun, 2020 3 commits
  12. 25 Feb, 2022 1 commit
  13. 23 Feb, 2022 2 commits
  14. 26 Jan, 2022 1 commit
  15. 19 Jan, 2022 2 commits
  16. 17 Jan, 2022 1 commit
  17. 28 Dec, 2021 1 commit
    • Isaac Freund's avatar
      ext-session-lock-v1: new protocol · a52b8f02
      Isaac Freund authored
      
      
      This protocol allows for a privileged Wayland client to lock the
      session and display arbitrary graphics while the session is locked.
      
      The client is responsible for performing authentication and informing
      the compositor when the session should be unlocked. If the client
      dies while the session is locked the session remains locked, possibly
      permanently depending on compositor policy.
      
      Signed-off-by: Isaac Freund's avatarIsaac Freund <mail@isaacfreund.com>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      a52b8f02
  18. 24 Nov, 2021 1 commit
  19. 23 Nov, 2021 3 commits
  20. 17 Nov, 2021 1 commit
  21. 10 Nov, 2021 1 commit
  22. 09 Nov, 2021 1 commit
  23. 13 Oct, 2021 1 commit
  24. 11 Oct, 2021 1 commit
  25. 04 Oct, 2021 1 commit
    • Alexander Richardson's avatar
      tests: allow cross-compiling the tests · 78f654ed
      Alexander Richardson authored
      
      
      I am trying to cross-compile from macOS for FreeBSD and this is currently
      failing since the tests attempt to build a native binary that links
      against the wayland-client and wayland-server libraries for the FreeBSD
      system. I believe we should be building them for the target system and
      not the current host (especially since there is no way to build
      wayland-client and wayland-server for macOS, but I do want to check that
      the files build correctly for FreeBSD).
      
      Signed-off-by: Alexander Richardson's avatarAlex Richardson <Alexander.Richardson@cl.cam.ac.uk>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      78f654ed
  26. 19 Sep, 2021 1 commit
  27. 15 Sep, 2021 1 commit
  28. 13 Sep, 2021 1 commit
    • Peter Hutterer's avatar
      pointer-gestures: add hold gestures · 824cea61
      Peter Hutterer authored and Simon Ser's avatar Simon Ser committed
      
      
      Hold gestures merely denote "there are fingers on the touchpad but they are
      not moving". As touchpad touches are generally fully abstracted, a client
      cannot currently know when a user is interacting with the touchpad without
      moving - no motion events will be sent in this case.
      
      The two use-cases here are:
      - hold-to-interact: where a hold gesture is active for some time
        a menu could pop up, or some object is selected, etc.
      - hold-to-cancel: where e.g. kinetic scrolling is currently active, the start
        of a hold gesture can be used to stop the scroll
      
      Since hold gestures by definition do not have movement, there is no need for
      an "update" stage in the gesture.
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      824cea61
  29. 09 Sep, 2021 1 commit
  30. 01 Sep, 2021 1 commit