I've created this GoogleDoc[0] were I've assigned every action defined in
actions.cpp to its window. I don't know what every action does, so I would
really appreciate if some of you could please take a quick look at it. In
the column named Observations I've put question marks where I'm not certain
that I've corectly assigned the shortcut to its widget.
I only moved actions from the main window to the scoretab and for them I've
set the context to WidgetWithChildren. I see that there are actions that
have effect in to whole application (they have the context Application
shortcut) I've kept those in the main window.
I've granted access to everyone for editing so you can make changes
directly into that document.
Thank you very much!
Andrei
[0]
https://docs.google.com/spreadsheets/d/1RbOLweFvoXxSYrJ-BMFmUiL1_b0lgzJvlDjPbbRcCew/edit?usp=sharing
2014-06-09 20:33 GMT+03:00 Andrei Tuicu <andrei.tu...@gmail.com>:
> 2014-06-09 19:43 GMT+03:00 Marc Sabatella <m...@outsideshore.com>:
>
>
>> 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.
>>
>
> Well the implementation will be ready these days (I'm hoping by tommorow),
> so you and others can try it and give me feedback after playing with it.
> The only thing that I have to do now is assign to every action its window
> and that is the only thing that takes a bit of time, because I have to do
> this in actions.cpp for every action.
>
>>
>>
>> >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
>>
>
> Oh, it seems that I've understood this part completly wrong. :) From the
> knowledge that I have so far, I don't know any way in which I can say
> something like "start from here" for the tabbing order, at least not
> provided out of the box by Qt. I'm sure that I've tried this at one point
> for other purpose, but I'm almost sure that I can find a way at least as
> far as CTRL+TAB is concerned. For the concept of active button, I don't
> think it is possible, but I might be wrong so I'm going to try and maybe I
> will find a way. :)
>
> >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.
>
> Yes, you are right, this is what is happening at the moment, but this
> happens not because the score has focus, but because tabbing order is
> actually the list of objects from the window, in the order in which they
> are created. When pressing tab the first time, Qt looks in that list and
> gives focus to the first object that has the apropriate focus policy. There
> is a function, setTabOrder(Widget* a, Widget* b), but it only changes where
> the focus will be transfered when a gets focus by tabbing. Hmm, I have to
> try and see what setTabOrder(NULL, b) does. It might be the key to do what
> we want. :) For windows that have .ui files it is possible to set where the
> tabbing order will start, but this is a static thing, it is recorded in the
> XML file and cannot be changed programatically. This is what I understand
> so far, but it might not be the whole picture, so I most do some more
> reasearch.
>
> Andrei
>
------------------------------------------------------------------------------
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://p.sf.net/sfu/hpccsystems
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
