gmane.comp.gnome.accessibility.general

Reminder: 2012/05/24 16:00 CET a11y weekly meeting

Joanmarie Diggs — 2012-05-24T02:31:32

Hey all.

  * Reminder: 2012/05/24 16:00 CET a11y weekly meeting
  * Agenda-in-progress: http://live.gnome.org/Accessibility/Meetings
  * Reminder: Add your agenda items prior to the meeting
  * Subscribe-able Team Calendar: http://bit.ly/GNOME-A11y-Calendar

Be there or be square! ;)
--joanie

Re: A11y for Linux on ARM

Pete Brunet — 2012-05-22T13:43:22

Thanks Piñeiro, Is
http://git.gnome.org/browse/java-atk-wrapper
part of the stack?  Do you know what binary, e.g. SO file, contains this
code?

What automated test tools were used?

Pete

On 5/22/12 4:23 AM, Piñeiro wrote:

Re: A11y for Linux on ARM

Piñeiro — 2012-05-22T09:23:12

GNOME a11y stack was ported to Maemo [1], and some of the devices that
used Maemo, like N810 [2] and N900 [3] were ARM based. Anyway, although
some sniffing, debugging and automated testing tools were used (so the
stack was working), AFAIK, nobody used real end-user ATs like Orca on
those devices.

Taking into account the similarities between Maemo and Meego, I suppose
that it should also work there, and on the recent N9, but I never tested it.

BR

[1] maemo.gitorious.org/hail
[2] http://en.wikipedia.org/wiki/N810
[3] http://en.wikipedia.org/wiki/N900
[4] http://en.wikipedia.org/wiki/Nokia_N9

A11y for Linux on ARM

Pete Brunet — 2012-05-21T17:10:08

Is anyone using a11y support on Linux on ARM?  If so, are there any
issues?  -Pete

Accessibility meeting in Randa,Switzerland

Mario Fux — 2012-05-21T14:46:00

Good morning

I'm a lurker on this list and the main organizer of the Randa Meetings [1]. In 
the first two years we had just KDE people there and last year finally two 
Gnome people (Seif Lotfy and Ryan Lortie).

This year one of the meetings will be about a11y in KDE software and Qt and 
we'd like to have some Gnome people there as well. I know the Gnome world less 
well but I'm sure you organize some kind of sprints from time to time as well.

If you're interested please add yourself to the following doodle where we try 
to find the date which matches best:
http://doodle.com/svghf38ibdg6k9dv

And if you've questions don't hesitated to ask. Oh and please forward this 
mail to lists and persons you think makes sense.

griits & thx
Mario

[1] http://community.kde.org/Sprints/Randa

Re: Tentatively no team meeting 17 May

Juan José Marín Martínez — 2012-05-17T05:15:52

On Jue, 17 de Mayo de 2012, 5:02 am, Joanmarie Diggs dijo:

For me it's ok. Enjoy the free day for those who have it :-)
Cheers,

Tentatively no team meeting 17 May

Joanmarie Diggs — 2012-05-17T03:02:50

Hey all.

The 17th is a bank holiday for some and a vacation day for others. We
don't have anything pressing to discuss tomorrow, so.... Unless anyone
has any objections, let's cancel tomorrow's meeting and resume next week.

Take care.
--joanie

Re: Announcing Orca v3.4.2

Udesh Liyanaarachchi — 2012-05-15T14:49:00

Thanks a lot.. I will join this group and search more.

On Tue, May 15, 2012 at 7:52 PM, Joanmarie Diggs <jdiggs< at >igalia.com> wrote:

Re: Announcing Orca v3.4.2

Joanmarie Diggs — 2012-05-15T14:22:54

Hey Udesh.

From your description, I don't think Orca is relevant. Orca is a screen
reader and presents things to users who are blind or visually impaired
via speech output and/or refreshable braille. Have you connected with
the Simon project?

Project page: http://www.simon-listens.org
KDE A11y list: https://mail.kde.org/mailman/listinfo/kde-accessibility

Hope this helps. Take care.
--joanie

On 05/14/2012 08:40 PM, Udesh Liyanaarachchi wrote:

Re: Announcing Orca v3.4.2

Udesh Liyanaarachchi — 2012-05-15T00:40:47

Great work..!!
Hope I can get a help from Orca to my GSoc project adding voice control for
Banshee  http://tecstuf.blogspot.com/
Any suggestion would be so helpful.

Thanks & Regards,

On Tue, May 15, 2012 at 6:03 AM, Luke Yelavich <themuso< at >ubuntu.com> wrote:

Re: Announcing Orca v3.4.2

Luke Yelavich — 2012-05-15T00:33:12

I am in the process of preparing it for Ubuntu's proposed updates repository, and I'll put out a call for testing when its available.

Luke

Re: Announcing Orca v3.4.2

Robert Cole — 2012-05-14T23:21:08

Taht si great news!

Will this come in Ubuntu's updates, or will I need to get it from Git?

Hope all is well, and thanks for all of the hard work.

On 05/14/2012 03:29 PM, Joanmarie Diggs wrote:

Announcing Orca v3.4.2

Joanmarie Diggs — 2012-05-14T22:29:43

=============
What is Orca?
=============

Orca is a free, open source, flexible, and extensible screen reader
that provides access to the graphical desktop via user-customizable
combinations of speech and refreshable braille.

You can read more about Orca at http://live.gnome.org/Orca.

=========================
What's Changed in 3.4.2?
=========================

General

  * Fix for bug 675522 - incorrect comment for translators

  * Prevent gnome-shell notifications from being double-presented

  * Try to handle metacity timeouts more gracefully

  * Fix for bug 674237 - More unicode errors found with hungarian locale

  * Fix for bug 674693 - Modifier keys pressed alone should interrupt
    speech

  * Prevent Orca from interrupting speech in Anaconda trees

Where can I get it?
===================

http://download.gnome.org/sources/orca/3.4/orca-3.4.2.tar.xz

Enjoy!

Announce: mousetweaks 3.4.2

Francesco Fumanti — 2012-05-14T19:50:06

Dear reader,


A new release of mousetweaks is available; the version number is 3.4.2.

It can be downloaded from:
http://download.gnome.org/sources/mousetweaks/3.4/

Direct download link:
http://download.gnome.org/sources/mousetweaks/3.4/mousetweaks-3.4.2.tar.xz (1.94M)
   sha256sum: 7f8a6ae627edae12e0d5b92926c33191bfa504c1ccaf51195051681aedfa700c

=====================
What is mousetweaks ?
=====================

     Mousetweaks is a package that provides mouse accessibility enhancements
     for the GNOME desktop. These enhancements are:
     
     1. It offers a way to perform the various clicks without using any
     hardware button. (Hover Click)

     2. It allows users to perform a secondary click by keeping the primary
     mousebutton pressed for a determined amount of time. (Simulated
     Secondary Click)

     These enhancements can be accessed through the Universal Access panel
     in the GNOME Control Center or through the command-line interface.


===================
Distribution Notes:
===================

     Mousetweaks is implemented as a daemon that only runs when one of its
     features has been enabled.

     Apart the click-type window that can be used to control the type of
     the next simulated click, there is no graphical user interface
     shipping with mousetweaks. Distributions can create their own
     graphical user interface matching their desktop and use dbus to
     completely control mousetweaks.


=============================
What is new in this release ?
=============================

New and updated translations:

     [id] Andika Triwidada


Many thanks to all contributors.


Best regards,

The MouseTweaks team

Re: what we need from X (was Re: Wayland)

Alan Coopersmith — 2012-05-12T03:46:46

And I've been at a conference this week, so was delayed responding myself.

I hope you don't mind that I've taken the liberty of cc'ing the X.Org
development list so the developers working on the input handling in X
(and even some of the ones working on the input handling in Wayland)
can see and respond to these issues.


I think the two went hand in hand - it wasn't being maintained because it
wasn't seen as generally needed.  Like GNOME, X.Org development is done
either by employees of corporations meeting their corporate needs (in X's
case, mostly OS/distro vendors or graphics/input device vendors) or
volunteers working on the parts that personally interest them or meet
their needs.   And as noted in the mail of mine from 2010, there was
some thought that the more general solutions in later Xinput releases
could be used instead of the special purpose solution in XEvIE.


Unfortunately, I'm not deeply enough involved in the input side to know what
the answers are here - I'm just trying to provide a catalyst to get the right
people talking to each other.  Hopefully the input guys on xorg-devel can
provide some answers, or consider what changes need to be made to Xinput (or
Wayland input) to better meet the needs of accessibility helpers/frameworks.
Thank you for providing such detailed information for them to consider.

Reminder: 2012/05/10 16:00 CET a11y weekly meeting

Joanmarie Diggs — 2012-05-10T02:14:49

Hey all.

  * Reminder: 2012/05/10 16:00 CET a11y weekly meeting
  * Agenda-in-progress: http://live.gnome.org/Accessibility/Meetings
  * Reminder: Add your agenda items prior to the meeting
  * Subscribe-able Team Calendar: http://bit.ly/GNOME-A11y-Calendar

Be there or be square! ;)
--joanie

what we need from X (was Re: Wayland)

Piñeiro — 2012-05-08T12:10:56

Hi Alan, thanks for your mail, and sorry for the delay in my answer, I
have been doing some research.

On 05/07/2012 04:22 PM, Alan Coopersmith wrote:

Well, I was not here when XEvIE was born or was let to die, so probably
the info that I have is incomplete. As I was told, XEvIE was not let die
because nobody required it, but because was maintainerless. In fact,
Daniel Stone mentioned that was somewhat broken since day 1 (see his
comment at the end of my post here [2]). Googling a little, I found this
interesting mail [4] (also written by you). And it seems that main
consumer of XEvIE was gok (in fact, AFAIK, just one app could use XEvIE
at the same time, so at-spi was being used as a kind of wrapper).

Register to global key events on ATK based on server-side key snooping
was added since the beginning at 2001. XEvIE support on at-spi was added
on 2003, and mainly to be used by gok. So I assume (please see my
previous "probably the info that I have is incomplete", correct me if
I'm wrong), that the problem was that XEvIE was hard to maintain (or at
least not really maintained), and the main functionality required was
provided by key snooping on ATK (as Orca was well maintained, gok was
deprecated, and Caribou seems to no require it (yet)). So taking into
account the low amount of resources of the accessibility team, the
conclusion is that live without XEvIE was, not fine, but assumable.

Having said so, I think that we need something like XEvIE. Not the
package, but the functionality, or part of it. As I'm not an X expert, I
can't tell if what X provides now is enough. So after take a look to
what we have on at-spi2-core:
* In order to implement atspi_register_device_event_listener:
* Listen Mouse movement events: calling XQueryPointer on a idle call
(this sounds somewhat hacky and intrusive)
* In order to implement atspi_generate_mouse_event
* Generate Mouse events with XTestFakeRelativeMotionEvent,
XTestFakeButtonEvent, etc
* In order to implement atspi_register_keystroke_listener:
* key snooping on the server side (ATK or Qt)
* In order to implement atspi_generate_keyboard_event:
* Generate key event with XTestFakeKeyEvent

Additionally, in this research I found that right now
atspi_register_device_event_listener only works with mouse events
(improve documentation required). As part of the implementation of this
listener I found a process to get and filter events (on event-source.c)
based on XPending, XNextEvent and XFilterEvent. So I'm not sure if this
could be applied to also listen to key events.

At this moment the priority is getting rid of the server-side
(application-side) key snooping in order to forward key events. So Alan
(or anyone reading), do you think that this could be achievable with X
but without XEviE (Daniel Stone seems to discourage that on my post
comment [2])?

PD: Having said so, X event management in at-spi (and AFAIS in general)
is somewhat messy. For example, as at-spi2 started as a C&P of at-spi
there are still code related with XEviE in spite that since the
beginning was said that it should be removed [5]

[1] https://bugzilla.gnome.org/show_bug.cgi?id=649559#c2
[2]
http://blogs.igalia.com/apinheiro/2012/01/19/atkat-spi2-hackfest-2012-day-1/
[3]
http://mail.opensolaris.org/pipermail/accessibility-discuss/2010-April/000185.html
[4] https://live.gnome.org/Gok
[5]
http://www.linuxfoundation.org/collaborate/workgroups/accessibility/atk/at-spi/at-spi_on_d-bus

Re: Wayland

Alan Coopersmith — 2012-05-07T14:22:59

BTW, from the X.Org developer point of view, one of the reasons we let
XEvIE die was because it didn't seem like anyone required it, or even
really noticed that it had been broken for a couple releases before the
removal.   If there are requirements from X or Wayland that are going
unmet, step 1 is letting the developers of those systems know.

Re: Wayland

Piñeiro — 2012-05-07T10:35:51

Hi Jason,

On 05/07/2012 04:58 AM, Jason White wrote:

As far as I know, no. At least  no Wayland developer provided any
feedback on gnome-accessibility, gnu-accessibility or any other of the
accessibility-related mailing lists I'm subscribed to.

Anyway, we have Wayland in consideration. Some historic context:

We had a brief thread about this on 2010. It started on
gnome-accessibility-list:
https://mail.gnome.org/archives/gnome-accessibility-list/2010-November/msg00054.html

Although it also touched gnome-shell mailing lists.
https://mail.gnome.org/archives/gnome-shell-list/2010-November/msg00040.html

Due this conversation, we include Wayland as one of the things to talk
about in the first ATK/AT-SPI2 hackfest, and we created a bug to track it:
https://bugzilla.gnome.org/show_bug.cgi?id=649556

But the conclusions of the Hackfest didn't provide too much light:
https://bugzilla.gnome.org/show_bug.cgi?id=649556#c1

So we know basic things, like that we want X/Wayland totally transparent
to ATK, and that probably AT-SPI2 will need to take that into account,
but we lack the details. Why we didn't do anything else here? Well,
basically because we are already overwhelmed with other stuff.


Unfourtunately, that means that current GNOME accessibility
infrastructure will not work on Wayland right now.


One of the current problems big problems is related to key events. In a
short, as XEvIE is dead, we can't track key events directly from X
server, so we are doing a key snooping on the application, and
forwarding it via DBUS. This is not really performant, can have some
collateral effects, and is the only remaining thing that makes X not
really transparent to ATK. Since we started to talk about that, I have
asking about how this could be done on Wayland. As you mention that key
handling is still in flux, I guess that it is a good moment to ask.



Thanks for the link, I will read it shortly.

Yes, you are right. It seems that Wayland is the future (not sure if
middle or long term yet), so it is good to really think about it.

Thanks

BR

Wayland

Jason White — 2012-05-07T02:58:33

Are there people with backgrounds in accessibility development working with
the Wayland project?

In particular, the accessibility infrastructure will need to be fully
supported on systems that run Wayland without an X server. The latest Wayland
update that I've read mentions keyboard handling as one of the aspects of
Wayland development that is still in flux, hence there may be opportunities
for those who understand the requirements of AT-SPI 2, Orca etc. in this area to
make their requirements known before the relevant APIs are set.
http://lwn.net/Articles/491509/

I know that it will remain possible to run X as a Wayland client, but, given
the current thinking of X and Wayland developers, the norm will be for desktop
environments to use Wayland directly without an X server.

Brainstorming about Accessible Help

Joanmarie Diggs — 2012-05-03T15:06:53

Hey all.

As discussed during last week's team meeting, Shaun is organizing the
Open Help Conference [1] and would like our input. I have created a
"brainstorming" page on our wiki [2] so folks can jot down ideas. Please
add your thoughts.

Thanks and take care.
--joanie

[1] http://http//openhelpconference.com
[2] http://live.gnome.org/Accessibility/AccessibleHelp