Hello, everyone!
In order to make add accessibility and make everything work as expected I
think that the whole mechanism of shorcuts and actions should be
restructured a bit.
In my opinion these are the main problems of the current implementation:
- all the shortcuts are global
- (optional) the user can set assign any shortcut to an action without any
restrictions
So this is what happens:
If for example I select a button using TAB and press Return, the button
will not be clicked, instead the system break action will be triggered. If
I'm editing text in a textbox and press CTRL+A I'm not selecting the whole
text, instead I'm triggering the action that selects all the elements from
the score.
After talking to Marc and Lasconic I propose the following solution:
1. Move every QAction that affects the score in the ScoreTab object and
change their shorcutcontext from WindowShortcut to , leaving in the
MuseScore object (Main window) just those that open subwindows, dialogs,etc.
2. Set the focus policy for all the other subwindows of the main window so
that the they don't receive focus by clicking on their elements (except for
the case when text editing is necesary)
3. (optional) Restrict the user from assigning keys like Return, Tab, Arrow
keys as shortcuts.
Details:
For 1. I will create a global enum that will specify for what
window/object is the QAction intended. In this way, if in the future other
actions will be added that are supposed to go in other objects, the only
thing that will be needed is to add a new value for that enum. Since every
action is instantiated in the action.cpp file using a Shortcut object, I
will put a variable of that enum type as field in the Shortcut object.
For 2. : Since all actions are in the main window at the moment and their
shortcut context is WindowShortcut, the focus *appears* to be always in the
scoretab. In order to preserve this behavior where this is desired and
avoid the bad examples I've given above I need to set the focus policy for
all the other objects so that they don't give away the focus to other
elements. It would be nice to set a property for scoretab so that it
doesn't give away the focus, but this is not possible. The only usecase I
see when the focus should leave the scoretab is when editing text in
another subwindow.
For 3: This step is debatable. With the default shortcuts assigned in the
way they are now, everything will work as desired, but this doesn't mean
that a user cannot reassign keys like: Return, Tab, Arrow keys as shortcuts
for other actions and create problems. This is a question if we consider
that is MuseScore's responsability to restrict the user from poorly
assigning shortcuts, or it is the user's responsability. In the first case,
the above mentioned keys will be handled like KeyPressEvents in the
scoretab object and their behavior for the scoretab will be hardcoded.
I would like your opinions regarding the following:
Q1: What do you think about step 3?
Q2: Do you know other usecases in which the scoretab should give away the
focus, except when editing text?
Beside my two questions I would very much appereciate any comments
regarding my suggestion, or if you have other questions they are all
wellcome. :)
I've implemented a part of this solution and I've done some tests and all
seems to be working as expected.
Thank you very much!
Andrei
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
