On 06/09/2014 10:03 AM, Andrei Tuicu wrote:
Regarding your questions:
>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.
Yes, it is an option, but Lasconic said that he doesn't want this to
happen.
True, but it's not clear any of had completely thought through the
different possibilities at the time of that discussion - how the
Inspector might different form the toolbars in this respect. This could
well be something you have to implement and play with (or let others
play with) to really get a sense of.
>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?
Here there are two solutions:
One is by default implemented by Qt, everything that has the TabFocus
policy will be added to the tab order. So if I just change the focus
policy for the inspector's elements to TabFocus, when tabbing, when
you get to the end of the toolbar, it will jump directly to the inspector.
The other is the one that we've talked about last week I think. A
shortcut that will change the focus from one subwindow to another so
when I start tabbing, it be limited to the elements of that subwindow
I think it is my turn to not have explained myself clearly :-). I think
I am talking about something different here.
I am talking about what happens if I first click a button in Inspector,
and then press Tab. If you set Inspector's elements to TabFocus, then
clicking an Inspector button won't transfer focus there. That's fine.
But what if the very next thing I do is press Tab? Your current
proposal would presumably to exactly what would have happened if I had
not pressed an Inspector button first - focus will move to the first
toolbar button. That's because at the moment the user presses Tab, the
focus is still in the score subwindow. What I am suggesting is that the
code for Tab could perhaps, if possible, check to see if the user had
"recently" pressed a button (we'll call it "X"), and if so, move focus
to the next button in the tab order ("Y"), *even though focus is not
actually on button X but was actually in the score subwindow). In other
words, if there is a concept of an "active" button, have the Tab key
start focus with the next button after the active button, rather than
the first toolbar.
*In addition* to this, yes, it would nice to have Ctrl+Tab or some other
command move to the next subwindow *once you've already moved focus to a
toolbar or subwindow*. But I'm not talking about what happens after you
transfer focus to the subwindow; I'm talking about what the very first
press of Tab actually does.
BTW, regarding the "in addition" comment - I don't actually to *limit*
tab to only working within the current subwindow. In other words, the
default behavior of Qt is fine - when you reach the end of one
subwindow, move on to the next. That's fine, I think. I just want a
*quicker* way to move to the next subwindow without having to first go
through everything in the current one.
The Windows guidelines for Keyboard UI navigation[0] say the following:
# The TAB key moves the input focus to the next area of an active pane
only if it is not used by any other controls within the window.
# The CTRL+TAB shortcut keys or F6 function key moves the input focus to
the next pane or palette.
# The CTRL+F6 combination moves the input focus to the next window in a
group of related windows or between multiple-document interface (MDI)
windows.
Ah, thanks for the reference. I thought as much regarding Ctrl+Tab, but
that was based more on gut feel & memory of experience than on actually
knowing a specific guideline.
Since CTRL+TAB is used for changing from one tab of score to another,
CTRL+F6 is the next best thing.
As far as I am concerned, Ctrl+Tab should be no different than other
shortcuts here. *If focus is currently in a score tab*, then indeed,
Ctrl+Tab would move to the other. But *if focus is in the toolbar*,
then Ctrl+Tab should move to the Inspector. I guess this is a bit
inconsistent in that it suggests Ctrl+tab should also take you out of
the second score tab and onto the toolbar, and I guess that could be OK
too. In other words, Ctrl+Tab could cycle between ScoreTab1, ScoreTab2,
Toolbar, Inspector, MuseScore Connect, Palette (eventually) and then
back to ScoreTab1. With Shift+Ctrl+Tab moving backwards through that
same cycle. But if the guidelines don't forbid it, I think I'd rather
have two difference cycles. If you start in a score tab, then Ctrl+Tab
just cycles between them. If you start in a Toolbar or other subwindow,
then Ctrl+Tab cycles Toolbar - Inspector - MuseScore Connect. And the
way to move between the two cycles would be Tab - unless the same
guidelines recommend something different.
On the other hand, this might be another area where it makes sense to
implement and play with before deciding.
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
