1. 22 Apr, 2016 1 commit
  2. 11 Dec, 2014 1 commit
  3. 15 May, 2014 1 commit
  4. 15 Oct, 2013 1 commit
    • Allison Karlitskaya's avatar
      GtkActionMuxer: store primary accels · 3f8c2355
      Allison Karlitskaya authored
      Reuse the existing infrastructure in GtkActionMuxer for propagation of
      accelerator information: in particular, what accel label ought to appear
      on menu items for a particular action and target.
      
      This is a good idea because we want accels to travel along with the
      actions that they're tied to and reusing GtkActionMuxer will allow us to
      do that without creating another hierarchy of a different class for the
      sole purpose of filling in accel labels on menu items.
      
      Doing it this ways also allows those who copy/paste GtkActionMuxer to
      insert the accels for themselves.
      
      Add a new method on the GtkActionObserver interface to report changes.
      
      This patch introduces a new concept: "action and target" notation for
      actions.  This format looks like so:
      
        "'target'|app.action"
      
      or for non-targeted actions:
      
        "|app.action"
      
      and it is used over a number of possible alternative formats for some
      good reasons:
      
       - it's very easy to get a nul-terminated action name out of this format
         when we need it, by using strrchr('|') + 1
      
       - we can also get the target out of it using g_variant_parse() because
         this function takes a pointer to a 'limit' character that is not
         parsed past: we use the '|' for this
      
       - it's extremely easy to hash on this format (just use a normal string
         hash) vs. attempting to hash on a string plus a GVariant
      
      A close contender was to use detailed action strings here, but these are
      not used for two reasons:
      
       - it's not possible to easily get the action name or target out of the
         strings without more work than the "action and target" format
         requires
      
       - we still intend to use detailed action strings on API (since they are
         a lot nicer to look at) but detailed action strings can be given in
         non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
         so we'd have to go through a normalisation step anyway.  Since we're
         doing that already, we may as well convert to a more convenient
         internal format.
      
      This new "action and target" format is going to start appearing in a lot
      more places as action descriptions are introduced.
      
      I suspect that nobody is using '|' in their action names, but in case I
      am proven wrong, we can always switch to using something more exotic as
      a separator character (such as '\x01' or '\xff' or the like).
      3f8c2355
  5. 13 May, 2013 3 commits
  6. 20 Aug, 2012 1 commit
    • Lars Uebernickel's avatar
      GActionMuxer: add support for parent muxers · d1c458f9
      Lars Uebernickel authored
      If a muxer does not contain an action group with the given prefix, chain
      up to the "parent" muxer to look for it.
      
      This initial implementation is rather inefficient.  It will lead to
      changes on action groups associated with parent muxers being broadcast
      to all children (regardless of if anybody there is interested or not).
      An optimised version will follow soon.
      d1c458f9
  7. 27 Feb, 2012 1 commit
  8. 19 Dec, 2011 1 commit