1. 28 Jan, 2023 3 commits
  2. 25 Jan, 2023 3 commits
    • Carlos Garnacho's avatar
      gtkapplication: Do not call gdk_display_notify_startup_complete() · 79e11bed
      Carlos Garnacho authored
      This should do nothing worthwhile anymore, the X11/Wayland GtkApplication
      implementations do already pass the startup ID from the platform_data
      via windowing specific APIs, and the application handling the request
      via show()/present() should trigger the activation request.
      
      (cherry-picked from commit 3526d8b2)
      79e11bed
    • Carlos Garnacho's avatar
      gtkwindow: Shuffle gdk_window_set_startup_id() calls · 2a470386
      Carlos Garnacho authored
      While this used to be tangential to windows showing or requesting
      focus, the xdg-activation Wayland protocol does merge both concepts
      together.
      
      But also, for a correct interaction with the compositor, the
      toolkit should ideally merge the activation request resulting from
      both into the same one, so that the gdk_window_focus() request
      replies to the startup token that started the application and
      correct focus-stealing prevention/etc happens, instead making up
      one just in time for the focus request.
      
      This kind of requires doing things in the right order, a show()
      request on the GtkWindow should activate any pending activation
      token on the toplevel, a present() request should additionally
      create a new token if there was none pending. And
      xdg_activation_v1_activate() should happen once on both.
      
      Shuffle the gdk_window_set_startup_id() calls so that this
      happens in the right order for Wayland, while making X11 happy
      too.
      
      (cherry-picked from commit e8adfa2a)
      2a470386
    • Carlos Garnacho's avatar
      gtkwindow: Minor refactor · a0679385
      Carlos Garnacho authored
      Move the handling of the startup ID to a separate function, since
      this will be called from several places.
      
      (cherry-picked from commit 6f01f846)
      a0679385
  3. 21 Jan, 2023 1 commit
  4. 13 Jan, 2023 1 commit
  5. 07 Jan, 2023 1 commit
  6. 12 Dec, 2022 1 commit
    • Ross Burton's avatar
      Use @basename@ in enumeration type templates · 8eb4e596
      Ross Burton authored
      The @filename@ directive will use the full path of the file being parsed
      for enumeration types; we should use @basename@, instead, as it improves
      the reproducibility of the build by using only the file name.
      
      Backport of 4040f765 from main.
      8eb4e596
  7. 08 Dec, 2022 2 commits
    • Guido Günther's avatar
      emojichooser: Actually disable the recent section · 900454e9
      Guido Günther authored
      The loop sets empty = FALSE when there are emojis but for that
      to work we need to initialize the value to TRUE initially.
      
      Fixes: 7928532b
      (cherry picked from commit 89c816a6)
      900454e9
    • Emmanuele Bassi's avatar
      build: Remove the Autotools build · 2b0a605c
      Emmanuele Bassi authored
      CI and downstream packagers have been using the Meson build for a while
      now, and we checked that it's idempotent to the Autotools build.
      
      Having two build systems in tree doesn't make maintaining and releasing
      GTK any easier, even if it's the stable/frozen branch.
      2b0a605c
  8. 06 Dec, 2022 6 commits
  9. 03 Dec, 2022 1 commit
  10. 30 Nov, 2022 1 commit
  11. 11 Nov, 2022 1 commit
    • hrdl's avatar
      Fixes incorrect grabbing behaviour causing subsequent rejection of input · 5c6d2c8e
      hrdl authored and hrdl's avatar hrdl committed
      mouse_location can be set to NULL in gtk_range_update_mouse_location(). This
      causes a match with stepper_?_gadget in gtk_range_multipress_gesture_pressed(),
      as both are NULL. This leads to a grab being added internally and as well, a
      critical error message, and a subsequent rejection of touch inputs. Returning
      early when mouse_location is NULL prevents this.
      
      Closes #4947
      5c6d2c8e
  12. 27 Oct, 2022 1 commit
  13. 26 Oct, 2022 1 commit
    • Luca Bacci's avatar
      GtkTooltip: Scale the cursor size on X11 · bbce00f3
      Luca Bacci authored
      GtkSettings/X11 takes the values as provided by
      XSettings. Unlike other backends, the values of
      XSettings are in physical size (that's because
      X11 doesn't support mixed-DPI setups anyway).
      
      Take that in account when retrieving the cursor
      size in gtk_tooltip_position ().
      
      Note that this discrepancy between the X11 and
      other backends has been fixed in GTK4.
      
      Fixes #5223
      bbce00f3
  14. 06 Oct, 2022 7 commits
    • Carlos Garnacho's avatar
      gtkimcontextwayland: Shuffle full resets after IM changes · 92813e52
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      Doing reset() on the text widgets after commit and delete_surrounding
      is still too eager for some IMs (e.g. those that expect being able
      to commit text while keeping a preedit buffer shown).
      
      However, reset() is more of a "synchronize state" action on Wayland,
      and it is still desirable to do that after changes that do come from
      the IM (e.g. requesting the new surrounding text and cursor/anchor
      positions). Notably here, the text_input protocol may still come up
      with a preedit string after this state synchronization happens.
      
      Shuffle the code so that the text widgets do not reset() the IM
      context after text is deleted or committed, but the Wayland IM does
      apply its practical effects after these actions happen. This keeps
      the Wayland IM fully up-to-date wrt text widget state, while not
      altering the ::commit and ::delete-surrounding-text behavior for
      other IM context implementations.
      92813e52
    • Carlos Garnacho's avatar
      gtktextview: Also reset IM context after IM surrounding text deletion · a88e8483
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      When the IM commands the GtkText to delete text, the cursor position
      would change, and so would the surrounding text. Reset the IM context
      so that these updates are properly picked up by the IM.
      
      Fixes backspace	key behavior in	the GNOME Shell OSK, since that	relies
      on the surrounding text	being properly updated for the next iteration.
      a88e8483
    • Carlos Garnacho's avatar
      gtkentry: Also reset IM context after IM surrounding text deletion · 018083fa
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      When the IM commands the GtkText to delete text, the cursor position
      would change, and so would the surrounding text. Reset the IM context
      so that these updates are properly picked up by the IM.
      
      Fixes backspace key behavior in the GNOME Shell OSK, since that relies
      on the surrounding text being properly updated for the next iteration.
      018083fa
    • Carlos Garnacho's avatar
      gtkentry: Avoid early IM reset on updates · fa6aca29
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      Resetting the IM on IM updates is too eager and indeed the simple
      IM context doesn't like that this happens in the middle of dead
      key handling.
      
      We however want to reset the IM after actual text buffer changes
      (say, a committed string) moved the cursor position, altered the
      surrounding text, etc. So that the IM implementation does know to
      update its state.
      
      Since there is going to be an actual IM reset anyways, it does
      no longer make sense to try to preserve the old priv->need_im_reset
      status during commit handling.
      fa6aca29
    • Carlos Garnacho's avatar
      gtkentry: Avoid early IM reset on updates · 7b1f9a3b
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      Resetting the IM on IM updates is too eager and indeed the simple
      IM context doesn't like that this happens in the middle of dead
      key handling.
      
      We however want to reset the IM after actual text buffer changes
      (say, a committed string) moved the cursor position, altered the
      surrounding text, etc. So that the IM implementation does know to
      update its state.
      7b1f9a3b
    • Carlos Garnacho's avatar
      gtkentry: Shuffle the places doing IM reset · b0c4196f
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      During entry widget manipulation (inserting or deleting text via keyboard)
      the IM context is reset somewhat early, before the actual change took place.
      This makes IM lag behind in terms of surrounding text and cursor position.
      
      Shuffle these IM reset calls so that they happen after the changes, and
      ensure that the IM is actually reset, since that is currently toggled on
      a pretty narrow set of circumstances.
      b0c4196f
    • Carlos Garnacho's avatar
      gtktextview: Shuffle the places doing IM reset · 0a8b0025
      Carlos Garnacho authored and msizanoen1's avatar msizanoen1 committed
      During text widget manipulation (inserting or deleting text via keyboard)
      the IM context is reset somewhat early, before the actual change took place.
      This makes IM lag behind in terms of surrounding text and cursor position.
      
      Shuffle these IM reset calls so that they happen after the changes, and
      ensure that the IM is actually reset, since that is currently toggled on
      a pretty narrow set of circumstances.
      
      Also, fix a bug during GtkEventControllerKey::im-update where the condition
      on cursor position editability to reset the IM context was inverted.
      0a8b0025
  15. 30 Sep, 2022 1 commit
    • Jonas Ådahl's avatar
      wayland: Add support for gtk_surface1_titlebar_gesture() · 45ba6e93
      Jonas Ådahl authored
      This adds a private GDK API that GTK calls using GDK_PRIVATE_CALL(). It
      is more or less a copy of the GdkSurface::titlebar_gesture() API, and
      achieves the same. If the backend or compositor doesn't support titlebar
      gestures, the existing path is used as a fallback.
      45ba6e93
  16. 13 Sep, 2022 1 commit
  17. 21 Aug, 2022 1 commit
    • Nelson Ben's avatar
      Fix open location entry when pressing '~' · 573636d8
      Nelson Ben authored
      Recent changes in GTK default input method
      makes ~ char to start as dead key, that's
      why filechooser stopped detecting it for the
      keybinding to open location entry.
      
      We also make sure '~' appears in the location
      entry (instead of being emtpy).
      
      Fixes #4911 for GTK3
      573636d8
  18. 16 Aug, 2022 1 commit
  19. 15 Aug, 2022 2 commits
    • Rastersoft's avatar
      Remove unneeded unblock · 02ea88bb
      Rastersoft authored
      When a signal handler is disconnected, it doesn't matter if it
      was blocked or not, so there's no need to unlock it before
      disconnection.
      02ea88bb
    • Rastersoft's avatar
      Unblock signal on update_relative_to in Gtk.Popover · c9a3b427
      Rastersoft authored
      When a Gtk.Popover loses the focus, it blocks the grab_notify
      signal from the associated widget, and it unblocks it when it
      regains the focus. To know whether the signal is or not blocked,
      it uses the priv->grab_notify_blocked flag.
      
      On the other hand, when the method update_relative_to() is
      called, all the signals connected to the old associated widget
      are disconnected, and connected to the new widget.
      
      Unfortunately, the priv->grab_notify_blocked flag isn't updated,
      which means that if update_relative_to() is called while the
      Gtk.Popover doesn't have the focus (for example, because the
      user switched into another application), when the focus is
      regained, the code in window_focus_in() will see that
      priv->grab_notify_blocked is TRUE and will unblock the handler;
      but that handler wasn't blocked because the one that was blocked
      was disconnected when update_relative_to() was called. This
      shows a WARNING in the console:
      
      GLib-GObject-WARNING **: ../../../gobject/gsignal.c:2692: handler '5146' of instance '0x556912f84f40' is not blocked
      
      This patch fixes this.
      
      Fix #4777
      c9a3b427
  20. 20 Jul, 2022 1 commit
  21. 19 Jul, 2022 1 commit
  22. 13 Jul, 2022 1 commit
    • swilmet's avatar
      docs: improve doc of gtk_style_context_get() · fea466c1
      swilmet authored
      When using this function in GtkSourceView (for GTK 3), there was a
      mistake for retrieving a GdkRGBA value.
      
      So, better document the function to avoid further mistakes.
      fea466c1
  23. 24 Jun, 2022 1 commit