1. 19 Dec, 2019 1 commit
  2. 12 Dec, 2019 1 commit
  3. 16 Nov, 2019 2 commits
  4. 11 Oct, 2019 1 commit
  5. 06 Sep, 2019 1 commit
  6. 22 Jun, 2019 1 commit
    • John Ralls's avatar
      Hide Objective-C from outside GdkQuartz. · ef72fe75
      John Ralls authored
      Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1737
      Don't export any functions taking or returning MacOS types in
      gdkquartz.h, gdkprivate-quartz.h, or any header that either includes.
      The GdkQuartz internal functions are moved to a new header
      gdkinternal-quartz.h, the functions used by quartz-specific
      Gtk files are moved to another new header gdkquartz-gtk-only.h, and
      the key and event enums to a new header gdkkeys-quartz.h.
  7. 25 Apr, 2019 1 commit
  8. 15 Apr, 2019 1 commit
  9. 11 Apr, 2019 6 commits
  10. 08 Feb, 2019 1 commit
  11. 31 Jan, 2019 1 commit
    • Suyuan Chang's avatar
      macOS: Fix bug that entry cannot press and hold a key to input accented character. · cfad43b8
      Suyuan Chang authored
      There're two issues in GdkQuartzView's NSTextInputClient implementation
      causes this bug.
      1. The -(NSRange)selectedRange should not return [NSNotFound, 0] if
         there's no selection. The accented character window will not show
         if returned NSRange's location is NSNotFound. Instead of that, the
         NSRange's location should be the caret position in the text input
      2. The accented character window will invoke
         -(void)insertText:replacementRange: with non-empty replacement
         range, to replace non-accented character with accented character
         after user select it from accented character window. This case is
         not implemented in original code. Here I use another gobject data
         to pass the information to input module and convert it into
         'delete-surrounding' event.
      Besides these, there's another bug cause gtk_im_context_filter_keypress()
      return wrong value while user press and hold a key. When user press
      and hold a key, the accented character window will consume the
      repeating key down event. Is this case, gtk_im_context_filter_keypress()
      should return TRUE, indicate the key press is filtered by input
      method module. But it will return FALSE because
      gtk_im_context_filter_keypress() assume that every key press event
      will generate some text from input method module.
      Fixes #1618
  12. 24 Jan, 2019 1 commit
  13. 21 Jan, 2019 1 commit
  14. 14 Jan, 2019 1 commit
    • John Ralls's avatar
      [IMQuartz] Get the GdkWindow from the NSKeyEvent. · ee0e59e6
      John Ralls authored
      Instead of from the IMContextQuartz's client window because the former
      is the event window where the text will be inserted. In some cases
      they're different and the text may be discarded (because the client
      window isn't editable) or misplaced.
      Fixes Bug 707945.
  15. 06 Dec, 2018 1 commit
  16. 30 Oct, 2018 1 commit
    • Carlos Garnacho's avatar
      imwayland: Plug leaks · 336f3827
      Carlos Garnacho authored
      The various strings (pending/current preedit, surrounding, and commit
      buffer) are being leaked in the case of GtkIMContext destruction.
  17. 17 Oct, 2018 1 commit
  18. 16 Oct, 2018 2 commits
  19. 08 Oct, 2018 1 commit
    • Chun-wei Fan's avatar
      gtkimcontextime.c: Fix Korean input · 1ece5562
      Chun-wei Fan authored
      Commit c255ba68 inadvertently introduced a regression that broke Korean
      text input because the changes there resulted that only the last input
      string that we have from ImmGetCompositionStringW() for each time the
      commit signal is emitted is kept, and also as a result the final Korean
      character that is input by hitting space is also lost as a result, as we
      didn't check for whether we are done with preediting.
      Fix these issues by doing the following when we receive the
      WM_IME_COMPOSITION message with GCS_RESULTSTR from Windows:
      -Do not emit the commit signal during WM_IME_ENDCOMPOSITION, and...
      -Emit the commit signal anyways, as we did before, c255ba68, however...
      -We still save up the string to commit, because we need to re-compute
       the cursor position when we do ->get_preedit_string(), which needs to
       take the GCS_RESULTSTR string we get from WM_IME_COMPOSITION into
       account as well, so that we avoid getting the Pango criticals that
       occur during Chinese (and most likely Japanese) input as the cursor
       position is out-of-range.
      Fixes issue #1350.
  20. 28 Sep, 2018 1 commit
  21. 14 Sep, 2018 1 commit
  22. 11 Sep, 2018 2 commits
  23. 07 Sep, 2018 1 commit
  24. 23 Aug, 2018 1 commit
  25. 30 Jul, 2018 1 commit
  26. 28 Jul, 2018 1 commit
    • Christian Hergert's avatar
      imwayland: fix potential leak of attr list · 508e0648
      Christian Hergert authored
      This fixes a potential leak of a PangoAttrList that is set when chaining
      up to the parent get_preedit_string(). We check to see if the attr list
      was created and reuse it instead of leaking the previous value.
  27. 20 Jul, 2018 1 commit
  28. 24 Jun, 2018 1 commit
    • Michael Catanzaro's avatar
      imwayland: Fix a small leak · efb934c0
      Michael Catanzaro authored
      If the parent get_preedit_string implementation returns a nonnull
      zero-length string, then we ignore it, which is almost fine. We have to
      free it, though.
      Fixes #1174
  29. 22 Jun, 2018 1 commit
  30. 04 Apr, 2018 1 commit
  31. 28 Mar, 2018 1 commit
  32. 20 Mar, 2018 1 commit
    • Carlos Garnacho's avatar
      imwayland: Avoid TOGGLE_INPUT_PANEL requests if there's no focus · 4f78abdd
      Carlos Garnacho authored
      Fixes two things: 1) As GTK+ can be coerced into using the wayland IM
      module despite the compositor not implementing the interface, all paths
      not checking for global state before sending requests are prone to
      crashes, this one fell hit this pitfall.
      And 2) ensures the tap gesture only triggers TOGGLE_INPUT_PANEL if the
      widget IM is focused. This is a possibility on eg. WebKit pages, where
      its IM is only focused as long as a form element in the page is focused.
      Tapping elsewhere shouldn't toggle the OSK.
      Closes: #114