Re: improving accessibility of 2 dimensional editing areas



Hi,

Thank you for your response. The Ags*Meta widgets are really what I
want. I think the screenreader can tell you what I am going to show
you.

My idea is to implement a key stroke like Ctrl-M to show/hide these
widgets and set focus.

http://git.savannah.nongnu.org/cgit/gsequencer.git/diff/ags/X/editor/ags_notation_meta.h?h=3.1.x
http://git.savannah.nongnu.org/cgit/gsequencer.git/diff/ags/X/editor/ags_automation_meta.h?h=3.1.x
http://git.savannah.nongnu.org/cgit/gsequencer.git/diff/ags/X/editor/ags_wave_meta.h?h=3.1.x

Well about positioning, I have some tool dialogs allowing you to do so.

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/editor/ags_position_notation_cursor_dialog.h?h=3.1.x
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/editor/ags_position_automation_cursor_dialog.h?h=3.1.x
http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/editor/ags_position_wave_cursor_dialog.h?h=3.1.x

So everything is just fine.

best regards,
Joël

On Thu, Jan 23, 2020 at 10:05 AM apinheiro <apinheiro igalia com> wrote:


On 22/1/20 22:14, Joël Krähemann via gnome-accessibility-list wrote:
Hi all,

Hi,



What about extending Atk interfaces to help assisting you to perform
editing within 2 dimensional editing areas?

I am the upstream author of:

http://nongnu.org/gsequencer/

I have 3 editing areas:

http://nongnu.org/gsequencer/api/2.3.2/libgsequencer/AgsNotationEdit.html
http://nongnu.org/gsequencer/api/2.3.2/libgsequencer/AgsAutomationEdit.html
http://nongnu.org/gsequencer/api/2.3.2/libgsequencer/AgsWaveEdit.html

They have all a x-position in common. And some sort of x position,
values and amplitudes.

Well it is a bit more complicated since GSequencer allows you to do
multi-channel editing.

This widget allows you to turn on/off channels:

http://nongnu.org/gsequencer/api/2.3.2/libags-gui/AgsNotebook.html

May be we can implement some new interfaces? Like:

* AtkStreamPosition - giving you the x-offset
* AtkLayerHint - telling you what layer is on/off
* AtkLevel - telling you the y-offset
* AtkMeta - telling you summary of all


I didn't have time to a full check of those editing areas, but just a my
first quick though. Aren't those too many new interfaces? I mean that if
each of those interfaces is going to provide you just one value, perhaps
it would make more sense to re-think them on one/two interfaces instead
of 4.

For example, instead of a new interface AtkStreamPosition, why not a
some new properties (x-offset, etc) on the existing AtkStreamableContent?

Also, as AtkComponent already allows to ask for the object layer,
perhaps extend it to ask for a list of active layers? (unless layers on
your use case is different on what Atk already have).

Also, not sure about AtkMeta. First, who would implement it? The main
container? Also, what kind of summary it would provide? Something like
"number of layers", "number of streams", etc? I think that it would be
valuable somewhat more details there.



and extending:

* AtkValue - to deal with multi-value input/output


So the main container would expose a multi-value AtkValue? what would be
the advantage of this approach over individual elements exposing their
AtkValue?



AtkValue should be able to tell you what value is on what layer.

I think AtkMeta could be powerful, just giving you some string
describing you all kind of settings.

If you have any idea howto improve let me know.

Just as writing this, I recognized that I could do a GtkTable showing
you some strings ...
This would be my AgsMeta might be ;)


best regards,
Joël
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list


[1]
https://developer.gnome.org/atk/stable/AtkComponent.html#atk-component-get-layer




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]