On 06/09/2014 05:54 AM, Maurizio M. Gavioli wrote: > AndreiTuicu wrote >> 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. > I'm using Linux, but I cannot confirm this: > > *Arrows*: I can move around in menus with the arrows, without them affecting > the score.
Menus and dialogs work fine indeed. The issue as described only affects controls within subwindows of the main window - eg, spin boxes in Inspector, as you observed later. This is the same on Linux as on Windows. > . And for dialogs, it's already the case that these are separate > windows*TAB/Shift-TAB*: I can move from one dlg control to the other with TAB > and > Shift-TAB, without affecting the score (both in modal dlgs, like, for Here, he was talking specifically about the toolbar, not dialogs or subwindows. Currently, there is no way to transfer keyboard control to the toolbar in the first place, but that is one of of the changes he made earlier in his code (not yet merged): Tab transfers control from the score to the toolbar, an important requirement for accessibility. > *Ctrl-A*: I can select whole text in dlg text controls and even in score > textual elements (in edit mode) with Ctrl-A without it selecting the whole > score. Here again, the issue is with subwindows only. Try clicking in the Search window in MuseScore Connect, typing some text, then selecting it via Ctrl+A. > 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. > I have no clear idea of the consequences of 1), but I assume you have > studied the matter. > > 2) raises some questions. I believe 2) is necessary to address the consequences of 1) :-). The idea of 1) is that each subwindow - including the score tabs - will "own" its shortcuts, meaning shortcuts are active only while focus is in that window. By default, this might mean that pressing one of the note duration icons would transfer focus to the toolbar, so you'd need to click back in the score to actually enter notes. 2) would be needed to keep focus in score even when pressing toolbar buttons, etc. But you are right that it would be nice to be able to navigate Inspector via keyboard even if initially entering it via clicking. Not sure, but I *think* this could be made to work. By default, I assume pressing Tab would put focus on the first toolbar button, but maybe the code could check to see if something else is "active" and instead transfer focus there. Andrei? Personally, I wouldn't care if clicking in Inspector (or MuseScore Connect) *did* transfer focus there completely. It's really only the toolbars where this definitely should not happen. So that's presumably another option. Marc ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
