Onscreen keyboard and dwelling in LightDM

Sat Jun 11 09:22:06 UTC 2011

Hi,

Sorry for the late reply; I was afk for a week.

On 31.05.2011 08:25, Robert Ancell wrote:
> On 05/27/2011 07:18 AM, Francesco Fumanti wrote:
>> Hello Robert,
>>
>>
>> You might remember that I already opened a thread about onscreen
>> keyboards, dwelling and display manager shortly before UDS-O. LightDM
>> being the default display manager for Ubuntu 11.10, I would like to
>> ask whether there is already a plan about integrating accessibility
>> features into LightDM?
>
> A frequently asked question!  Yes, we plan for the Ubuntu greeter to be
> as accessible as possible.
>
>> ...
>>
>> As pointer-only users cannot use a hardware keyboard, they need a way
>> to access the onscreen keyboard by using only the pointer. Moreover,
>> there are pointer-only users that are not able to click with a
>> hardware device. These users need a way to activate automatic click,
>> also known as dwell click or hover click, by only moving the pointer
>> to a determined area/spot of the screen and resting there for a little
>> time.
>>
>> For users able to click, the solution is straightforward: simply add
>> an item to the options/accessibility gui that the user can click to
>> open the onscreen keyboard.
>>
>> For users not able to click, a dwellable spot, that enables dwelling
>> is needed. What about using the options/accessibility item itself as
>> the dwellable spot. It could for example work like this: The user
>> moves the pointer to the options/accessibility item and some sort of
>> bubble or notification area with a countdown appears. The bubble
>> informs the user that if he moves the pointer to a specific area of
>> the bubble, automatic clicking will be enabled. Advantages of this
>> approach:
>> - no additional exclusive dwellable spot is necessary
>> - if the user does not react to the bubble, nothing happens
>> - only one item has to be made dwellable in order to enable dwelling  (*)
>> Or course, it should remain possible to open the options/accessibility
>> item as usual by a mouseclick.
>>
>>
>> Ubuntu is shipping an onscreen keyboard and dwelling software since
>> several releases with their default installation. Their names are
>> onboard and mousetweaks and both of them do NOT require at-spi to run.
>> So they can be started and used also when at-spi is not running.
>>
>>
>> (*) Another approach would be to open the options/accessibility item
>> after the timeout and add another dwellable item in the
>> options/accessibility menu/dialog to start dwelling. Meanwhile, I
>> think that marmuta's idea with the "activation area in the bubble" is
>> superior, as it only needs one dwellable spot instead of two. (marmuta
>> is part of the onboard devel team, Gerd is the coder of mousetweaks;
>> both are getting a copy of this email.)
>
> My preference is actually to implement it this way.  It would certainly
> be simpler than providing the dialog.

So, if I get you write, you prefer to do it with two dwellable items: the options menu itself and another item to enable dwelling in the options menu.

When doing it this way, I wonder whether the options menu should not popup immediately when the pointer gets over it and close again when the pointer leaves the popup area. In case it does not popup immediately, there should be some feedback showing the passing dwell time.

Whether to open the options menu immediately or after a delay is a question probably best solved with the ui design team.

The dwell item in the options menu should however only be enabled after a dwell time has past (of course with a feedback while the pointer is resting on the item waiting for the dwell time to pass). I suppose that this way it is less disturbing for users that do not need the dwell feature.

> I'm assuming this would only need to be done once, and as this setting
> would be persistent between logins the cost of the double dwell would
> only occur once.  Do you think this is correct?

Yes, I think that it is correct.

The alternative with a single dwell was mainly to avoid having the developer implement two items that are dwellable by themselves; it was not to save the user from having to perform two dwell operations instead of one in order to enable the dwelling feature.

>> The options/accessibility interface should not only provide a way to
>> start the accessibility tools, but also to quit them. Regarding this,
>> if I remember correctly, mousetweaks has a --login option; Gerd,
>> please correct me if I am wrong.
> I'm not sure what you mean by this.  The design will probably just have
> a drop down list of accessibility options (much like GNOME shell) and
> these could be toggled on and off.

Yes, that is what I meant: it should be possible to toggle the accessibility options on and off.

Moreover, I wanted to let you know that mousetweaks has a --login command line parameter for this. If I remember correctly, mousetweaks forks and goes to the background if the --login parameter is not used; thus the pid returned when it was started is not the final pid of the daemon making it more difficult to kill by pid. Gerd (=mousetweaks developer), please correct me if I am wrong.

>> As far as I could read, LightDM aims to become a cross desktop display
>> manager; thus, I suppose that it should also provide a way for
>> distributions (and users) to replace an accessibility tool that
>> provides a specific feature with another providing that feature; for
>> example some distributions might want to replace the onscreen keyboard
>> named onboard with the onscreen keyboard caribou or florence or even
>> another one.
>>
>>
>> Finally, I suppose that the options/accessibility part of LightDM is
>> also a component of the greeter. Consequently, I wonder whether the
>> persons designing the greeter for Ubuntu are in part the persons
>> responsible for the addition of the options/accessibility items to the
>> display manager? Is there anybody in particular that should also be
>> contacted?
>>
> Actually the accessibility is entirely the responsibility of the greeter
> (so each greeter will have varying levels of a11y).  The Canonical
> design team is designing the greeter for Ubuntu, and I will implement
> it.  I'm collecting requirements for a11y from discussions like this.

LightDM landed yesterday in oneiric. Could you please tell me whether the greeter it is currently using already is the Ubuntu Unity greeter?

> How you can help:
> 1. Open bugs for these requirements on this project
> https://launchpad.net/unity-greeter
> 2. As soon as we have the Unity greeter first version, review it for
> a11y and file bugs/send email.

The launchpad Unity greeter page you linked here above does not allow to file bugs against it. I wonder whether this is because there is no package associated to it yet. Could you please have a look?

Cheers,

Francesco