Keyboard navigation/patching #869
Conversation
Most of the code related to kbdnav is on g_kbdnav.c but in a few cases we will need to include related functionality in other c files. In g_kbdnav.h We define "HAVE_KEYBOARDNAV" to allow conditional compiling of the kbdnav stuff.
main modifications: - stuff related to t_editor_private - canvas_key redirect key presses to be handled in g_kbdnav.c - canvas_goto() - canvas_objindexes (to be called from the gui)
1. If needed, we display each object index when canvas_map() is called 2. We call the kbdnav routine that draw the connections so we can highlight the selected one
kbdnav stuff mainly responsible for creating new obj/msgbox/atoms in the correct position and connecting them to the correct in/outlet. Also there is kbdnav_iopos() which provides a single function to get in/outlet positions. Currently multiple functions of the pd core use copy/pasted routines to deal with that. I intend to unify them to use this new function later.
When kbdnav is active this allow the blue in/outlet selection rectangle to be drawn for those objects
In this version this is an "tcl entry" that the user can activate with shift+' (resulting in a doublequote). Any message you type there is sent to the patch (just like in dynamic patching). The only exception is "connect" which the code translates to "connect_with_undo".
|
Currently build tests are failing. Maybe it is a problem with the |
|
I like the idea of showing index of objects cause it is also useful for dynamic patching (knowing the index to make connections) |
|
Ctrl+Arrows are captured by the OS so we need to use CMD as our main modifier on OSX. We still need to think of a shortcut for show obj indexes because Cmd+tab is also used by the OS.
|
ctrl+arrows were being capture by the OS so now Cmd is the kbdnav modifier on OSX. Still we should change Cmd+Tab for displaying obj indexes. I'm thinking Cmd+i on OSX and Ctrl+i on Win. |
|
Cool stuff! Still have to test. There are some opportunities to not have any keyboardnav specific code in existing methods at all, other than function calls wrapped in #ifdefs. I gave some hints in my comments. Maybe you can try and see how far you get? |
| @@ -687,6 +693,11 @@ void canvas_map(t_canvas *x, t_floatarg f) | |||
| if (x->gl_isgraph && x->gl_goprect) | |||
| canvas_drawredrect(x, 1); | |||
| sys_vgui("pdtk_canvas_getscroll .x%lx.c\n", x); | |||
| #ifdef HAVE_KEYBOARDNAV | |||
| t_kbdnav *kbdnav = canvas_get_kbdnav(x); | |||
There was a problem hiding this comment.
make sure to conform to C89 (sic!) and declare your variables at the beginning of the code-block.
src/g_editor.c
Outdated
| if(editor) | ||
| { | ||
| t_editor_private *private = editor->e_privatedata; | ||
| t_kbdnav *kbdnav = &private->kbdnav; |
There was a problem hiding this comment.
*always use canvas_get_kbdnav() instead of directly accessing the è_privatedata`.
(there are multiple occurences of this anti-pattern in the code)
| # on X11, <Shift-Tab> is a different key by the name 'ISO_Left_Tab'... | ||
| # other systems (at least aqua) do not like this name, so we 'catch' any errors | ||
| catch {bind $tkcanvas <KeyPress-ISO_Left_Tab> "::pd_bindings::canvas_cycle %W -1 %K %A 1 %k" } stderr | ||
|
|
||
| # window protocol bindings |
There was a problem hiding this comment.
Because with the "goto" functionality you can go directly to any object you want in the patch.
There was a problem hiding this comment.
so? with your patches you don't need the mouse any more, should we remove that as well ;-) ?
(just to make sure: the answer to this rhetoric question should be "no").
as a sidenote: if you want to remove these bindings (and i obviously don't agree that you should) for de-crufting purposes, you should also remove:
- the
canvas_cycletcl-proc - the
cycleselectmethod of the canvas - the
canvas_cycleselectfunction
There was a problem hiding this comment.
an i find goto + trying out all those indices considerably more complicated that just Tabing through the patch.
There was a problem hiding this comment.
The idea with "Go To" is that you don't have to try the indices. You just look at the object, see it's index, type it and hit return.
Tab-traversal is (pratically) unpredictable because the object order can change. A simple, straight"chain" of objects might have completely "spaced" indices depending on the order you created the objects, the copy-pastes you did, and etc.
Especially on big patches it can be quite a chore to keep tabbing until you get to the object you want. Even now that you can see the indices and know how many times you need to press the Tab.
What if you must press it 45 times? And holding Tab is no good either. While holding it did it triggered 30 times? 40 ? 60? I can't see how's that more complicated than
- press mod+g
- all object indices are automatically visible
- look at the object you wanna go and type it's index
- Return
Also the "Go To" is originally intended for "jumps" since when you're on a "chain" you can just mod+arrow your way around with ease.
There was a problem hiding this comment.
well, this is mostly bike-shedding. but here you go:
What if you must press it 45 times? And holding Tab is no good either. While holding it did it triggered 30 times? 40 ? 60?
so what if? why would it matter if tab triggered 30 times, 40 or 60? i really don't care as it eventually gets me there.
and that is very simple to check with Tab-cycling. i just keep the key pressed until the object highlights. then i let go. since i was to slow, i back-cycle 3 times. done.
no symbolic processing involved (as in: relate numbers to objects).
to be fair, it might help to have a more contrasting colour that blue/black.
otoh with goto, if you have a fairly large patch, having numbers splattered all over the patch won't help readability either: so you have random numbers spilled all over the objects which makes it hard to read both the objects (beneath the numbers) and the numbers themselves. 😛
|
Note: At the current state I've changed Find Again to Shift+accel+F and the Go to dialog is assigned to accel+G |
note that "set_indices_visibility" won't go to pdtk_kbdnav.tcl because there is already a binding for kbdnav_toggle_indices_visibility
|
Now the GUI keeps track of which patch is keyboard-navigating and we can have context-sensitive hotkeys. I've also included an entry in the Edit menu to enable/disable keyboard navigation. Some key changes (pun intended)
|
Since moving kbdnav hotkeys to TCL we shouldn't be using kn_moddown. Removing this check allows triggering the "keyboard connect" while kbd-navigating
Also don't mess with toplevel bindings in the "Go To" and "Connect Object" dialogs.
|
Did a cleanup and update of the first post with the current state of things. Recently i just realized that the shift+digits are system/locale dependent. I'm inclined to change it to mod+digits. |
umlaeute
added
feature
This is a prototype branch that allows you to fully navigate and connect your patches with the keyboard. Here is what's new:
Features
doc/7.stuff/keyboard.navigation/keyboard.patching-help.pdI've tried to keep it simple and intuitive. Most of the navigation is done with mod+arrow
Testing is needed in all platforms (I'm testing in Win10 and building with Msys2/MinGW as suggested in (INSTALL.TXT)
TODO
7.stuff/patching/(instead of7.stuff/keyboard.navigation#ifdefsIdeas to discuss