Re: inaccessible treeviews and tables

Hello,
Okay I am not going to emit more signals now unless someone will detect 
unexpected behaviour.
As for the context menu issue, the context menu is there, it opens when 
clicking using the right mouse button. However other than using orca's 
features to simulate a right click there is no way on how to popup that 
using keyboard only. Additionally I think providing keyboardaccess to 
popup menus is good practice and even some sighted people are used to it 
so I would like to do that if it's within my abilities.

Oh sorry and I have found out another bit I am missing. While browsing 
the screen using flat review my cells are represented as single 
characters only. So I have no way on how to read it word by word or even 
letter by letter using flat review. I guess I need to implement ATKText 
interface similar way TexCellRenderer does it. What is not obvious to me 
is do I need yet another object or do I just implement methods such as 
get_text, get_character_at_offset etc on my accessible? Isn't there some 
default implementation to inherit from?

Greetings

Peter



On 10.07.2014 15:57, Piñeiro wrote:
> On 07/10/2014 03:06 PM, Peter Vágner wrote:
>> Hello,
>> Thank you verry much again for the help.
>> Now it appears to work as I imagined it to.
>>> However I am still a bit confused on the update_cache method. I have
>>> connected two chat clients on two independent devices. When I changed
>>> name of the contact it resulted of the cell being redrawn and the
>>> change has been noticed when browsing using flat review and also when
>>> navigating using the arrow keys in the treeview.
>> Do I have to emit some signals or that is all up to the toolkit? Or by
>> emitting proper signal can I get ability to announce when the text
>> changes in the given cell when the corresponding row is in focus or
>> it's selected?
> If orca doesnt' get the proper name it can be because an accessible-name
> change is not sent. But you are already saying that the flat review is
> getting all the proper information. So, why emit more signals if you are
> already saying that it is working?
>
>> Previously you have also recommended to implement ref_state_set method
>> on the accessible.
> I used ref_state_set as a example of the usual methods that a custom
> accessible would need to update. Check if the info of the cell is
> correct. If the states are wrong, then you would need to provide a
> custom ref_state_set. If not, it would not needed. But that is common
> sense. If something works, no changes are needed.
>
>> I however feel this is not relevant for the CellRenderer. I am already
>> getting focus and selection events on the treeview column. Or am I
>> missing something more that is usefull and not yet implemented? I
>> understand that for text cell it is usefull because it is possible to
>> indicate whether the text is single line or multi line.
> I can't say if you are missing something. Sorry, I don't have the time
> to test what you are doing. But you are saying that is working for you.
> Again, if it is working, you don't need to fix anything. You started
> this work because you were testing the app and something was failing.
> The bugs that you detected were solved, and the application is working.
> If something is not working, that bug would raise if the users starts to
> use the application, but it is impossible to just foresee that.
>
>> Now a completelly different question. Usually pressing shift+F10 key
>> and / or the applications key (the next to right ctrl key) should open
>> so called context menu, popup menu or right click menu. Is there a
>> standard way on how to implement this or the only way on how to get
>> this working is by looking for keypresses? In default gnome
>> applications it is working like this all over the place however this
>> app does not do this and I am maybe putting wrong keywords to google
>> in order to find out how this is done.
> Shift+F10 is the standard keypress to open the context menu.  But each
> application is free to have or not have a context menu. So when you say
> "this app does not do this", do you mean that have a context menu that
> doesn't open with the standard keybinding or that it doesn't have a
> context menu at all? Because if it is the latter, there is not bug to solve.
>
> BR
>

_______________________________________________
gnome-accessibility-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list