Issues with collateral window keyboard focus
System: self-compiled under Linux Mint 17, with Qt Lib 5.3 and Qt Creator 3.3.0.
Since about last summer, the management of the keyboard focus among the several windows making up MuseScore has worsened. Some examples:
1) After dragging something from the palette and dropping it on the score or after double-clicking something in the palette, the kbd focus remains on the palette and any following key stroke operates on it (this is inconvenient for any key stroke but particularly annoying for [PgUp]/[PgDn] as they change workspace selection, with very little visual feedback of what happened! I regularly end up with the Basic workspace selected without noticing!)
2) Ditto for Inspector buttons.
3) Ditto after selecting a zoom factor from the zoom drop list (this dates from previous times, but I am listing it here anyway).
I do not see any reason for keeping the focus to any collateral window, after any operation on them, with the only exception of Inspector text boxes (regardless they are for real text or numbers, I imagine the user may want to continue to type into them until he moves away explicitly).
(Note: any operation includes also opening a collateral window: it is surprising that, after having pressed F9 (F8) to open the palette (Inspector), pressing F9 (F8) again, instead of closing it, simply does nothing.)
The whole matter has made working with the keyboard (which is my primary way of working and by far the fastest and more precise) an exercise of patience: after any palette or Inspector operation, I have to [Alt][Tab] to the main window or move the mouse away from its place and click on the main window title bar to restore the proper focus. When revising beaming or ornamentation, this ends up being rather acrobatic...
If there are reason behind the current setup, I am eager to know them and see if a compromise can be reached!
Thanks,
M.
Comments
Well, there are reasons for the changes in general, and it's quite simple: accessibility. The goal is to make MsueScore more usable for blind people, and that requires everything to be doable via keybaord control only. Nothing can require clicking (which requires sight to position the mouse), and it's important also that the the keyboard focus not be lost unnecessarily once it has been transferred somewhere.
That's the general story, and most of the changes should also be positive changes for sighted users. In particular, the Inspector was almost completely unusable via keyboard before these changes, but now it should be a joy to control by keybaord for sighted and blind users alike.
However, it is indeed possible that a small number of the changes might appear to be a hindrance for those of us who are able to see / click things. The goal was to minimize this impact, and I think we largely succeeded. But let's look at your specific concerns individually.
1) I don't understand. What I see happening is a wonderful improvement: immediately after palcing an element via the palette (whether drag & drop or double click), the element just placed is automatically selected and received focus, so you can immediately move it up and down using the arrow keys. And page up/down move the score for me as always. Can you post a very precise series of steps to reproduce what you are seeing (and what OS)?
2) The Inspector change is related to accessibility, but as I said, I see it as a marvelous thing. It means you can now click in a spin box and actually use the arrow keys to spin the box (previously, the arrow keys operated on the score). And tab moves you to the next box, so you can then change the next setting just as easily. The Inspector was almost completely unsuable via keybaord otherwise. So I cannot understand how you could see this change as a bad thing? Again, is there some specific sequence of actions that perhaps doesn't work as well as it could? because surely this basic use case - click a spin box and then have full keybaord control over the Inspector until you release it - is a *huge* improvement for keyboard users. Missing is a simple way to return focus to the score other than by tabbing until you get there or hitting Esc. Obviously, the latter is simpler. Ultimately, the plan is to add a shortcut to move focus to the next window.
3) is, as you mention, not exactly a recent issue. Actually, what *did* change is that you can now operate this control with the keyboard at all; that was formerly impossible. So again, an improvement overall as far as I am concerned. But that does mean you need to explicitly return focus to the score by tabbing until you get there or hitting Esc. Again, the latter is simpler.
In reply to Well, there are reasons for by Marc Sabatella
Case 1 above (palette), sample steps:
1) Create a new score; to be reproducible, I used the "My First Score" template with all default settings, except for 200 initial measures, to be sure to have more than 1 page.
2) Select the first rest of page 2
3) From the palette, add a fermata to that rest (either by drag an drop or by double-clicking)
4) Try [Left], [Right], [PgUp], [PgDn]: none does anything to the score; however, if "Basic" is the current workspace, [PgDn] selects the "Advanced" workspace, if the "Advanced" is current, [PgUp] selects the "Basic" workspace.
5) Click the fermata to restore proper focus: now, arrows and other commands work as expected.
I find the whole LESS accessible than before: I can't see any reason for the score to not gain the kdb focus immediately after doing something with the palette; right now the palette is not navigable with the kbd and even if it was, in my experience the chances you need to move to another element or do something with it before applying another palette commands greatly outnumber the chances to apply several palette commands in sequence to the same element.
________________________________________
Case 2 (inspector): The Inspector WAS in most cases fully usable by keyboard before; tab order was not always set or correct (I myself updated the tab order of several widgets several times; often it gets scrambled when a widget is modified, and I expect this to happen again), not all spin boxes had the proper steps set and so on, but generally speaking it could be used and, in addition, it released the focus in most cases I expected it to do.
Unfortunately, I forgot the details, as a rather long time has passed. However, I am rather sure that, for instance, once upon a time, pressing F8 right after opening the Inspector did close it; now it does not (the key stroke is 'eaten'), a small symptom that focus is now 'harder'.
While I see the reasons for a more strict focus in the Inspector, where the probability of dealing with several of its fields in sequence is higher than for the palette, the need to have a quick and easy way to restore the focus to the main window seems to me rather important: surely clicking on the main window title bar (not anywhere on the window itself, lest this affects the score in some way) is not a proper solution and even using [Alt][Tab] is not the ultimate of accessibility (particularly if you have problems in seeing the [Alt][Tab] selection dlg).
_______________________________________
ESC:
I do not know if you quote this ESC function as a plan or as something which is expected to already work; in my case, it does not: if I press ESC while the focus is on the palette (or the inspector), the current element is unselected and a mouse operation is needed to have a current element again; hardly kdb friendly, I dare say.
Thanks,
M.
In reply to Case 1 above (palette), by Miwarre
Regarding the palette, I think I may have discovered why I am seeing something different from you: it seems it works as I describe (which is to say, correctly) if I have the palette docked, but as you describe (which is to say, incorrectly) if I have it undocked. In which case, that seems to likely to be just a bug that needs fixing. I don't normally work with the palette undocked, but I take it you do? or do you see the incorrect behavior even when docked?
As for the Inspector, it's possible that too used to work differently when undocked, or you might be misremembering, or you might be talking about different changes than I am. But it wasn't just subtle differences in what the step value was or occasional glitches in the tab order. Spinboxes literally did not work at all with the keyboard before the accessibilty work - the score was stealing the focus for the arrow keys. Same with tab. Maybe this was only an issue docked? Now these things work perfectly as far as I can tell - docked or undocked - and I wouldn't want to give that up. And that includes F8 for me - docked or undocked, I can't find any series of steps that will lead to F8 *not* toggling it as expected. So that could be system dependent (I'm testing on Ubuntu with xfce4), or maybe I just need more specific steps to follow.
Anyhow, indeed, a simple way to return focus to the score would be fine. Esc is not ideal as a workaround since you lose the selection, but focus *is* returned to the score for me, as I can verify by press Home or End. As I said, we were planning on having a shortcut to cycle focus from window to window but never got around to it. It's probably not too late to make something happen for 2.0 here.
So here's how I'd summarize:
Palette - currently has a bug where it steal focus only when *undocked*
Inspector / Toolbar - everything is fine docked or undocked as far as I can tell, but a shortcut to explicitly return focus to the score without losing selection would be nice.
Everything else should be greatly improved over where they were before the summer, though. Keybaord control navigation of the Inspector now works whereas before it did not, keyboard navigation of the toolbar is now possible (via Tab to place focus there, might take a few presses depending on what else is open), much cleaning up of tab order in dialogs, etc.
In reply to Regarding the palette, I by Marc Sabatella
Undocked palette focus bug filed as #45331: Palette takes keyboard focus when undocked
In reply to Regarding the palette, I by Marc Sabatella
Undocked: indeed! I was about to do the same test, as I always use undocked palette and inspector (I would undock even the toolbar if I find a way to undock it as a whole).
F8 toggling: I did a few tests. If I dock and then undock the Inspector, F8 works as a toggle. If I start MS with the Inspector undocked (as I always do, usually with the inspector turned off at MS start up), F8 is not a toggle any longer: it turns the inspector on, but does not turn it off until focus is returned to the score (this presumably applies to F9 too, but I didn't try).
Of course, I do not particularly care about the toggle function; I just use it an indicator that something weird is going on.
ESC: the current ESC behaviour is not simply "not ideal", it is useless; returning the focus means returning where I was before, with the same selection and all. If the user has to reconstruct the previous status, it is 'longcut' rather than a shortcut.
This is probably the single most annoying thing I find in the current MS user interface, much more important to my eyes than a way to cycle through all the various windows.
Thanks,
M.
P.S.: my system is described at the beginning of the OP.
EDIT: Thanks for filing the bug! I was about to,but you spared me the effort!
In reply to Undocked: indeed! I was about by Miwarre
OK, great, glad that's sorted out then! I've updated the issue to mention the F8 issue.
I'm currently working on issues with the shortcuts for toggling to time signature, key signature, and symbols palette, also the start center. For the start center, I find that after closing it via Esc, it takes two presses of F4 to reopen. That's because the "checked" status in the menu gets out of sync with the window - the View menu says start center is open even though it is closed. I don't suppose something like that is what is going on with F8 for you, too?
As for Esc, our persepctives probably depend on what exactly one was planning on doing next. I guess you were planning on doing things that would have required navigation, or other operations on the same selection? I guess I tend not to. It might help if you described your use case in more detail, so we can better understand it and try to support it.
As an example, as far as I would have known, a shortcut to cycle the windows would have solved the problem for you, as after two or three presses, you'd be back in the main window with the selection intact. And that's more *generally* useful than a solution that makes it easy to get back to the score window but still equally hard to reach other windows (thinking about accessibility here again). But I guess having it be a single key to return to score *in addition* to the the two-or-three-step method would be a plus.
In reply to OK, great, glad that's sorted by Marc Sabatella
An aside first: you repeatedly expressed your concern for the visually impaired users. I cannot but agree wholeheartedly, being myself not gifted with a good sight. In fact, I find that the current UI requires me to use my eyes and to reach for the mouse more than before, not less. It is possible that this happens simply because now there are more things which can be done than before, spread across more windows; but even this makes navigation among windows more critical.
Multiple F8/F9: the example you describe does not apply; no matter how many times I press F8/F9 after the first, they do not toggle back to previous state; only by moving the focus to the main window they do, in which case the second press toggles the first.
Usage: I normally peruse scores I write (or have written) with MS sequentially, from the beginning (or from a relevant work starting point: a movement, a section, whatever) to the end (or to an equivalent work ending point). Of course, it also occurs to me to occasionally correct or edit a detail at a random location, but the description above greatly outnumber any other workflow. I would be rather surprised if this would not be the case for the great majority of the users: we normally write and we normally read texts sequentially, not by jumping to random locations, unrelated to each other.
So, after applying a palette or Inspector command, the most common (by far!) kind of next operation is to go on sequentially: next note, next chord, whatever. The next common kind of operation is to do something else to the same element. This applies to both the palette and the inspector and both while entering and while editing.
For both kinds of operations described above, loosing the 'current point' and the need to reach to the mouse, move it on the previously selected element(s) and re-select it (as it happens with ESC) is a serious hindrance of the workflow, which may easily increase both the time needed to achieve a task and the possibility of error by a sizeable factor.
The main window is 'main', is the reference point of the great majority of any work done with MS; you constantly 'go back' to it from a variety of other places; a shortcut to do exactly this would be hugely useful; much more, in my perspective, than a shortcut cycling among open windows, as it would require a variable number of strokes to reach any given point, without obvious indications of where you are after any stroke (particularly if you do not have a very good sight, like me).
And I add that it should be a customizable shortcut (not hard-coded at framework level); if not, it should be a simple key stroke, not far from hand home position and not one requiring octopus-like hands to achieve ([LeftShift][RightAlt][LeftCtrl][Q][F12]... ;) ).
I hope this clarifies my sentiments; in fact, these seem to me things so obvious I am surprised I have to clarify them; but, we know, never assume anything!
Thanks,
M.
In reply to An aside first: you by Miwarre
One reason I find it important to clarify these things is that we are seeing very different behaviors. I had never seen the undocked palette bug you describe because I never undock my palette. From where I sit, everything is infinitely *better* than before, and yet clearly you are seeing regressions. So I don't see any way forward except to describe things that may be painfully obvious to each of us but for whatever reason not relevant to the other.
That said, first I want to put some of this into persepctive regarding overall accessibiltiy. I think perhaps you are not fully understanding the extent of the improvements made. As I have said, previously, the Inspector was completely and totally unusable via keybaord before. There was simply no way to operates its controls, no way to navigate from field to field, without the mosue. As I mentioned, arrow keys and tab keys simply did not function. So it wouldn't have mattered if there was a way to return focus to the score or not - the Inspector was useless without a mosue anyhow. Similarly, the toolbar was also completely and totally useless without a mouse. There was no way to activate any of the toolbar buttons using the keyboard. Of course, there were keybaord shortcuts for many of the commands, but blind people generally want to use Tab to navigate the buttons on the interface to find out what is even available, and again, that just plain wasn't possible.
What made this possible was, among other things, changes in focus policy, and while Andrei tried to make these changes have minimal impact on those of us who normally combine mouse and keyboard rather than use keyboard alone, that isn't to say there are no regressions at all.
Still, it is important to keep this in persepctive. MuseScore was virtually completely inaccessible before, whereas now the situation has been improved *enormously*. The toolbar and Inspector were both completely inaccessible from the keyboard. Now they work beautifully. This is a *huge* improvement, one that should completely dwarf whatever small niggles might still remain. Usable beats useless, and it was useless before. But as I have said, for those of us who *can* see and didn't mind needing to also use the mouse when operating the toolbar or Inspector, there may indeed be a few regressions in some details, so let's work to reduce those - but let's not lose sight (sorry) of what an enormous improvement really *has* been made here.
I'll make a separate post regarding specifics to keep this one from getting longer than it is. But I really can't stress enough just how important and valuable the changes that have been made are.
In reply to One reason I find it by Marc Sabatella
It was not my intention to minimize the importance or the thoroughness of Andrei's work about accessibility nor to dismiss the visually impaired audience as marginal: while not being really blind, as I already said, I have myself sight problems (in some country, like Spain, I would actually qualify as blind (somehow latu sensu) and each driving licence renew is kind of a lottery for me; in addition, age does not help...).
That said, I have seen my MuseScore accessibility and usability getting worse and worse over the last year or so, to the point of becoming an exercise of patience and a continuous source of frustration (and the occasional source of errors I would not have done by myself alone...)
The kind of scores I deal with are not mainstream, I am aware of this, as perhaps are the individual operations I routinely perform on them (coloratio? no thanks!). But I doubt my general workflow is inherently much different from the general workflow of more or less anybody else using MS daily and throughout from score concept to printed copy (often not for myself but for other peoples).
This is why I stressed (perhaps more than I am used to) the inconveniences of the current situation.
Thanks,
M.
P.S.: I'll answer your other post very soon.
In reply to It was not my intention to by Miwarre
One more bit of a meta-discussion, if you can stand it!
Obviously, we are both very passionate about making MuseScore as good as it can be. So it doesn't bother me to be having this sort of discussion. I just want to get to the bottom of whatever the issues are. When you say you see your accessibility and usability getting worse and becoming a source of frustration, that pains me as much as I'm sure it does you, so I am equally motivated to help solve the problems!
What I am hoping we find is that actually there will turn out to be a very *short* list of regressions, but that you happen to encounter these regressions more often than I (like the undocked palette focus issue, which I probably *never* would have noticed). But let's get the list as complete as possible, prioritize, and hoepfully knock off as much as we can!
In reply to An aside first: you by Miwarre
On to specifics:
Regarding F8 / F9 - apparently you are seeing a bug I don't see. As I said, for me, the toggles work fine. I guess from what it has to do with whether the window was docked at the moment when MuseScore started up? I would suggest filing issues on that, with complete steps to reproduce *starting from a factory reset*.
It sounds like your usage is * very* different from mine. I am almost using the Inspector "sequentially" as you describe. In fact, I don't tend to use it much at all; I tend to accept defaults for most things. So in my workflow, the Inspector is indeed used more randomly than it apparently is for you. Like maybe only two or three elements per page of music might need any sort of Inspector adjustment at all, so I expect to be clicking to select the things I operate on, as that would be faster than keyboard navigation. If I am just changing leading space before a note in measure 3 and then something about a hairpin in measure 27, I would normally click the note in measure 3, click in Inspector, click the hairpin in measure 27, then click the Inspector again. So the case you are describing just doesn't come up for me. So I'm glad to have this increased understanding.
Anyhow, I *do* understand that a way to return focus to the score without losing selection would be valuable. I am just trying to understand to make sure that whatever form this takes wouldn't mess up anything for you. For instance, if F8 worked as it is supposed to for you - hiding the Inspector if currently visible - and returned focus to the score with selection intact, would that meet your needs? Frankly, it would not meet mine, as I leave the the Inspector open and docked at all times. Having to press F8 to open it every time I wanted to use it would be a step backwards for me. So I am not sure why I suggested this, except to point out that a solution acceptable to one person might not be to another, so it is still important we be as clear as we can.
The "easy" shortcuts are mostly taken already, so unfortunately I'm not sure there would be one we could choose that would be totally to your liking, but yes, it should be customizable. I'm open to suggestions. Assuming it's possible to di it this way at all, that is - Andrei is the one who knows more about focus policy and so forth.
Anyhow, let's keep on with the specifics. We've already discovered the bug with focus on undocked palettes that we never would have known about otherwise. It could be there are other things you are seeing that bother you that are also things that I am simply not seeing, or differences that are just a matter of the difference in our workflow.
Right now, the only issues I know about that are regressions are the palette focus issue that only happens with undocked plaettes, the F8 toggle issue that only happens with specific sequence of docking/undocking operations, and the issue of wanting to return focus to the score after it is in Inspector. That's three very specific things that can hopefully? Is there more?
In reply to On to specifics: Regarding F8 by Marc Sabatella
BTW, this might be naive, but what about using "Esc" itself as the shortcut for "return focus to score"? I have no idea if that's possible, as I think "Esc" gets some special treatment by Qt (maybe just for dialogs), and the whole way the focus model works for the Inspector is not totally clear to me. But if it's feasible, it seems to me it would solve this particular issue nicely. One press of Esc to return focus to score; then a second press would have its usual effect of clearing the selection.
I see this is the shortcut for the same basic purpose in Chrome. It also seems to me that somehow, F5 (usually "refresh") wouldn't be a bad choice here.
In reply to On to specifics: Regarding F8 by Marc Sabatella
It is not evident to me that your inspector usage is structurally different from mine; you probably use it less than I do (I would say I have to modify an inspector value for approx. one element per measure, on average), but you still use it mostly while scanning a score sequentially, whence the need (or at least the usefulness; the more you use it, the greater the need) to return to the same spot to go on.
F8 - Inspector. Should F8 work 'as advertised', it would be a step forward, but not as useful as a dedicated shortcut; me too I tend to keep the inspector open for long runs; not always open, though: as I need to display scores at some zoom level (150% being my default) in order to see them comfortably, I need all the screen real estate I can gain and, particularly while entering or proof reading new music, I tend to keep the inspector always closed, opening it occasionally. OTOH, while editing / correcting, I tend to keep it always open.
Shortcut. It may prove impossible (or impractical) to have such a shortcut customizable: as by definition it deals with intra-window operations, it might be necessary to deal with it at a rather low level, where the MuseScore own shortcut paraphernalia are not readily accessible.
Anyway, if possible, good; if not, any of the candidates you list on your other post would be fine, F5 being the less obvious to me, and the proposed functionality of ESC the most appealing. Just FYI, it seems to me F3 is not currently used by any default shortcut; it could be used for this directly or swapped with another of the Fn keys (mostly used to open collateral windows), if it is reputed more appropriate; probably a bearable change.
Needs: yes, your list covers my important needs in this area; namely, in order of importance (for me at least):
Thanks,
M.
In reply to It is not evident to me that by Miwarre
I think the main thing that is different is that for me, it is far more important to have full keyboard control *while in the Inspector* than it is to have keyboard control of *how I get into and out of the Inspector*. As mentioned, I fully expect to click my way in and out of the Inspector, but once there, I need to have full keyboard control. So for me, trading ease of entry/exit for ease of use once there was a win; for you, it was a loss. But of course, ideally, we have both, so that is what we shall strive for!
I see what you mean about it possibly being impossible for this shortcut to be customizable. Hopefully this is possible to implement at all, and Esc will work. I sort of having this nagging feeling that the subject came up once before and there were complications of some sort. I also agree about F8 weirdness being more symtopmatic of other possible issues than a major issue in itself.
So as for Esc working to return focus from "everywhere else", can we be clear on what "everywhere else" entails? Right now, I think the only other places focus could be is on toolbar (happens if you Tab to it), or in Inspector, or in Selection Filter. Or at least, those should be the only places once the undocked-palette bug is fixed. So there are the places where we'd need this new shortcut to work. My guess is that of these, the toolbar probably doesn't interest you - I'm thinking only the more-or-less completely blind user will ever use the keyboard control of the toolbar, and even, most will use direct keyboard shortcuts where possible.
I have to confess I am often fooled by the Selection Filter and the way it takes focus - Ctrl+C or Ctrl+X after setting the filter don't do anything unless I click in the score, thus losing the very selection I was probably trying to filter. So I'd especially like to see a way out for that. I would be tempted to say I wish it didn't take focus at all, but I am not sure that is consistent with accessibility goals of full keyboard control unless it were to be completely reimplemented to work more like the toolbar.
If you think of any other issues, please don't hesitate to bring it up while there is time to fix for 2.0 - although of course fixing post 2.0 is perfectly possible.
In reply to I think the main thing that by Marc Sabatella
I think we are homing to the target, here; good!
I believe that "everything else" may literally mean "everything else". Ultimately the code for that shortcut would be a
statement. It might mean little or nothing where the focus was before: the inspector, the toolbar, the (master) palette, the selection filter, the mixer..., if the event is intercepted at low enough level. But moving away from the inspector is the case I personally need more.
It just occurred to me that the Master Palette has the same focus-grabbing behaviour of the regular Palette (and it is undocked by default). I do not use it very often, so it is not as much important, but it would be nice to be consistent.
Thanks,
M.
Steps for the Inspector F8 toggle issue
1) Start MuseScore
2) Open the Inspector if it is not already open
3) Undock it, if it is not already undocked
4) Close the Inspector
5) Close MuseScore
6) Re-start MuseScore
7) Open the Inspector with F8
8) Press F8 again
Result: nothing happens
Expected result: the Inspector is closed.
As repeatedly said, this issue is rather minor in itself; it seems to me relevant only as a symptom of some other problem going on with focus and window management.
Thanks,
M.
In reply to Steps for the Inspector F8 by Miwarre
FWIW, I cannot reproduce with those steps (Ubuntu 14.04, xfce4) - Inspector continues to close for me just fine. It continues to do so even if I click in the Inspector after step 7. I jiust can't get F8 to *not* work. So there may be some dependency on other MuseScore settings, I guess, or other OS or window manager dependencies.
But yes, I agree this is not a problem *in itself*, just seems symtomatic of perhaps something else that could potentially be a cause for concern.
With that in mind, I'm still wondering, does a *second* press of F8 close the Inspector? If you go to the View menu, does it show the Inspector as being displayed or not? Does it close with F8 if you click in the score after opening the Inspector, or is F8 then locked out forever? What about after another restart? Just trying to shed light on *where* the problem might be. As I believe I mentioned, I tracked down a related-sounding problem with Start Center where it would not appear after pressing F4 - but it did appear after pressing twice, and it was because the menu action state was out of sync with the actual dialog state (which is to say, it had nothing to do with focus).
In reply to FWIW, I cannot reproduce with by Marc Sabatella
Some answers:
*) The Inspector item in the "View" menu is always in sync with the actual Inspector status, no matter I open / close it.
*) A second F8 press does nothing; I can press F8 any number of times without any effect, until I move the focus back to the main window (for instance to see how the "View" menu shows the Inspector item); after this, F8 closes the Inspector.
*) What do you mean by "another restart"? I have restarted MS countless times and this behaviour never changed.
However, if I dock the Inspector, then F8 works as a toggle and continues to work even if I undock it back. If I close MS with the Inspector still docked, F8 will toggle even after restart. If I close MS with the Inspector undocked, at restart F8 no longer toggles.