1. 13 Sep, 2019 3 commits
  2. 22 Aug, 2019 1 commit
  3. 18 Aug, 2019 1 commit
    • Alberts Muktupāvels's avatar
      display: remove benign warning for older X clients · 4c8927e5
      Alberts Muktupāvels authored
      The default configuration of libinput-gestures utility invokes wmctrl to
      switch between desktops. It uses wmctrl because this works on both Xorg
      and Wayland (via XWayland). Unfortunately, this generates the following
      warning message every time, in both Xorg and Wayland desktops:
      
      "Received a NET_CURRENT_DESKTOP message from a broken (outdated) client
      who sent a 0 timestamp"
      
      The desktop switch still works fine. The tiny code change here removes
      this specific warning because, as the prefacing code comment originally
      said and still says, older clients can validly pass a 0 time value so
      why complain about that?
      
      I also refactored the "if (workspace)" code slightly to avoid the double
      test of the workspace value.
      
      Based on mutter commit:
      mutter@e9cc220c
      4c8927e5
  4. 14 Aug, 2019 1 commit
    • Alberts Muktupāvels's avatar
      menu: change event parameter back to timestamp · af0bbded
      Alberts Muktupāvels authored
      Commit 37fa0d19 replaced gtk_menu_popup with gtk_menu_popup_at_rect
      to avoid deprecated warning making it more complicated then needed.
      
      gtk_menu_popup_at_rect requires two parameters that are not always
      available. For example we don't have GdkWindow for CSD windows. And
      next commit will popup menu in response of ClientMessage event where
      we don't have any info about key and/or button press events.
      
      Simplify code by creating fake event in menu.c with minimal data
      needed for gtk_menu_popup_at_rect. GdkEvent is used to get GdkDevice,
      button and time. For GdkWindow we can use root window.
      af0bbded
  5. 13 Aug, 2019 1 commit
  6. 29 Nov, 2018 1 commit
  7. 09 Sep, 2018 1 commit
  8. 08 Sep, 2018 2 commits
    • Owen W. Taylor's avatar
      fix problems with focus tracking · 19c5732a
      Owen W. Taylor authored
      When a client spontaneously focuses their window, perhaps in response
      to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial.
      Updating display->focus_serial in response to FocusOut then was causing
      us to ignore FocusIn and think that the focus was not on any window.
      
      We need to distinguish this spontaneous case from the case where we
      set the focus ourselves - when we set the focus ourselves, we're careful
      to combine the SetFocus with a property change so that we know definitively
      what focus events we have already accounted for.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=720558
      19c5732a
    • Alberts Muktupāvels's avatar
      display: ensure that we ignore our own focus events for focus predictions · 66a4cb4a
      Alberts Muktupāvels authored
      When we set the input focus, we first set the predicted window,
      and then try to process focus events. But as FocusOut on the
      existing window comes before FocusIn on the new window, we'll
      see the focus out on the old window and think the focus is going
      to nothing, which makes metacity think the prediction failed.
      
      Fix this by making sure that we ignore focus window changes of our
      own cause when updating the focus window field, by ignoring all
      focus events that have a serial the same as the focus request or
      lower. Note that if metacity doens't make any requests after the
      focus request, this could be racy, as another client could steal
      the focus, but metacity would ignore it as the serial was the same.
      Bump the serial by making a dummy ChangeProperty request to a
      metactiy-controlled window in this case.
      
      Based on mutter commit:
      mutter@7fdfbad6
      66a4cb4a
  9. 02 Sep, 2018 1 commit
  10. 16 Jun, 2018 2 commits
  11. 11 Mar, 2018 1 commit
  12. 21 Jul, 2017 1 commit
    • Owen W. Taylor's avatar
      Fix crash when struts change during grab operation · 1031d4df
      Owen W. Taylor authored
      Since meta_workspace_invalidate_work_area() frees the edges
      workspace->screen_edges and workspace->monitor_edges, we must clean up
      our cached edge resistance data when the invalidate_work_area() is
      called on the active workspace, or when the workspace changes.
      
      Make the computation of the edge resistance data lazy so that it
      will be recomputed the next time we try to access it.
      meta_display_compute_resistance_and_snapping_edges() is made
      private to edge-resistance.c
      
      Invaliding the data when active workspace changes also will improve
      correctness for edge resistance when the current workspace changes
      during a grab operation. (Even with this fix we still don't try to
      handle window positions changing during a grab operation; that can't
      cause a crash since, unlike screen and monitor edges, the window edges
      are freshly allocated, it will just cause slight oddness in that
      corner case.)
      
      Root cause tracked down due to much effort by Jon Nettleton.
      https://bugzilla.gnome.org/show_bug.cgi?id=608800 (Mutter)
      https://bugzilla.gnome.org/show_bug.cgi?id=603632 (Metacity)
      1031d4df
  13. 04 Jul, 2017 1 commit
  14. 19 Jun, 2017 2 commits
  15. 25 Apr, 2017 1 commit
  16. 20 Apr, 2017 2 commits
  17. 01 Apr, 2017 1 commit
  18. 18 Mar, 2017 2 commits
    • Jasper St. Pierre's avatar
      window: remove code for static gravity resizes · 12626b0b
      Jasper St. Pierre authored
      It was never turned on for all the years it's been there.
      12626b0b
    • Daniel Drake's avatar
      reduce server grabs during window creation · 73194072
      Daniel Drake authored
      Remove some obvious server grabs from the window creation codepath,
      also ones that are taken at startup.
      
      During startup, there is no need to grab: we install the event handlers
      before querying for the already-existing windows, so there is no danger
      that we will 'lose' some window. We might try to create a window twice
      (if it comes back in the original query and then we get an event for it)
      but the code is already protected against such conditions.
      
      When windows are created later, we also do not need grabs, we just need
      appropriate error checking as the window may be destroyed at any time
      (or it may have already been destroyed).
      
      The stack tracker is unaffected here - as it listens to CreateNotify and
      DestroyNotify events and responds directly, the internal stack
      representation will always be consistent even if the window goes away while
      we are processing MapRequest or similar.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=721345
      73194072
  19. 16 Mar, 2017 1 commit
  20. 12 Mar, 2017 5 commits
  21. 10 Mar, 2017 9 commits