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. *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 instance "File | Info" and non-modal dlgs like Inspector). *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. There is one glitch, though: in the Inspector, numeric fields are assumed to be 'spinnable' with arrows, but using arrows, for instance with a note selected, changes the pitch of the note rather than the spin value. Possibly, something to tune in the dlg design? For the rest, I am noting no mis-behaving of key strokes associated with shortcuts. > 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. On one hand, the fact that the Inspector, the Palette and, say, the zoom control keep the focus once open or clicked and do not release it until the user does not clicks on the score window is rather inconvenient (for instance, pressing F8 opens the Inspector, but pressing F8 again does NOT close it). On the other hand, having the Inspector retaining the focus ensures that it can be navigated via the usual keystrokes, without re-clicking on it. > Details [snipped]: > > 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? Q1 - Step 3: Except for the 'spinnable' Inspector values, I am not experiencing any issue with shortcuts using keys also used to navigate dlgs and menus. I don't know if it a Linux-only privilege, but this point seems to me fine as it is. Q2 - window focus: see my doubts above. Would it not rather be the case to have a 'system'-key which would move the focus to the main score window from wherever it is? Once upon the time, F10 used to do something similar in many (Windows?) apps (from the main app window to menus and back). Hoping this can be of some usefulness, Maurizio -- View this message in context: http://dev-list.musescore.org/Keyboard-usability-and-accessibility-tp7578844p7578845.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ 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 Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
