| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Just like we did for GtkShortcutTrigger.
This allows language bindings to properly deal with all the actions.
|
|
|
|
|
|
|
|
|
|
| |
The lightweight inheritance mechanism used for GtkShortcutTrigger is not
going to be usable by bindings, because boxed types cannot have derived
types.
We could use GTypeInstance and derive everything from that, like
GParamSpec, but in the end shortcuts are not really a performance
critical paths, unlike CSS values or render nodes.
|
|
|
|
|
|
|
|
|
|
| |
GTK defines various types that are meant to be derivable only within GTK
itself, and "final" from the perspective of consumers of the GTK API.
The existing macros defined by GObject, such as G_DECLARE_FINAL_TYPE and
G_DECLARE_DERIVABLE_TYPE, lack this functionality.
While we wait for GObject to get this kind of macro, we should define
our own.
|
|
|
|
| |
g_list_model_get_item is transfer full :(
|
| |
|
| |
|
|
|
|
|
| |
We have a test that enumerates the GtkText actions,
so when a new open appears, the test needs to be updated.
|
| |
|
|
|
|
| |
We forgot to allocated that popover.
|
|
|
|
|
| |
This is now done in widgets which have context
menus.
|
|
|
|
| |
This signal is going away.
|
|
|
|
| |
This signal is going away.
|
|
|
|
| |
We can just use a shortcut controller directly.
|
|
|
|
| |
The signal was not used anyway, in the font explorer demo.
|
|
|
|
| |
This signal is going away. Use an action instead.
|
|
|
|
|
| |
This signal is going away, and having context menus
on sliders is not really a thing anyway.
|
|
|
|
| |
This signal is going away.
|
|
|
|
| |
This signal is going away. Use an action instead.
|
|
|
|
| |
The ::popup-menu signal is going away.
|
| |
|
|
|
|
|
| |
At a tab that lists the shortcuts contained in a
GtkShortcutController.
|
|
|
|
| |
No point in creating objects that just hold empty lists.
|
| |
|
| |
|
|
|
|
| |
This is helpful in the inspector.
|
|
|
|
|
|
| |
It is just too ugly to use quarks across multiple
source files, so add a private helper function that
attaches the controllers.
|
|
|
|
| |
Simplifies code quite a bit.
|
| |
|
|
|
|
| |
It's unused.
|
| |
|
|
|
|
|
|
|
|
| |
People should use shortcut controllers instead (global, capture).
A side effect of this is that GtkAccelLabel now lost its method to
magically look up accelerators to display. Somebody needs to add that
back later.
|
| |
|
| |
|
|
|
|
|
| |
Use it to allow adding shortcuts to the controller via the usual <child>
method.
|
|
|
|
|
| |
<property name="action">action(win.quit)</property> style action
specifications now work for GtkShortcutAction properties.
|
|
|
|
| |
And hook it up into the GtkBuilder infrastructure.
|
|
|
|
|
|
|
|
| |
API remains the same, but activation is now done via a
shortcutcontroller.
The code uses a controller with global scope so that the
shortcuts are managed with all the other global shortcuts.
|
|
|
|
| |
It was using the default display unconditionally.
|
|
|
|
| |
A parse function should return success or not. So do that.
|
|
|
|
|
| |
Those are useful for putting triggers in hash tables or getting sorted
output.
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce the amount of special casing by using a list model
for global and managed shortcuts, too.
This way, the ListModel API will work for the ShortcutController in the
GtkShortcutManager and GtkRoot.
The only special case remaining is shortcut activation, which needs to
pass the right widget to the controller in the global/managed case.
|
|
|
|
| |
For all but the callback action, we can print something useful.
|
|
|
|
|
| |
This way, we can use shortcut_controller_new_for_model() and avoid all
the special casing about run_class.
|
|
|
|
|
|
|
| |
This is mainly for internal use, but I can't see a reason to not have it
public for people who want to maintain their own lists.
I'm sure gnome-builder will never ever find a way to misuse it.
|
|
|
|
| |
After all, this controller is a list of shortcuts.
|
| |
|
|
|
|
|
|
|
|
| |
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
- Activate a GAction
|
|
|
|
| |
After the removal of GtkAccelMap, these things are no longer necessary.
|