Sure! Go ahead. Find some of us on IRC if you need help.
https://kiwiirc.com/client/irc.freenode.net/?nick=musescore|?#musescore
lasconic
2016-05-14 17:56 GMT+02:00 Samadhi Poornima <
samadhipoornima...@cse.mrt.ac.lk>:
> Hi all,
>
> Sorry about the delayed reply. I just had my exams.
>
> I think we should start with the searchable palette. That is "A shortcut
> to summon the palette filter and type the first couple of letters and all
> the palette items starting from that letter will be listed one below the
> other and the user can traverse through them by pressing the downwards
> arrow. When the required palette is found press enter to display."
>
> Shall I start with familiarizing myself with the code related to this area?
>
> Regards,
> Samadhi.
>
> On 2 May 2016 at 16:37, Andrei Tuicu <andrei.tu...@gmail.com> wrote:
>
>> 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 <m...@outsideshore.com>:
>>
>>> 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
>>> Mscore-developer@lists.sourceforge.net
>>> 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
>> Mscore-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>>
>>
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Mscore-developer mailing list
> Mscore-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
