1. 21 Oct, 2018 1 commit
  2. 19 Oct, 2018 2 commits
  3. 16 Oct, 2018 5 commits
    • Matthias Clasen's avatar
      Merge branch '1371-flickering-tooltips-if-no-mouse-cursor-theme-loaded-gtk3' into 'gtk-3-24' · 00034c00
      Matthias Clasen authored
      Tooltip: Fix the used cursor size if 0 in Settings
      
      See merge request !374
      00034c00
    • Matthias Clasen's avatar
      Merge branch... · c0b5d660
      Matthias Clasen authored
      Merge branch '1397-gtknotebook-built-in-popup-menu-listing-tabs-doesn-t-use-tab-label-text-for-the-last-tab' into 'gtk-3-24'
      
      Notebook: Ensure menu label updates with tab_label
      
      See merge request !385
      c0b5d660
    • Benjamin Otte's avatar
      Merge branch 'win32-fix-dnd-info-disposal' into 'gtk-3-24' · 2453e71f
      Benjamin Otte authored
      Fix DND info disposal
      
      See merge request !390
      2453e71f
    • LRN's avatar
      DnD: fix setting icon in drag-begin · 41721381
      LRN authored
      Commit 1c96b703 changed the way icon
      information is given to DnD. Previously an icon helper was kept at
      the drag source site. Now an image definition is stored there.
      The difference is that icon helper is an object that changes its
      state in response to an icon being set, thus the object survived
      multiple icon changes. Whereas image definition is destroyed and
      re-created from scratch every time a drag icon is changed.
      This created a problem where gtk_drag_begin_internal() would receive
      the value of site->image_def when a drag just began, then it emits
      "drag-begin" signal, in response to which an application can
      set drag icon, changing the value of site->image_def. However,
      gtk_drag_begin_internal() is unable to know about that change and
      continues to use the old value it received from up the stack.
      
      Not only does it prevent drag icon from being set from "drag-begin",
      it also can induce a crash, since the old image_def value used
      by gtk_drag_begin_internal() points to a freed memory region.
      
      Fix this by only setting a default icon (which is created in-place)
      in gtk_drag_begin_internal() if the caller does not care about icons.
      Otherwise gtk_drag_begin_internal() will return a boolean that indicates
      whether an icon needs to be set. Then the caller can invoke
      gtk_drag_set_icon_definition() to set the icon, if needed.
      
      Fixes #1407.
      41721381
    • LRN's avatar
      Fix GtkDragSourceInfo disposal · 5e00fd25
      LRN authored
      gtk_drag_clear_source_info() immediately unrefs the info attached
      to the context (the very same info we're in the process of destroying
      in gtk_drag_source_info_free()). If that reference was the last one,
      then accessing the info object after that is a use-after-free error.
      Also, change the order a bit to first free the event, and only then
      unref the context.
      
      Fix this by copying all the fields of the info that we need, and
      then working with these copies.
      5e00fd25
  4. 15 Oct, 2018 1 commit
  5. 13 Oct, 2018 1 commit
  6. 12 Oct, 2018 4 commits
    • Daniel Boles's avatar
      Adwaita: Regenerate CSS for new window.devel style · 2856fb86
      Daniel Boles authored
      Commit 955aa8d5 forgot this, again.
      2856fb86
    • Daniel Boles's avatar
      Notebook: Ensure menu_label updates with tab_label · 80a3d709
      Daniel Boles authored
      This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
      buildable_add_child() calls set_tab_label(), but the latter did nothing
      to update the menu_label corresponding to that tab with the new text.
      Using Builder to populate the tab child, only tabs other than last got
      the right non-default labels, and even that was mostly coincidental, as
      adding the main child called update_labels() via real_insert_page(), so
      it took effect when the 2nd last main child is added, updating the rest
      but leaving the last with the default label, not that given in Builder.
      
      Fix by factoring out the code from child_reordered() to a new helper
      menu_item_recreate() and calling that in set_tab_label(), so that
      whenever the tab_label is updated, so is its corresponding menu_label.
      
      This fixes the reported case and presumably others that we could write.
      
      fixes #1397
      80a3d709
    • Daniel Boles's avatar
      Notebook: Don't notify 2x from set_tab_label_text · 82c53089
      Daniel Boles authored
      It calls set_tab_label(), which already does that.
      82c53089
    • Daniel Boles's avatar
      gtk-demo/main: Suppress implicit fallthru warning · d9f08c85
      Daniel Boles authored
      Comments matched to reassure the compiler that fallthrough is
      intentional are supposed to precede the case or default keywords, at
      least in GCC, so the one here did not suppress the warning with GCC. We
      can just the if condition and put the comment at the end to solve that.
      
      https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
      d9f08c85
  7. 11 Oct, 2018 1 commit
  8. 10 Oct, 2018 2 commits
  9. 08 Oct, 2018 2 commits
    • LRN's avatar
      Merge branch 'gtk-3-24.win.updated' into 'gtk-3-24' · caa5ba46
      LRN authored
      gtkimcontextime.c: Fix Korean input
      
      See merge request !356
      caa5ba46
    • 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.
      1ece5562
  10. 07 Oct, 2018 3 commits
    • Hugo Lefeuvre's avatar
      gtkstack: fix null pointer dereference · adbaee79
      Hugo Lefeuvre authored
      The gtk_stack_snapshot_slide() function dereferences the
      last_visible_child pointer without proper != NULL ckeck. This might
      result in NULL pointer dereference and crash if last_visible_child is
      invalid.
      
      Add a != NULL check before dereferencing the pointer.
      
      cherry-picked from !361
      adbaee79
    • Daniel Boles's avatar
      Tooltip: Fix the used cursor size if 0 in Settings · 9b7d886b
      Daniel Boles authored
      Before the recent rework of positioning in GtkTooltip, the widget always
      used the cursor_size of the GdkDisplay. That work redid this to instead
      take GtkSettings::gtk-cursor-theme-size. But that property's doc says:
      
      > Size to use for cursors, or 0 to use the default size.
      
      and has 0 as its default. This is quite a likely scenario for anyone
      whose desktop or settings.ini does not explicitly provide a cursor size,
      which is the case for XFCE and win32, to name just two common platforms.
      
      Then, it seems getting a cursor_size of 0 causes GtkTooltip to freak out
      and hide/show itself at a very rapid speed, thus making it unusable.
      
      So, we should check whether the Settings return 0 and, if so, still use
      gdk_display_get_default_cursor_size (display) to ensure we get a size.
      
      #1371
      9b7d886b
    • Aurimas Černius's avatar
      Updated Lithuanian translation · b10cde7b
      Aurimas Černius authored
      b10cde7b
  11. 06 Oct, 2018 2 commits
    • LRN's avatar
      Merge branch 'win32-runtime-immodule-swap' into 'gtk-3-24' · 259c8e63
      LRN authored
      GDK W32: Support switching input modules at runtime
      
      See merge request !366
      259c8e63
    • LRN's avatar
      GDK W32: Support switching input modules at runtime · d26c11f0
      LRN authored
      This leverages the normal input module switching mechanism in GTK
      by making it think that the gtk-im-module setting changed.
      The backend returns gtk-im-module value as "ime" if W32
      IME API says that an IME is in use. Otherwise it returns
      and empty string - this still triggers an input module
      loading code, which, not being able to load the desired module
      (which is and empty string), falls back to looking at current
      keyboard layout.
      
      Paired with the code that signals gtk-im-module change on keyboard layout
      switches, this is sufficient to make GTK capable of loading appropriate
      input modules at runtime. At least, the kinds of modules that specify
      languages for which they are loaded automatically by default, and the
      IME module.
      
      Loading other kinds of input modules might still work via specifying
      the gtk-im-module setting in gtk ini file, but doing so will likely
      make GTK incapable of loading the IME input module that is used
      for Korean, Chinese and Japanese (and some other languages).
      
      Until someone figures out a way to actually change gtk-im-module
      setting on Windows at runtime with meaningful values, the behaviour
      introduced by this commit seems like a sufficient workaround.
      d26c11f0
  12. 03 Oct, 2018 1 commit
  13. 28 Sep, 2018 1 commit
  14. 24 Sep, 2018 3 commits
  15. 22 Sep, 2018 1 commit
  16. 21 Sep, 2018 1 commit
    • Arnaud B.'s avatar
      Make dashed border-style work correctly · 0feebcf1
      Arnaud B. authored
      There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.
      0feebcf1
  17. 19 Sep, 2018 2 commits
  18. 18 Sep, 2018 2 commits
  19. 17 Sep, 2018 1 commit
  20. 14 Sep, 2018 2 commits
  21. 13 Sep, 2018 2 commits