GNOME Bugzilla – Bug 670907
Implement application bindings
Last modified: 2019-03-20 10:58:47 UTC
As shown in: https://live.gnome.org/action/diff/Design/SystemSettings/Tablet#Mockups We would need a way to tell applications: "Zoom by 10%" or "Decrease brush size by 2 points".
See also bug 686782
Maintainer change
The design needs to be reviewed since the bindings should be set per app and many apps might not support the suggested actions in the current design. E.g. brush opacity / pick color / etc. are not useful when working with Blender.
By the UI review, what I expect is to have a solution for not exposing confusing controls like choosing an app and then which function to assign for it. If we decide not to let users configure each button+app's individual function, then I hope I get a solution for exposing functions that might not make sense in the app a user intends to use (e.g. brush size in Blender). In all cases I think that letting users configure a keyboard shortcut and modifiers might make it useful and it's a fallback when the user's desired function is not found in the list.
What I had in mind is a cross application API. If an app doesn't/can't implement/expose an event, then it's simply not triggered by the button. The keyboard shortcut is definitely useful, but a fallback. The key issue with keyboard shortcut is that you essentially need to configure everything twice. System level shortcut and then app by app to make sure the shortcuts align/dont' conflict.
I don't think we can get whether an app implements a certain function or not unless they expose them some way like through DBUS and I don't think we should count on that. Bastien can correct me if I'm wrong. In that case, and to have different bindings per app, we will to keep our own database of function-shortcut per app and to consult these based on the currently focused app. Surely we can do nothing in case the current app is not on our database or doesn't have a correspondent function but this way we don't have different functions per app, only different shortcuts for the same function. Is this what's intended?
Here's what I'm thinking about the architecture to implement this (explained in very basic terms and without UML :) ): Apps have actions that may be "increase brush opacity by 10%", "save", "open", "pick color", etc. [APP BINDINGS PROVIDER] (provider may not be the better name) A provider is a GObject that describes an application and its supported actions, it also knows how to apply the actions. It has a name for the respective application e.g. "inkscape" (or a list of names if we think it'll be difficult to get a fixed app name on all systems as "icedove" on Debian instead of Thunderbird but this might not be necessary). It also holds a list of those supported actions which is a pair of action_name:action_function The action_name may be e.g. "pick-color" or "decrease-brush-opacity". The action_function is a pointer to a function that applies the respective action. That function may implement the action e.g. through a DBus call or through a keyboard shortcut. We could also map a third "variable" here which would be the "human-readable" name of the action where we'd have a translatable string e.g. "Decrease brush opacity". [APP BINDINGS MANAGER] This is a GObject that holds a list of providers and is in charge of asking the right one to apply an action. This manager is given the name of the action (from g-s-d) when an event occurs, checks which is the currently used application's name (by using libwnck or another way) , gets the right provider based on that and tells it to apply the action. ==== Using the implementation above, we can have a provider subclass for each app that has a DBus API and a generic kb shortcut provider for those who don't, this one can be instantiated with an app name and a list of action names and kb shortcuts (e.g. "<control>s").
As mentioned on IRC, I don't want to have to maintain the non-DBus version of the code, so there's no need to implement this as an abstract class. If an application doesn't support/use D-Bus, you can create a separate "fake" application that'll take the application's capabilities and export them over D-Bus.
Any progress or decisions about this bug? I did some research about gimp and looks like dbus can't be used out-of-the-box. There is a plugin to expose gimp internals over dbus, but that's too complicated in my opinion. Krita seems to be a bit better, but inkscape/blender are not using dbus (please correct me if I missed something). Are we stuck because there is no perfect solution right now? I think that per-application user defined keyboard shortcuts + user defied icon/label are currently the best what we can have (aka "ms windows solution"). It's not perfect, but I use it at work for a long time and it's definitely better than what we have today - one fixed keyboard shortcut per button for all applications.
Perhaps go with the non perfect solution for now and at the same time ask the respective application communities what they would suggest for tackling this in a generic way? What would a well formulated question with a reference to this bug? To which application communities should it be posted? - Inkscape - GIMP - Blender - Krita - ...?
just browsing the bugs to see if there are any improvements coming to working with a wacom tablet in gnome. will this be implemented in the next gnome release? and didn't all these settings get easier with latest libinput improvements ? thanks
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/181.