1. 04 Jul, 2018 2 commits
  2. 25 Jun, 2018 1 commit
  3. 11 Jun, 2018 1 commit
  4. 26 Apr, 2018 1 commit
  5. 10 Apr, 2018 2 commits
    • Emmanuele Bassi's avatar
      Terminate strncpy() buffers correctly · 14c8a603
      Emmanuele Bassi authored
      When using strncpy() with a buffer we need to account for the
      terminating NUL character. GCC 8 started warning when using PPD_MAX_NAME
      as the buffer length for strncpy() because the buffer we're copying into
      has the same length — which means that the terminating NUL may be
      skipped if the source string has a length of PPD_MAX_NAME.
      
      The appropriate way to handle the case where we're copying a source with
      a length bigger than of PPD_MAX_NAME is, as reported in the strncpy()
      documentation, to copy `PPD_MAX_NAME - 1` bytes, and explicitly NUL
      terminate the destination buffer. This has the additional benefit of
      avoiding the compiler warning.
      14c8a603
    • Benjamin Otte's avatar
      12063fe5
  6. 05 Apr, 2018 1 commit
  7. 28 Mar, 2018 1 commit
  8. 18 Mar, 2018 4 commits
  9. 13 Mar, 2018 1 commit
  10. 11 Mar, 2018 1 commit
  11. 25 Feb, 2018 2 commits
    • Matthias Clasen's avatar
      Always include platform immodules · 15cc20e7
      Matthias Clasen authored
      No need to load these as gio modules, we just include
      them in libgtk.
      15cc20e7
    • Matthias Clasen's avatar
      Convert immodules to use an extension point · 29bcc38a
      Matthias Clasen authored
      Add an extension point called gtk-im-module, which requires
      the type GtkIMContext. Simplify the loading by using GIO
      infrastructure. Drop the locale filtering for now, I don't
      think it is really necessary nowadays.
      
      Convert existing platform modules to gio modules.
      Sill to do: Drop the conditional build machinery.
      Either always include them, or never.
      29bcc38a
  12. 19 Feb, 2018 4 commits
  13. 18 Feb, 2018 2 commits
  14. 17 Feb, 2018 1 commit
  15. 16 Feb, 2018 1 commit
  16. 15 Feb, 2018 2 commits
  17. 14 Feb, 2018 4 commits
  18. 13 Feb, 2018 1 commit
  19. 03 Feb, 2018 2 commits
    • Emmanuele Bassi's avatar
      Drop the Big GDK Lock · 888dfe49
      Emmanuele Bassi authored
      GDK has a lock to mark critical sections inside the backends.
      Additionally, code that would re-enter into the GTK main loop was
      supposed to hold the lock.
      
      Back in the Good Old Days this was guaranteed to kind of work only on
      the X11 backend, and would cause a neat explosion on any other GDK
      backend.
      
      During GTK+ 3.x we deprecated the API to enter and leave the critical
      sections, and now we can remove all the internal uses of the lock, since
      external API that uses GTK+ 4.x won't be able to hold the GDK lock.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=793124
      888dfe49
    • Emmanuele Bassi's avatar
      Replace gdk_threads_add_timeout* with g_timeout_add() · c655759c
      Emmanuele Bassi authored
      The main GDK thread lock is not portable and deprecated.
      
      The only reason why gdk_threads_add_timeout() and
      gdk_threads_add_timeout_full() exist is to allow invoking a callback
      with the GDK lock held, in case 3rd party libraries still use the
      deprecated gdk_threads_enter()/gdk_threads_leave() API.
      
      Since we're removing the GDK lock, and we're releasing a new major API,
      such code cannot exist any more; this means we can use the GLib API for
      installing timeout callbacks.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=793124
      c655759c
  20. 16 Jan, 2018 1 commit
  21. 17 Dec, 2017 1 commit
  22. 08 Dec, 2017 1 commit
  23. 21 Nov, 2017 1 commit
  24. 17 Nov, 2017 1 commit
  25. 31 Oct, 2017 1 commit