gtk2/gtk/gtkactionobserver.c

188 lines
7.0 KiB
C
Raw Normal View History

/*
* Copyright © 2011 Canonical Limited
*
2012-02-27 13:01:10 +00:00
* This library is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License as
* published by the Free Software Foundation; either version 2 of the
* licence or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
2012-02-27 13:01:10 +00:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
* Authors: Ryan Lortie <desrt@desrt.ca>
*/
#include "config.h"
#include "gtkactionobserverprivate.h"
G_DEFINE_INTERFACE (GtkActionObserver, gtk_action_observer, G_TYPE_OBJECT)
/*< private >
* GtkActionObserver:
*
* `GtkActionObserver` is a simple interface allowing objects that wish to
* be notified of changes to actions to be notified of those changes.
*
* It is also possible to monitor changes to action groups using
* `GObject` signals, but there are a number of reasons that this
* approach could become problematic:
*
* - there are four separate signals that must be manually connected
* and disconnected
*
* - when a large number of different observers wish to monitor a
* (usually disjoint) set of actions within the same action group,
* there is only one way to avoid having all notifications delivered
* to all observers: signal detail. In order to use signal detail,
* each action name must be quarked, which is not always practical.
*
* - even if quarking is acceptable, `GObject` signal details are
* implemented by scanning a linked list, so there is no real
* decrease in complexity
*/
void
gtk_action_observer_default_init (GtkActionObserverInterface *class)
{
}
/*< private >
* gtk_action_observer_action_added:
* @observer: a `GtkActionObserver`
* @observable: the source of the event
* @action_name: the name of the action
* @enabled: %TRUE if the action is now enabled
* @parameter_type: (nullable): the parameter type for action invocations
* @state: (nullable): the current state of the action
*
* This function is called when an action that the observer is
* registered to receive events for is added.
*
* This function should only be called by objects with which the
* observer has explicitly registered itself to receive events.
2011-12-01 11:30:10 +00:00
*/
void
gtk_action_observer_action_added (GtkActionObserver *observer,
GtkActionObservable *observable,
2020-07-24 18:40:36 +00:00
const char *action_name,
const GVariantType *parameter_type,
gboolean enabled,
GVariant *state)
{
g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
GTK_ACTION_OBSERVER_GET_IFACE (observer)
->action_added (observer, observable, action_name, parameter_type, enabled, state);
}
/*< private >
* gtk_action_observer_action_enabled_changed:
* @observer: a `GtkActionObserver`
* @observable: the source of the event
* @action_name: the name of the action
* @enabled: %TRUE if the action is now enabled
*
* This function is called when an action that the observer is
* registered to receive events for becomes enabled or disabled.
*
* This function should only be called by objects with which the
* observer has explicitly registered itself to receive events.
2011-12-01 11:30:10 +00:00
*/
void
gtk_action_observer_action_enabled_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
2020-07-24 18:40:36 +00:00
const char *action_name,
gboolean enabled)
{
g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
GTK_ACTION_OBSERVER_GET_IFACE (observer)
->action_enabled_changed (observer, observable, action_name, enabled);
}
/*< private >
* gtk_action_observer_action_state_changed:
* @observer: a `GtkActionObserver`
* @observable: the source of the event
* @action_name: the name of the action
* @state: the new state of the action
*
* This function is called when an action that the observer is
* registered to receive events for changes to its state.
*
* This function should only be called by objects with which the
* observer has explicitly registered itself to receive events.
2011-12-01 11:30:10 +00:00
*/
void
gtk_action_observer_action_state_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
2020-07-24 18:40:36 +00:00
const char *action_name,
GVariant *state)
{
g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
GTK_ACTION_OBSERVER_GET_IFACE (observer)
->action_state_changed (observer, observable, action_name, state);
}
/*< private >
* gtk_action_observer_action_removed:
* @observer: a `GtkActionObserver`
* @observable: the source of the event
* @action_name: the name of the action
*
* This function is called when an action that the observer is
* registered to receive events for is removed.
*
* This function should only be called by objects with which the
* observer has explicitly registered itself to receive events.
2011-12-01 11:30:10 +00:00
*/
void
gtk_action_observer_action_removed (GtkActionObserver *observer,
GtkActionObservable *observable,
2020-07-24 18:40:36 +00:00
const char *action_name)
{
g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
GTK_ACTION_OBSERVER_GET_IFACE (observer)
->action_removed (observer, observable, action_name);
}
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
/*< private >
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
* gtk_action_observer_primary_accel_changed:
* @observer: a `GtkActionObserver`
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
* @observable: the source of the event
* @action_name: (nullable): the name of the action
* @action_and_target: (nullable): detailed action of the changed accel, in action and target format
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
*
* This function is called when an action that the observer is
* registered to receive events for has one of its accelerators changed.
*
* Accelerator changes are reported for all targets associated with the
* action. The @action_and_target string should be used to check if the
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
* reported target is the one that the observer is interested in.
*
* Either @action_name or @action_and_target may be %NULL.
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
*/
void
gtk_action_observer_primary_accel_changed (GtkActionObserver *observer,
GtkActionObservable *observable,
2020-07-24 18:40:36 +00:00
const char *action_name,
const char *action_and_target)
GtkActionMuxer: store primary accels 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).
2013-07-10 02:37:17 +00:00
{
GtkActionObserverInterface *iface;
g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
iface = GTK_ACTION_OBSERVER_GET_IFACE (observer);
if (iface->primary_accel_changed)
iface->primary_accel_changed (observer, observable, action_name, action_and_target);
}