Back to the main page.
Bug 1632 - inventorize common usage of keyboard shortcuts
| Status | CLOSED INVALID |
| Reported | 2012-08-08 13:40:00 +0200 |
| Modified | 2019-08-10 12:29:21 +0200 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Eelke Spaak |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1655 |
Jan-Mathijs Schoffelen - 2012-08-08 13:40:19 +0200
Random things form meeting: Identify what is 'common' Use ismac and ispc (~ismac?) to switch between apple/non-apple specifics? Should be consistent over functions Keyboard shortcuts in reference documentation Make pressing 'h' show the help in the command window?
Eelke Spaak - 2012-08-14 15:19:58 +0200
Renaming this bug to reflect what it is actually about at the moment.
Eelke Spaak - 2012-08-14 15:46:01 +0200
A potentially useful webpage: http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts For now, I have inventorized the following keyboard shortcuts that might be of use in FT plots. Wherever I have mentioned Ctrl, the Mac equivalent would be to use the Apple-icon key. Ctrl++ - Zoom in Ctrl+- - Zoom out Ctrl+0 - Reset zoom to default These are pretty much the default everywhere. However, in many cases zooming is twodimensional, while we want to have a one-dimensional zoom functionality. I propose to make the above keys implement a vertical zoom (so a data display scaling), while Shift+the above combinations implement horizontal zoom (so usually a time display scaling). I don't think there is a "common usage"/"best practice" concerning multiple one-dimensional zoom keyboard shortcuts. Arrow keys: nudge the data by small amounts. Shift + Arrow keys: nudge the data by larger amounts. Left/right should nudge through time; I imagine up/down keys to nudge through channels/components in the databrowser. Also to keep in mind: when creating user interfaces, Tab should be useable to navigate to the intuitively next interface element (and Shift+Tab to the previous one). Not sure whether this is implemented automatically in Matlab interfaces. That's actually it for now. A bit less than I was hoping for/expecting. Any other functionalities that might require keyboard shortcuts?
Robert Oostenveld - 2012-08-15 09:54:19 +0200
For bug #1644 Arjen had to get an example on how to deal with keyboard input in the realtime headlocalizer GUI. For that I found these functions that seem to do something with it: manzana> grep -i KeyPressFcn *.m ft_analysisprotocol.m: set(fig, 'KeyPressFcn', @key); ft_databrowser.m:set(h, 'KeyPressFcn', @keyboard_cb); ft_multiplotTFR.m: set(gcf, 'KeyPressFcn', {@key_sub, zmin, zmax}) ft_singleplotER.m: set(gcf, 'keypressfcn', {@key_sub, xmin, xmax, ymin, ymax}) ft_singleplotTFR.m: set(gcf, 'KeyPressFcn', {@key_sub, zmin, zmax}) ft_topoplotTFR.m: set(gcf, 'KeyPressFcn', {@key_sub, zmin, zmax}) Explaining them to Arjen, I realized that there are some functions that make a figure and then get stuck in a while loop (ft_realtime_headlocalizer, ft_sourceplot) and some functions that immediately return (a.o. multiplot). As far as I know ft_databrowser is the only one in which the behavior regarding returning to the command line depends on the users specification of the function call. If the user specifies an output argument, it does not return (but rather waits until the user clicked all artifacts), if the user specifies no output argument it returns immediately. This "return to command line" behavior should be made consistent over functions (and hence included in the guidelines).
Robert Oostenveld - 2012-08-15 10:05:23 +0200
furthermore, the following functions are presently using mouse button callback functions for user interaction: manzana> grep -li WindowButton.*Fcn *.m */*.m ft_analysisprotocol.m ft_databrowser.m ft_multiplotER.m ft_multiplotTFR.m ft_singleplotER.m ft_singleplotTFR.m ft_topoplotTFR.m compat/ft_databrowser_old.m plotting/ft_select_channel.m plotting/ft_select_range.m plotting/ft_select_voxel.m private/arrow.m private/moviefunction.m private/prepare_mesh_manual.m private/rejectvisual_channel.m private/rejectvisual_trial.m The fieldtrip GUI guideline should also describe whether the mouse button down or the button up (seems more common in other apps) should trigger the action. See also https://developer.apple.com/library/mac/#documentation/userexperience/Conceptual/AppleHIGuidelines/Intro/Intro.html http://msdn.microsoft.com/en-us/library/windows/desktop/aa511258.aspx http://developer.gnome.org/hig-book/3.5/ http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html Typical is that I was not able to find similar KDE human interface guidelines.
Eelke Spaak - 2014-01-29 15:19:03 +0100
not a proper bug, and anyway what it was about has been fixed
- 2014-07-09 14:14:36 +0200
copy relevant sections of this bug's comments to the code guidelines