1. 23 Jan, 2019 5 commits
    • Carlos Garnacho's avatar
      gdk/wayland: Set a startup notification · bff46d86
      Carlos Garnacho authored
      And notify the shell about it. This is done through the
      gtk_shell1.notify_launch request added in gtk-shell v3. All the plumbing
      on the way to the activated application is already in place to transfer
      the startup ID, so the other side just has to reply with
      gtk_surface1.request_focus.
      
      Closes: GNOME/gtk#624
      bff46d86
    • Carlos Garnacho's avatar
      gdk/wayland: Implement gdk_window_present() · ed9db5a1
      Carlos Garnacho authored
      This uses the gtk_surface1.request_focus request added in gtk-shell v3,
      the given startup ID may be used by the compositor in order to determine
      when was the request started, and whether user input happened in between.
      
      Closes: #624
      ed9db5a1
    • Carlos Garnacho's avatar
      wayland/protocol: Update gtk-shell protocol to v3 · 45d6c009
      Carlos Garnacho authored
      This version has 2 new requests:
      - gtk_shell1.notify_launch notifies the compositor that the requesting
        client shall launch another application. The given ID is expected to
        be unique.
      - gtk_surface1.request_focus notifies the compositor that a surface
        requests focus due to it being activated. The given ID is passed to
        this process through undetermined means, if it corresponds with a
        current startup ID and there was no user interaction in between the
        surface will be focused, otherwise it will demand attention.
      45d6c009
    • Emmanuele Bassi's avatar
      Merge branch 'wip/iainl/pointer-type-casts-3-24' into 'gtk-3-24' · 2db6dbd1
      Emmanuele Bassi authored
      Fix -Wincompatible-pointer-types warnings
      
      See merge request !523
      2db6dbd1
    • Iain Lane's avatar
      Fix -Wincompatible-pointer-types warnings · 882c81da
      Iain Lane authored
      882c81da
  2. 21 Jan, 2019 4 commits
  3. 20 Jan, 2019 2 commits
  4. 19 Jan, 2019 1 commit
  5. 18 Jan, 2019 6 commits
  6. 17 Jan, 2019 4 commits
    • Jonas Ådahl's avatar
      menu: Adapt scroll offset if arrow is shown · c35878ec
      Jonas Ådahl authored
      When a popup is placed using move_to_rect(), it'll get feedback about
      the position and size it got assigned. We use this feedback to update
      the scroll offset, but while doing so, if the visibility of the arrow
      changed, we didn't adapt the offset accordingly.
      
      Fix this by offsetting the provided offset by the height of the arrow,
      if it was made visible as a side effect of the scroll offset change
      triggered by the feedback.
      
      Related: mutter#105
      Closes: #1463
      c35878ec
    • Jonas Ådahl's avatar
      menu: Force resize when remapping · 3e586a82
      Jonas Ådahl authored
      A menu will be clamped to the work area as a side effect of the
      move_to_rect() logic if the resize anchor flags was set. For it to work
      a second time, the initial size needs to be the actual menu size before
      being clamped again. Achieve this by forcing a size recalculation before
      showing the menu.
      3e586a82
    • Jonas Ådahl's avatar
      menu: Don't constrain initial menu size · 00486efd
      Jonas Ådahl authored
      Don't constrain the initial menu size by the work area of some monitor;
      instead let the move_to_rect() logic in the backend do the constraining.
      This fixes two things:
      
      1) The anchor delta provided to the backend will not be invalid. The
      delta is calculated by looking at the active menu item, calculating the
      offset given that, but since we clamped the window size before showing
      the window, the delta became invalid. This caused visible issues when
      the delta was large enough to make the initially calculated popup window
      geometry to be placed outside the geometry of the parent window, which
      is a violation of the Wayland protocol.
      
      2) The scroll offset to be correct when receiving the positioning
      feedback. While the scroll offset was based on the pre-clamped window
      size, the feedback, which was used to calculate the new offset, was not,
      causing the scroll offset to be clamped as well.
      00486efd
    • Jonas Ådahl's avatar
      wayland/window: Don't remap when handling xdg_popu.configure · 66ee4dea
      Jonas Ådahl authored
      If the size was constrained by the xdg_positioner mechanisms, we handle
      the resize by resizing the popup window. What we shouldn't do is
      hide/show the popup window so avoid that.
      66ee4dea
  7. 16 Jan, 2019 4 commits
  8. 15 Jan, 2019 4 commits
  9. 14 Jan, 2019 5 commits
  10. 12 Jan, 2019 1 commit
  11. 11 Jan, 2019 3 commits
  12. 10 Jan, 2019 1 commit