GNOME Bugzilla – Bug 686782
Support assigning simple key modifiers to tablet's HW buttons
Last modified: 2013-07-24 09:24:06 UTC
On selecting a bidding for the stylus buttons , this choices actually appear : http://i.imgur.com/eVl5W.jpg Unfortunately, on this list, there is not a lot of pertinent choice compare to the use of a stylus for digital painting. Example , I use here 'Ctrl' on the lower button ( color picker on Krita / Mypaint / Gimp ) as a part of my workflow. As a workaround, I can for the moment run a xsetwacom command on the top for my 2 tablets connected : xsetwacom set "Wacom Cintiq 21UX stylus" Button 2 "key ctrl" xsetwacom set "Wacom Intuos4 6x9 stylus" button 2 "key ctrl" Witch is fine, but still a workaround. If it's a low-hanging fruit, I would really appreciate to see on the scrolling list in next version 3 more options ' CTRL Modifier' , 'Alt Modifier' and 'Shift Modifier'. Thanks in advance.
Adding the modifiers to the list of actions is not sufficient, it would be a combination of button press and modifiers that's needed, but that would be awkward IMHO. What really matters is the action itself, ie the use of a modifier is a mean to achieve the action in the application ("pick a color" in the application) and not an end in itself. So I think this bug should be covered by the same fix as bug 670907, ie implement application bindings. Eventually, instead of using "CTRL+Alt+Left click" emulation to trigger "pick a color in GIMP" (for example, could be any app really), GNOME settings daemon would trigger the action in GIMP directly.
Understandable. However, not all applications follow the same scheme of shortcuts so naming them on function can be a problem. Therefore I think being able to use MOUSE MIDDLE CLICK, CTRL+= or SHIFT+DOWN should also be possible.
Maintainer change
Even though we should have the app bindings, my opinion about this is that we should allow mapping pure modifiers to the stylus's buttons because, as "pander" says, this is the only way to ensure that it can cover whatever application users may be using. Not a good argument but I can see that the OSX's settings show a "Modifier..." option for the stylus's button, as show in: https://live.gnome.org/action/diff/Design/SystemSettings/Tablet#Mockups I also don't understand why it couldn't be a simple modifier as Olivier opposes to (because I can just press the side button for getting a Ctrl mod and after that touch the tablet with the stylus to produce Ctrl+left_click). Maybe I am missing something?
It would also be in line with how GNOME3 allow configuration of shortcuts. Perhaps that could even be reused directly. See also http://i.stack.imgur.com/dBkqb.png
(In reply to comment #5) > It would also be in line with how GNOME3 allow configuration of shortcuts. > Perhaps that could even be reused directly. See also > http://i.stack.imgur.com/dBkqb.png Generating key combinations has nothing to do with capturing them.
*** Bug 694440 has been marked as a duplicate of this bug. ***
Hi, I wonder if we should add an option to the combo that shows the stylus buttons' actions called "Modifiers..." and when pressed, show a list of "unmarked" radio buttons with Shift|Ctrl|Super to set the combinations. That might be a bit uglyish from a design point of you perhaps we could use Jakub's opinion here.
Assigning pure modifiers seems like a desirable thing to have as they are indeed used extensively in graphics applications and would be cool not having to reach for a keyboard for this. Ideally we could have a single menu item listing ctrl alt shift (I would leave out the system super) togglebuttons in a similar way firefox does cut, copy and paste, but I'm not sure it's achievable with gtk :/ A much worse solution would be to have a 'Modifier keypress...' item and a modal dialog to choose between the three if you selected it, updating the selected entry to "Shift keypress" when the dropdown is collapsed. It sounds so eeky that even listing all three as items doesn't seem so terrible in retrospect. The other aspect of this is that our current button mapping doesn't indeed allow to map a pure modifier either. It should. We probably want to use the same solution for the button mapping as we'll have for the stylus.
I agree with Jakub. I'm also really happy to see new post on this bugreport.( as well as on the 'keep proportion' thread ) :-)
Created attachment 244059 [details] [review] wacom: Support assigning key modifiers to devices' keys This introduces a new cell renderer to pick the modifiers and new GsdWacomActionType.
Created attachment 244060 [details] [review] wacom: Support sending only modifiers assigned to the custom key
The patches above implement the request support but for HW keys. Support for assigning this to the stylus's buttons still needs to be implemented.
I have narrowed this feature to tablet's HW buttons because the styli are managed in a different way which I believe is worth dealing with in its own bug. Please review these patches when possible.
Created attachment 245623 [details] [review] wacom: Support assigning key modifiers to devices' keys This introduces a new cell renderer to pick the modifiers and new GsdWacomActionType. This version is rebased with master and corrects some things I found out meanwhile.
Created attachment 245624 [details] [review] wacom: Support sending only modifiers assigned to the custom key
Created attachment 245626 [details] [review] wacom: Support assigning key modifiers to devices' keys Another version correcting a small "expanding" problem in the mapping treeview.
Created attachment 245627 [details] Screenshot: Editing the modifier
Created attachment 245628 [details] Screenshot: After editing
This is looking really nice. Styling wise, it would be nice to have a 1px margin. Contrary to our discussion on IRC though, I wouldn't make them a linked group which is a control we usually use similarly to a radio control and I think we want to be be able to send modifier combos, they aren't exclusive. Just space them with 1px whitespace vertically and horizontally. 'Apply modifier' doesn't sound great to me, but haven't found anything much better yet. Joaquim suggested 'Send modifier' which I like better.
Created attachment 245640 [details] [review] wacom: Support assigning key modifiers to devices' keys New version after Jakub's comments. I couldn't however hide the renderer's label while editing a cell. If anyone got a good way to do it, please share.
Created attachment 245641 [details] [review] wacom: Support assigning key modifiers to devices' keys Forgot to change the "Apply Modifier" label, here it goes.
Review of attachment 245624 [details] [review]: ::: plugins/wacom/gsd-wacom-manager.c @@ +1205,3 @@ gtk_accelerator_parse_with_keycode (str, &keyval, &keycodes, &mods); + + action_type = g_settings_get_enum (wbutton->settings, KEY_ACTION_TYPE); In filter_button_events(), assign a variable to action_type (it's checked from GSettings 3 times without being assigned), and pass it as a parameter to generate_key. @@ +1210,3 @@ + gdk_error_trap_push (); + + send_modifiers (display, mods, is_press); You'll need to check for mods not being empty.
Review of attachment 245641 [details] [review]: ::: panels/wacom/cc-modifiers-cell-renderer.c @@ +30,3 @@ +}; + +const GdkModifierType MASKS[] = {GDK_SHIFT_MASK, One space too many. And put the first value on the following line. @@ +33,3 @@ + GDK_CONTROL_MASK, + GDK_MOD1_MASK, + 0}; Mention that the ordering must match the one used in the shortcut cell renderer. @@ +60,3 @@ + + modifier_data = g_object_get_data (G_OBJECT (button), "modifier"); + modifier = (GdkModifierType) GPOINTER_TO_UINT (modifier_data); You can do that without the intermediate modifier_data variable. @@ +73,3 @@ +{ + const gchar *path; + gboolean canceled; cancelled. @@ +115,3 @@ + + /* It can occur that the start_editing is called again before a + previous editing is done which causes problems (because the This is the format for comments: /* Blah * Blah */ @@ +122,3 @@ + return NULL; + + cell_text = GTK_CELL_RENDERER_TEXT (cell); Why do you need to cast it to use it in g_object_get() (which expects a gpointer, not a GtkCellRendererText) @@ +138,3 @@ + priv->new_modifiers_mask = priv->modifiers_mask; + + for (i = 0; MASKS[i] != 0; i++) Remove the "0" value from the array and use G_N_ELEMENTS() instead. @@ +148,3 @@ + button = gtk_toggle_button_new_with_label (label); + + gtk_widget_set_margin_bottom (button, 1); Magic number. @@ +226,3 @@ + + gobject_class->set_property = cc_modifiers_cell_renderer_set_property; + gobject_class->get_property = cc_modifiers_cell_renderer_get_property; Maybe you need to @@ +229,3 @@ + + g_object_class_install_property (gobject_class, + PROP_MODIFIERS_MASK, Indentation. @@ +251,3 @@ + g_type_class_add_private (klass, sizeof (CcModifiersCellRendererPrivate)); + + renderer_class->start_editing = cc_modifiers_cell_renderer_start_editing; Subclassing ->render might be needed to get the background cleared when editing starts? Otherwise you'll be rendering your usual text renderer and then whatever you're adding on top. ::: panels/wacom/cc-wacom-page.c @@ +989,3 @@ + + /* renderer = gtk_cell_renderer_spin_new (); */ + /* GtkAdjustment *adj = gtk_adjustment_new (10, 0, 100, 1, 5, 5); */ Hmm?
Obsolete by https://bugzilla.gnome.org/show_bug.cgi?id=703148