1. 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
  2. 09 Feb, 2014 1 commit
  3. 05 Feb, 2014 2 commits
  4. 04 Feb, 2014 4 commits
  5. 29 Jan, 2014 2 commits
  6. 14 Jan, 2014 1 commit
    • Allison Karlitskaya's avatar
      GtkApplicationWindow: give up on handling dispose · bc3867eb
      Allison Karlitskaya 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
  7. 10 Jan, 2014 1 commit
  8. 08 Jan, 2014 1 commit
    • Allison Karlitskaya's avatar
      Fix GtkApplicationWindow action group implementation · 2fd307fd
      Allison Karlitskaya 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
  9. 16 Dec, 2013 1 commit
    • Allison Karlitskaya's avatar
      Refactor GtkApplication · 7fd81cf1
      Allison Karlitskaya 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
  10. 13 Dec, 2013 1 commit
  11. 19 Nov, 2013 1 commit
  12. 16 Nov, 2013 4 commits
  13. 13 Nov, 2013 1 commit
  14. 15 Oct, 2013 1 commit
    • Allison Karlitskaya's avatar
      GtkApplication: a new approach to accels · 9a6ee36e
      Allison Karlitskaya 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
  15. 22 Sep, 2013 1 commit
  16. 03 Sep, 2013 1 commit
  17. 09 Jul, 2013 1 commit
  18. 13 May, 2013 1 commit
  19. 21 Apr, 2013 1 commit
    • Matthias Clasen's avatar
      csd: Drop content_window · 1507ba79
      Matthias Clasen authored
      Instead of reparenting the content, use input-only windows to
      set cursors and capture clicks on the window frame. This avoids
      some of the problems that were introduced by content_window, such
      as black flashes and non-working opacity.
      1507ba79
  20. 27 Mar, 2013 1 commit
  21. 17 Mar, 2013 1 commit
    • Rob Bradford's avatar
      window: Allow _gtk_window_set_allocation to return a modified allocation · 55a98da4
      Rob Bradford authored
      Update the documentation and users of this function to handle
      the future case that that we have some internal decorations to the window and
      useable allocation is thus smaller.
      
      By having a separate out parameter there is no need to have an in/out function
      and allows for greater robustness.
      
      The current implementation simply returns the allocation provided.
      55a98da4
  22. 21 Jan, 2013 1 commit
  23. 17 Sep, 2012 2 commits
    • Allison Karlitskaya's avatar
      gtkmodelmenu: simplify logic, expose bind API · dd143479
      Allison Karlitskaya authored
      Make the main (and only) entry-point to gtkmodelmenu.c the now-public
      gtk_menu_shell_bind_model().
      
      Move the convenience constructors (gtk_menu_new_from_model() and
      gtk_menu_bar_new_from_model()) to their proper files.
      
      Remove the private header file.
      
      Simplify the code a bit by making the initial populate part of the
      bind() call.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=682831
      dd143479
    • Allison Karlitskaya's avatar
      GtkAccelLabel: add manual accel API · 778aa7ad
      Allison Karlitskaya authored
      Add an API to GtkAccelLabel for hardcoding the accel key to be displayed
      (ie: allowing us to bypass the GtkAccelGroup lookup).
      
      Use that from the GMenuModel-based GtkMenu construction code instead of
      passing around the accel group.
      
      This makes accel labels work in bloatpad again.
      
      This patch effectively removes any hope of automatic runtime accel
      changes in GMenuModel-based menus without additional application
      support but it leaves the door open for this to be supported again in
      the future (if we decide that it's important).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=683738
      778aa7ad
  24. 20 Aug, 2012 5 commits
    • Allison Karlitskaya's avatar
      GtkApplicationWindow: drop GActionMuxer use · 5634eb22
      Allison Karlitskaya authored
      There are no remaining users of the GActionMuxer in GtkApplicationWindow
      because they've all been ported over to using the one on GtkWidget (via
      GtkActionHelper, for the most part).
      5634eb22
    • Allison Karlitskaya's avatar
      Remove private appwindow observer creation API · 315d43e8
      Allison Karlitskaya authored
      There are no remaining users of the GtkApplicationWindow API to create
      GSimpleActionObserver or to get the GActionObservable (ie: muxer) for
      the appwindow.  Drop those APIs.
      315d43e8
    • Lars Uebernickel's avatar
      ApplicationWindow: setup accels with widget muxer · 86d7c9d5
      Lars Uebernickel authored
      Use the muxer from GtkWidget to setup the accels rather than our own
      local muxer (which will soon be removed).
      86d7c9d5
    • Allison Karlitskaya's avatar
      gtkmodelmenu: move to new action regime · dd45862a
      Allison Karlitskaya authored
      Drop the explicit passing of GActionGroup into the GtkMenu(Bar)
      constructors and operate from the action context instead.
      
      With GtkMenuItem implementing GtkActionable, this turns out to be pretty
      easy (and most of the code can be removed from GtkModelMenuItem,
      including the GActionObserver implementation).
      dd45862a
    • Lars Uebernickel's avatar
      Add two users of gtk_widget_insert_action_group · ab3b4137
      Lars Uebernickel authored
      Each GtkWindow with an associated GtkApplication should add this as
      "app" to its action context.  Each GtkApplicationWindow is its own
      GActionGroup, and it should add itself to itself with the prefix "win".
      
      There is now some duplication here because we have the new GActionMuxer
      hierarchy managed by GtkWidget, but GtkApplicationWindow still carries
      its own muxer.  The redundancy will be removed in a future patch.
      ab3b4137
  25. 23 Jul, 2012 1 commit
  26. 02 Jul, 2012 1 commit
  27. 03 May, 2012 1 commit