2014-05-19 12:25 GMT+03:00 Andrei Tuicu <[email protected]>:
>
>
>
> 2014-05-19 2:56 GMT+03:00 Marc Sabatella <[email protected]>:
>
> On 5/18/2014 4:07 PM, Andrei Tuicu wrote:
>>
>> This is stricly for QActions contained in QMenu objects so this would
>> not affect other areas so it should not affect other areas. Also, they've
>> marked it as an important bug, so I'm assuming that this mean they will fix
>> it.
>>
>>
>> FWIW, there's mention of fixing issues in menus for Windows for 5.3.1 in
>> the blog article lasconic linked to.
>>
>>
>> > I've almost finished with the tabbing in the tool bar. You can see
>> the
>>
>>> > commits in this branch here[3]. I've created a class that inherits the
>>> > QToolButton and adds support for tabbing.
>>>
>>
>> I will start by saying that I have no insight into how the accessibility
>> API works in Qt - that's why I was so keen on finding someone else eager to
>> work on this :-). So hopefully you'll be able to teach me some here as you
>> learn. I'll be of more help to you regarding MuseScore internals as
>> opposed to GUI stuff specifically.
>>
>
> That is ok. :) When I ask you things about Qt internals or accessibility
> it is because I'm hoping you've encountered the same problem as me, but in
> other contexts in your experience.
>
>>
>> With that out of the way, I'm confused as to why it was necessary to
>> subclass QToolButton just to get what I would have thought was standard
>> behavior. Since it wasn't working before, obviously something needed to be
>> done, but this seems odd to me. Now that you've obviously developed some
>> understanding of how these things work, maybe you could point me to a good
>> primer to help me get up to speed on how Qt accessibilty works in general?
>>
>
> Regarding a good primer, unfortunately there is no such thing... First of
> all, the accessibility API does not address basic issues like tabbing, it
> provides a way to generate screen-reader feedback for user defined custom
> widgets. There is a general description about the class ierarchi here[0]
> and a good example here[1], but for the moment this API is not usefull at
> all. It might become usefull when I try to get screen-reader feedback for
> score elements, although at the moment I think that I can do that without
> the API, but I won't know for sure until I start working. The hard part
> (for now) is to do things that should work "out of the box". I know that
> I'm writing very few code, but I'm spending a lot of time researching how
> to do things, by reading class documentation, articles, blogposts and forum
> threads and finding a piece here, a piece there and trying to put them
> together in order to get the expected result. The accessibility issues were
> not addressed by many programers (as I see it) and there is very few code
> examples, I'm usually finding what I'm searching for it unrelated contexts.
>
I forgot the links, sorry!
[0] http://qt-project.org/doc/qt-5/accessible-qwidget.html
[1]
http://www.ranorex.com/blog/enabling-automation-for-custom-qt-widgets-by-adding-accessibility
>
> For example the QToolButton:
> The first thing that I saw when searching about tabbing was the
> setTabOrder(QWidget* a, QWidget* b) function from QWidget, and I've spent
> some hours in trying to use it, but with no luck. Then I've read somewhere
> unrelated about the focus and focusProxy properties of QWidget and I've
> tried combinations of those with setTabOrder. Finally, I've found the
> focusPolicy property which is for some subclasses of QWidget is set for
> NoFocus(this is the case for QToolButton), by default and for other is set
> to other values. There are only to values of this property that alow
> tabbing: TabFocus and StrongFocus(which means that widget can gain focus by
> either tabbing or my mouse click). If the focus policy doesn't have one of
> those 2 values then widget is not included in the tabbing chain, so the
> setTabOrder function doesn't have any effect. Next problem is that even if
> the property is set to one of those values and the focus those change from
> one QToolButton to another, the only way to know what widget had the focus
> was to open the screen-reader and it would tell me the name and description
> of the button that has focus. Also, pressing Enter/Return/Space did not
> trigger the click event. For these last 2 problems I've subclassed the
> QToolButton. I've bassically wrote the code that should have been in Qt in
> the first place. How I've managed to find the informations to get the
> expected behaviour is a whole different story. :)
>
> As you can see it is a very time consuming process of "do{ search, try,
> fail } until success"... At first I thought that this is my fault for being
> new to Qt, but I'm starting to think that it is not the case, since others
> can't help me either on dedicated forums. These is the reason why I've
> decided to write some articles on the blog with my solutions regarding
> these problems.
> Although it is a bit hard, I do have to say that is very rewarding to know
> that not only I'm working on adding support for accessibility in MuseScore,
> but also with these "how to"s I will help others how are trying to provide
> accessibility support. :)
>
>>
>> My first attempt at looking up info on this took me to the documentation
>> for QWidget, where it states:
>>
>> -
>> keyPressEvent<http://qt-project.org/doc/qt-5/qwidget.html#keyPressEvent>()
>> is called whenever a key is pressed, and again when a key has been held
>> down long enough for it to auto-repeat. The *Tab* and *Shift+Tab* keys
>> are only passed to the widget if they are not used by the focus-change
>> mechanisms. To force those keys to be processed by your widget, you must
>> reimplement
>> QWidget::event<http://qt-project.org/doc/qt-5/qwidget.html#event>
>> ().
>> - ...
>> - The default implementation of
>> event<http://qt-project.org/doc/qt-5/qwidget.html#event>()
>> handles *Tab* and *Shift+Tab* (to move the keyboard focus), and
>> passes on most of the other events to one of the more specialized handlers
>> above.
>>
>> This makes it sounds it sound like tabbing *should* have worked out of
>> the box unless we were already reimplementing QWidget::event(). And if we
>> were, wouldn't that be the place to add the proper Tab key handling? It
>> appears from the code in musescore.cpp that we weren't creating
>> QToolButtons directly - we were simply adding actions, which creates
>> QToolButtons automatically. I'm surprised this doesn't work already, but
>> obviously it doesn't. I don't suppose it's as simple as no tab order
>> having been defined? Probably not. Anyhow, your blog would be a good
>> place to record more info about what you've tried and not found successful.
>>
>>
>> As I said, the tabbing works, the default tabbing order is the order in
> which the objects are created, but there was no highlighting and the button
> wasn't clicked when the Return/Enter key was pressed. Yes the addAction
> method creates a new QToolButton and sets the QAction received as parameter
> as *default* action.
>
>> > First one, I could not find how to highlight the button
>>> > like when the cursor is hovering over it
>>>
>>
>> I looked at the QToolButton documentation and saw mention of the
>> setAutoRaise() method - sounds like this is *supposed* to do what you
>> want? It's supposed to be set by default when creating QToolButtons in a
>> QToolbar; maybe that means only when using the addAction method for doing
>> this. Perhaps calling this yourself is all you need?
>>
>
> Although I'm not yet sure what setAutoRaise does, I've tryied using it and
> doesn't do what I need.
>
>>
>>
>> The problem about Return/Enter key seems to be more complicated then I
>> saw it at first. As David said, other programs usually create a whole
>> different state for the program in order to allow keyboard navigation,
>> although I don't really like this and as I understood from you other
>> developers are also not big fans of states and modes, I think we should
>> have a discussion, I think on the IRC channel would be best, about this
>> problem.
>>
>>
>> Do you mean a special state you'd enter upon pressing Tab that puts focus
>> on the toolbar and redefines keyboard shortcuts? If it's only for Enter, I
>> could probably live with this (others will probably disagree). But I also
>> wonder if maybe this is all unnecessary. Instead of trying to make the
>> toolbar itself accessible, maybe it's better just to make sure everything
>> on it has a shortcut accessible in "normal" mode? That's kind of true
>> already. I'm actually more concerned about ability to reach the other
>> sub-windows - Inspector, MuseScore Connect, the Palettes, etc.
>>
> Yes, I was talking about a special state, but for when the ALT button is
> pressed. You can see this for example in Sibelius, or for example in
> Microsoft Word 2010 (and later). But after talking with Jaffar, I
> understand that this is a somewhat new way of handling the keyboard
> navigation and he would preffer if we don't do it this way, so my
> suggestion is that I finish in the way that I've started (without a new
> state) and after I show it to you, we decide how it's best. I'm a bit
> confused here, because the default behavior for a Qt application is to
> select the first menu when ALT key is pressed (I've tryied it and it
> actually works for a new created application), but somehow MuseScore
> overrides this behavior and I'm not sure yet here and how.
>
> This might seem unrelated, but I do have some ideas about highlighting.
> Can you please tell me where is the function that is called when a score
> element (for example note) is selected?
>
>>
>>
>>
>> I wrote the first weekly report. It can be found here.
>>
>> http://andreituicu.wordpress.com/2014/05/18/weeks0-tostring-menus-and-tool-bar/
>>
>>
>> Looks good! Although the title seems to display as raw Javascript?
>>
> No, it is not JavaScript. It was my way of writing a funny title, instead
> of "Week 0: Menus and Tool Bar". :D
> If it not ok, I will change it.
>
> Thank you!
> Andrei
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
