Hello,
I would also like very much for this project to continue, even if I am not
able to help with more than pointers and ideas, at least until I finish my
Bachelor thesis. I think it is a project that has a great impact.
2016-04-27 21:33 GMT+03:00 Marc Sabatella <[email protected]>:
> I am sorry your project did not get selected. We had a limited number of
> slots to fill so there were difficult choices to make. But this project is
> very import to me personally, so I'm definitely still wanting to help with
> this.
>
> Probably what makes sense is to look at the individual problems to be
> solved and come up with a plan as to who will do what and in what order.
>
> I think the two most important areas to look at first are a way to search
> the palettes - akin to the search box we have in the instrument list or
> symbols dialog - and a way to assign direct keybaord shortcuts to
> individual palette elements. My sense is that these two are probably
> pretty unrelated in terms of actual implementation, but should be
> considered together in terms of design.
>
> Andrei's as-yet-unmerged work implemented a third approach - makign the
> *existing* palette navigatable by keybaord - but I'm not sure that ends up
> being necessary if we do the other two things. That is, we were treating
> "keyboard access to palette" as an end goal and he implemented that
> directly. But if I look at the goals a bit differently:
>
> 1) an easy way to find things on palette
> 2) a fast way to apply things from palette
> 3) a way to enter palette items with keyboard only
>
> Palette navigation really doesn't help with 1) or 2). But searchable
> palette and shortcuts pretty much address 3) without the need to modify the
> existing palette code or behavior.
>
I agree with the fact that making palettes searchable and shortcuts will be
extremely helpful when it comes to editing and not only for the visually
impaired users. Traversing all palettes every time one wants to add an
element to the score would be extremely slow. I still think that we'd want
to give the users the option to traverse each element if they want to, but
I might be biased and I might change my opinion once I see the actual the
previous features working. :) Since most of the visually impaired users
will be new to MuseScore, I remember when I personally opened MuseScore for
the first time, after I looked a bit through the toolbar, then I expanded
all the palettes and I spent some time looking what is there. I think that
this is an important step in learning to use MuseScore. In the end, I think
what I am trying to say is that each approach (traverse/search/shortcuts)
will make the palettes usable by visually impaired users without the other
two, but if we want to give them a seamless experience, we need to have all
of them. As I said, I might change my opinion once I see things working. Of
course, it is always better to ask the users. Is MuseScore still working
with RNIB?
In terms of importance and impact, this would be the best place to start,
but probably not the easiest.
> Then, of course, there is also the "next element" command for full
> navigation of all elements - probably pretty easy to implement, actually,
> basically just as your proposal outlines.
>
I don't know if it will be that easy to implement, I think that there will
be a lot of corner cases to take into account, but it is a good place to
learn a big part of the MuseScore's libmscore internals.
> And a way to move keybaord focus from window to window - also hopefuly
> easy but will require familiarity with Qt and maybe Andrei has some good
> insight here.
>
I think this would be the easiest to implement. I would do this as follows:
1. Create a Singleton class FocusManager (or something like that) which
will store a circular linked list of QWidgets (or QObjects, you will have
to find the base class of all the MuseScore's subwindows that you would
like to move keyboard focus to). It will have to offer methods for
adding/removing windows and moving the focus to the next/previous windows.
I guess that you could avoid using the Singleton and store a pointer to the
FocusManger object in the MuseScore
<https://github.com/musescore/MuseScore/blob/master/mscore/musescore.h> object,
which if I remember correctly has only one instance and it is available
from everywhere. I don't know which approach is better.
2. Either create a class FocusManageable which in the
constructor/destructor adds/removes the current object to/from the
FocusManager's list and make each of the MuseScore's subwindow classes
inherit this class as well, or directly add the appropriate call in the
existing constructor/destructor. I personally prefer the first approach,
but you might want to check this with Lasconic and Marc.
3. In the methods for moving the focus to the next/previous window from the
FocusManager you would need to traverse the linked list to find which of
the windows contains the object that currently has focus. To find out what
is the object that currently has focus you can use qApp->focusWidget() and
to find if a window contains that object you would use the isAncestorOf
<http://doc.qt.io/qt-5/qwidget.html#isAncestorOf> method, like here
<https://github.com/musescore/MuseScore/blob/master/mscore/scoreaccessibility.cpp#L191>
.
4. Once you've found which of the windows has focus, you then go through
the list to find the next one that is visible and you set focus to it,
somewhere along these lines
<https://github.com/musescore/MuseScore/blob/master/mscore/scoreaccessibility.cpp#L200-L201>.
Note: you will have to call the activateWindow function as well, because
Windows doesn't allow a window that is not active to gain focus.
5. Create two MuseScore commands with shortcuts to call the methods for
moving the focus to the next/previous subwindow from the FocusManager
object.
There might be some things that I haven't consider, but you would find
those once you start the implementation.
Hope this helps,
Andrei
> Marc
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Mscore-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
