Re: inaccessible treeviews and tables

[Piñeiro <apinheiro igalia com>]

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

-- 
----
Alejandro Piñeiro