1. 11 Oct, 2017 1 commit
  2. 06 Oct, 2017 1 commit
  3. 30 Mar, 2017 1 commit
  4. 14 Oct, 2016 1 commit
  5. 13 Oct, 2016 1 commit
    • Alan Jenkins's avatar
      applicationwindow: fix leak of help_overlay · e2f5425a
      Alan Jenkins authored
      > Due to Gtk+ keeping a reference to the window internally,
      > gtk_window_new() does not return a reference to the caller.
      > To delete a GtkWindow, call gtk_widget_destroy().
      
      Caller(s) aren't expecting a need to delete help_overlay themselves
      once they've installed it.  (E.g. see gtk_application_window_added()).
      
      I didn't notice any direct precedents, but there's a parallel in the
      current implementation of gtk_container_destroy() which uses
      gtk_widget_destroy() on any added widget.
      
      This avoids leaking 100s of kB per window, when I tested nautilus.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=772859
      e2f5425a
  6. 17 Apr, 2016 1 commit
  7. 09 Apr, 2016 1 commit
  8. 14 Nov, 2015 2 commits
  9. 22 Oct, 2015 1 commit
  10. 21 Oct, 2015 1 commit
    • Matthias Clasen's avatar
      Add automatic help overlay support to GtkApplication · f6d9f9f9
      Matthias Clasen authored
      When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
      load a GtkShortcutsWindow from it for each GtkApplicationWindow,
      and set up a win.show-help-overlay action with accels <Primary>F1
      and <Primary>? to show it.
      f6d9f9f9
  11. 30 Jul, 2015 1 commit
  12. 26 Apr, 2015 1 commit
  13. 23 Dec, 2014 1 commit
  14. 09 Jun, 2014 2 commits
  15. 05 May, 2014 1 commit
  16. 12 Feb, 2014 1 commit
    • William Jon McCann's avatar
      docs: fully break lines in examples · 37a8ee6e
      William Jon McCann authored
      Try to do a better job of keeping example content
      from being too wide. It is often rendered as <pre>
      text so the only time we can wrap it is in the source.
      
      It is best to full break lines at all punctuation and
      to try to keep the width under 70 chars or so.
      37a8ee6e
  17. 09 Feb, 2014 1 commit
  18. 05 Feb, 2014 2 commits
  19. 04 Feb, 2014 4 commits
  20. 29 Jan, 2014 2 commits
  21. 14 Jan, 2014 1 commit
    • Ryan Lortie's avatar
      GtkApplicationWindow: give up on handling dispose · bc3867eb
      Ryan Lortie authored
      Stop trying to deal with "theoretical possibilities".
      
      We can't possibly continue to be a faithful GActionGroup implementation
      across dispose because dispose has a side effect of removing everyone's
      signal handlers.
      
      The code that we ran after the dispose chainup to do all of the fancy
      signal emulation was therefore dead.  The test that aimed to verify this
      was buggy itself due to an uninitialised variable, so really, it never
      worked at all.
      
      We keep the re-ordering of the chainup from the original commit to avoid having
      trouble with GtkActionMuxer and keep the checks in place that will prevent an
      outright segfault in the case that someone else tries to use the interface
      post-dispose.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=722189
      bc3867eb
  22. 10 Jan, 2014 1 commit
  23. 08 Jan, 2014 1 commit
    • Ryan Lortie's avatar
      Fix GtkApplicationWindow action group implementation · 2fd307fd
      Ryan Lortie authored
      GtkApplicationWindow frees its internal action group on dispose for the
      usual reasons: to avoid the possibility of reference cycles caused by
      actions referring back to the window again.
      
      Unfortunately, if it happens to be inside of a GtkActionMuxer at the
      time that it is disposed, it will (eventually) be removed from the muxer
      after it has been disposed.  Removing an action group from a muxer
      involves a call to g_action_group_list_actions() which will crash
      because the internal action group to which we normally delegate the call
      has been freed.
      
      A future patch that reworks the quartz menu code will introduce a use of
      GtkActionMuxer in a way that causes exactly this problem.
      
      We can guard against the problem in a number of ways.
      
      First, we can avoid the entire situation by ensuring that we are removed
      from the muxer before we destroy the action group.  To this end, we
      delay destruction of the action group until after the chain-up to the
      dispose of GtkWindow (which is where the window is removed from the
      GtkApplication).
      
      Secondly, we can add checks to each of our GActionGroup and GActionMap
      implementation functions to check that the internal action group is
      still alive before we attempt to delegate to it.
      
      We have to be careful, though: because our _list_actions() call will
      suddenly be returning an empty list, people watching the group from
      outside will have expected to see "action-removed" calls for the
      now-missing items.  Make sure we send those. but only if someone is
      watching.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710351
      2fd307fd
  24. 16 Dec, 2013 1 commit
    • Ryan Lortie's avatar
      Refactor GtkApplication · 7fd81cf1
      Ryan Lortie authored
      gtkapplication.c has turned into a bit of an #ifdef mess over time, and
      many of the current checks are incorrect.  As an example, if you build
      Gtk for wayland, and exclude the X11 backend, much of the functionality
      required by wayland (such as exporting menu models) will be disabled.
      
      Solve that by introducing a backend mechanism to GtkApplication (named
      GtkApplicationImpl) similar to the one in GApplication.  Add backends
      for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
      'DBus' superclass.
      
                                   GtkApplicationImpl
                                            |
                             /--------------+-------------------\
                             |                                  |
                  GtkApplicationImplDBus              GtkApplicationImplQuartz
                             |
                 /-----------+-----------------\
                 |                             |
        GtkApplicationImplX11      GtkApplicationImplWayland
      
      GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
      hooks for various things that the platform-specific backends may be
      interested in doing (startup, shutdown, managing windows, inhibit, etc.)
      
      With this change, all platform specific code has been removed from
      gtkapplication.c and gtkapplicationwindow.c (both of which are now free
      of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
      gtkapplicationwindow.c).
      
      Additionally, because of the movement of the property-setting code out
      of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
      friends) will be set on non-GtkApplicationWindows, such as dialogs.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=720550
      7fd81cf1
  25. 13 Dec, 2013 1 commit
  26. 19 Nov, 2013 1 commit
  27. 16 Nov, 2013 4 commits
  28. 13 Nov, 2013 1 commit
  29. 15 Oct, 2013 1 commit
    • Ryan Lortie's avatar
      GtkApplication: a new approach to accels · 9a6ee36e
      Ryan Lortie authored
      Rework how accels are handled on GtkApplicationWindow.
      
      Instead of having GtkApplication fill the GtkAccelMap which is then used
      by GtkApplicationWindow to create a GtkAccelGroup filled with closures
      that is then associated with the window, do it directly.
      
      GtkApplication now keeps a list of accels and their actions.
      Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
      appropriate action.
      
      This saves a fair bit of complexity and memory use (due to not having to
      create all those closures and accelmap entries).  The new approach also
      supports multiple accels per action (although there is not yet a public
      API for it).
      
      This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
      9a6ee36e
  30. 22 Sep, 2013 1 commit