Mike Gorse | 20 Jul 23:45 2014

ANNOUNCE: AT-SPI 2.13.4 released

AT-SPI 2.13.4 is now available for download at:

http://download.gnome.org/sources/at-spi2-core/2.13/
http://download.gnome.org/sources/at-spi2-atk/2.13/

What is AT-SPI2
===============

AT-SPI2 is a D-Bus based accessibility framework. It defines a D-Bus
protocol for providing and accessing application accessibility
information. The project includes a library for bridging the D-Bus
protocol to the ATK API, allowing Gtk based applications to be made
accessible. It also contains a client (AT) side library in C and a wrapper
for Python.

What's changed in AT-SPI 2.13.4

* [core] Ensure that we register with the session manager only once
   (bgo#728934).

* [core] Fix ucs2keysym prototype (bgo#730897).

* [core] introspection: add some missing Returns: (nullable) annotations

* [core] Fix various memory leaks.

* [atk] Fix typo in .pc file (bgo#721719).

* [atk] Fix retrieving text attributes (bgo#731980).

(Continue reading)

Nalin.x.Linux | 25 Jun 16:04 2014
Picon

Accessibility of ibus modules

Dear list,
I am Nalin from kerala/India, i am currently on the process of creating an ibus-engine for braille layout as part of google summer of code 2014 under the organisation swathanthra malayalam computing.It seems that orca screen reader is not announcing ibus-events such as expansion of preedit_string ,lookuptable etc. Currently we solved issue for ibus-sharada-braille engin using python-espeak api. Me with my mentor Samuel thibault discussed about this and we found various ways as follows

1 - make the ibus module speak by itself
2 - make the ibus module show a status bar where it writes what it wants to get spoken
3 - invent a new "input module" role, and events related to what an input module typically does (word expansion, word deletion, etc.)
4 - is there any way to register text event to at-spi via creating invisible accessible object ??

In this scenario please let us know what are the things we have to put forward to make ibus layouts accessible for screen reader users.
Expecting response nalin.

_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Joseph Scheuhammer | 12 Jun 21:00 2014
Picon

Public working drafts release for WAI-ARIA 1.1

Two public working drafts of the WAI-ARIA 1.1 specification, and the 
Core Accessibility API Mappings were released earlier today (Jun 12, 2014):

Link to the W3C announcement:
http://www.w3.org/blog/news/archives/3896

Links to the documents:
http://www.w3.org/TR/2014/WD-wai-aria-1.1-20140612/
http://www.w3.org/TR/2014/WD-core-aam-1.1-20140612/

--

-- 
;;;;joseph.

'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -
This Magpie | 8 May 11:12 2014

java-atk-wrapper

Hi List,

I would like to support the new java wrapper maintainer, Alejandro with the task of maintaining java-atk-wrapper since the whole module needs updating having been abandoned back in 2011[1]. 

The first commit since 2011, were just this week and, it's fair to say that the module has generally got a bit old and suboptimal over time.[2] I reckon it would really be great to put a bit more brainspace and time into improving things for java (by making use of what the most current java API can offer, for example). I won't have much time over the next 3 months but generally, I would like to have a go at helping get java-atk-wrapper up to scratch when I can, as long as that would not be a problem at all.

Does anybody have any thoughts about the module itself?

Many thanks,
Magdalen


_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Patrick Welche | 19 Apr 18:52 2014
Picon
Picon

a11y bus trouble after upgrade

I have been upgrading eg dbus, glib, at-spi2-core etc. and now registryd
won't start. The best test so far, which is I think what
get_accessibility_bus_address_dbus() does in at-spi2-core atspi-misc.c is:

  dbus-send --print-reply --dest=org.a11y.Bus /org/a11y/bus \
  org.a11y.Bus.GetAddress

which returns:

  Error org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus exited with status 1

This suggests that the session bus is running sufficiently to accept a
connection, but then something fails - any clues on how to find out what?

Cheers,

Patrick
Mike Gorse | 15 Apr 00:32 2014

ANNOUNCE: at-spi2-atk 2.12.1 released

At-spi2-atk 2.12.1 is now available for download at:

http://download.gnome.org/sources/at-spi2-atk/2.12/

What is AT-SPI2
===============

AT-SPI2 is a D-Bus based accessibility framework. It defines a D-Bus
protocol for providing and accessing application accessibility
information. The project includes a library for bridging the D-Bus
protocol to the ATK API, allowing Gtk based applications to be made
accessible. It also contains a client (AT) side library in C and a wrapper
for Python.

What's changed in at-spi2-atk 2.12.1

* Clean up socket directories on exit (bgo#684076).

Where can I get more information about AT-SPI2
==============================================

The project wiki is available at:

http://www.a11y.org/d-bus

How can I contribute to AT-SPI2?
================================

We need help testing with Gnome accessibility technologies, improving
performance, and generally tying up loose ends.  The above-referenced page
contains a list of known issues that should be fixed.

IRC   : #a11y on Gimpnet
E-Mail: accessibility-atspi <at> lists.linux-foundation.org

Development repositories can be found at:

git://git.gnome.org/pyatspi2
git://git.gnome.org/at-spi2-core
git://git.gnome.org/at-spi2-atk
Samuel Thibault | 3 Apr 00:10 2014

[Extended call] Accessibility and mobility topic of LSM 2014

Hello,

The call for talks for LSM has been extended up to 15th April, please
consider submitting talks!

Thanks,
Samuel

LSM/RMLL 2014
                 15th Libre Software Meeting
                      July 5-11, 2014
                     Montpellier, France
                   http://2014.rmll.info/
              Call For Papers and Participation
         limited to accessibility and mobility topic
     [we apologize for duplicate receipt of this message]
         Last call before deadline : april *15th* 2014

Sharing of knowledge, freedom of information, community spirit,
exchange of ideas, technological progress: every year the Libre
Software Meeting (LSM) follows the Libre philosophy.

RMLL/LSM is a non-commercial series of conferences, round tables
discussions and practical workshops based on Libre/Free Software and
its uses. Its aim is to provide a platform for Libre/Free Software
users, developers and stakeholders.

Access to LSM is free of charge and open to everyone. The conference
will be held in Montpellier from July 5 to July 11, 2014.

We hereby announce the opportunity to submit papers for selection by
the technical review committee for the RMLL/LSM 2014.

This year we would like to put a particular emphasis on accessibility
on the whole RMLL/LSM event. We will have our usual workshop, as
described below, but we would like to have accessibility talks held
in other sessions too, if possible all of them, as was achieved in
2010 in Bordeaux.  One of the reasons for that is that in France, on
1st January 2015, a law will enter in action to require accessibility
of all public places.  2014 is the last year to get ready for this.

We thus invite you to submit your accessibility talks to other topics
than the health topic, so as to broaden the audience of accessibility
questions.

Concerning our dedicated accessibility and mobility workshop,
to better target the various exchanges that will be taking place,
the programme committee of the accessibility and mobility workshop
proposes several kinds of meetings:

- "Solution" meetings, with conferences  and round tables to present
solutions dedicated to previous areas.

- "State of the art" conferences between practitioners, developers,
scientists and users to discuss about what exists according to the
specific needs of users, what works well or a little less well,
to talk about approaches...

- "Technical" presentations between developers and scientists. This
will allow initiation of exchanges between communities that do not
necessarily have the opportunity to meet and will maybe lead to new
collaborations or projects.

Finally, a workshop area will be available to try out and exchange
tools presented by their authors or by seasoned users of those
solutions.

Information on workshops from last year is available on
- http://schedule2013.rmll.info/programme/sante/accessibilite-autonomie-et-gestion/

Information on the previous global RMLL/LSM emphasis on accessibility
in 2010 is available on
- http://2010.rmll.info/+-Accessibilite,2-+.html

You will be able to attend conferences  on other related issues
such as "System Administration" (like Nagios, GLPI, Cfengine,
...), "Development" (like NoSQL, Lucene, GCC, ...), "Law" (like
Licenses,OpenData, FSF, ...), "Internet" (WebGL, Jabber, Typo3, ...),
... Conferences from last year are available on :
- http://schedule2013.rmll.info/

This year, LSM will have as guiding thread "Free software and you", which
can be particularly suited to the accessibility and mobility topic :)

If you are interested in participating, please submit your presentation
at:
https://2014.rmll.info/Appel-a-conferences

Please feel free to share this information with others people who
may be interested. We welcome your participation and input and look
forward for a valuable meeting. 

Deadlines =========

The following dates are important if you wish to participate to the
call for papers.

Abstract submission: no later than 15th of april 2014

Submission guidelines ====================

Speakers should submit an abstract in English or French ; about 400
words, and in 2 languages if possible. If accepted, this abstract
will be published on the website.

Submissions should be submitted via this form:
https://2014.rmll.info/Appel-a-conferences

Submissions should also include the following:

  * Contact information and Geographical location of presenter
  (country of origin/passport).
  * A brief biography.
  * Any significant presentation and/or educational
  experience/background.
  * For technical topics: Reason why this material is innovative,
  significant or an useful tutorial.
  * Optionally, any outlines or samples of prepared materials.
  * Information whether the submission has already been presented,
  and if so, where.

Personal information will be used exclusively for the sole purpose
of the RMLL/LSM committee and shall not be shared with third parties.

If the paper is not accepted for the main session, it may be accepted
for a short-form or "lightning talk" session.

Travel Assistance ====================

Non-commercial and based upon volunteer work, RMLL/LSM are events with
limited resources. However, speakers who exhibit particular need may
receive a refund for their transportation charges at the discretion
of the selection committee. If you know the estimated cost of the
transportation, providing this will make it easier for us to obtain
a clearer view of the expenses that will be incurred.

Publication on the web site ======================

The abstracts and slides for the conference will be published on
the event web site. The files should use only open formats and the
contents shall be shared under a free license.

Sponsoring ==========

If you wish to support the initiative and gain visibility by sponsoring
this event, please contact us by sending an e-mail to
sponsoring(AT)listes2014.rmll.info

Professionals, organisations and companies wishing to financially
support the RMLL/LSM can find more information on the website:
https://2014.rmll.info/Devenez-partenaire

Web site =================

Event web site :

http://2014.rmll.info/

CfP website :

https://2014.rmll.info/Appel-a-conferences

Best regards,
Programme Commitee of the LSM 2014 accessibility and mobility topic
John Emmas | 27 Mar 12:38 2014
Picon

Version 2 numbering

Hi guys,

I'm a bit confused about the "version 2" numbering for libatk.  I 
noticed this morning that a new branch got created for version 3 (the 
new branch is called "gnome-3-12") and I assume that it's timed to match 
similar libraries (such as glib / glibmm etc) who also just released 
version 3.12

However....  the latest atk branch I can find for version 2 is 
"gnome-2-30" - even though glib and glibmm are now 5 x releases further 
on, at ver 2.40.  Glib and Gtk seem to be developing versions 2 and 3 in 
parallel.  Is that not the case for atk or is there some other 
explanation for why the version 2 branches haven't moved on since 2.30?  
It's not a big problem.  I'm just curious to understand the difference.  
Thanks.

John
Magdalen Berns | 17 Jan 01:40 2014

GNOME Accessibility Mailing Lists

Hi lists,

Sorry for the cross post but this concerns both lists:

gnome-accessibility-devel [1]   

gnome-accessibility-list [2]

Both seem to be described as GNOME accessibility development or
technical discussion lists.

It does seem appropriate to provide a means for users to access support
from developers (and other users) but a bit less appropriate to subject
non-technical users to development threads in the process. So, it might
be a nice idea to:

a) move developer/technical discussion to gnome-accessibility-devel    

b) redefine gnome-accessibility-list as a list for users of the tools
and place to access support in using them instead of a development list.

What do people think about this?

Regards,
Magdalen

[1] https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
[2] https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
magpie | 9 Jan 18:00 2014

[Fwd: Mousetweaks: integrate into GNOME Shell or keep in its current form?]

Happy 2014 everyone,

I thought I'd sent this last week but it came up in the a11y meeting 
today that the email was not in archives so I am resending and hopefully 
this finds everyone well. Further to that I am actually going to cross 
post to the GNOME Shell list (I was not sure whether to do that last 
week so did not) as Alejandro pointed out it is a decision for both 
mousetweaks developers and the GNOME Shell team to make so hopefully 
they will not mind the cross post! I added point 6 but have left the 
rest as it was.

I am bringing the following thread up:

https://mail.gnome.org/archives/gnome-accessibility-devel/2013-November/msg00007.html

It seemed to fizzle out with nothing decided and am hoping to finding 
out what people and hopefully Gerd and Francesco (the mousetweaks 
developers) are thinking now that some dialogue has happened. It would 
be good to find out what can be done for the feature. A few of 
points/questions/concerns on this:

1. I posted this out to both GNOME Shell and a11y lists first off 
(reluctant to keep doing that but feel free to forward this on anyone 
who thinks to do so) yet seems to have been very little comment from 
general group of gnome-shell developers. Will gnome-shell actually want 
this? I am less sure since I have tried quite a few times to get 
Mousetweaks in the menu for this 5 year old bug: 
https://bugzilla.gnome.org/show_bug.cgi?id=589906 and the response so 
far has not seemed very encouraging.

2. Component Maintenance in GNOME Shell. MouseTweaks into GNOME Shell 
might need to make sure that they (or someone at least) is going to be 
practically able to maintain and develop that work after it is in. Two 
reviews are needed for each commit, apparently. Getting one review seems 
pretty impossible, if two reviews are going to needed for bugs which 
arise after mousetweaks lands (assuming it would  there :-) ) Then g-s 
mousetweaks is probably going to have a difficult time keeping up.

3. Francesco seemed to have some reservations as I understood things I 
think he was concerned that implementing mouse-tweaks in gnome-shell 
would lead make Mousetweaks less accessible (i,e. by turning into a 
solution only gnome-users can access. If I got that right, and those 
concerns still exist then it would be good to discuss them a bit more so 
we can pinpoint what exactly might need to be done.

4. I pulled the extents logic rout of the magnifier and made it so the 
query to the component and text interfaces are done solely by the 
tracker, whatever client connects to it should be free to just make use 
of whatever extents it needs without the clients' developer having to 
rewrite existing code. This means mousetweaks should be able to easily 
make use of the focus tracking to perform the hover click actions by 
setting a threshold time and then performing some check to see whether 
an object is in focus long enough to activate a simulated click, I 
suppose. No doubt there is more to this, but I wonder will that help? If 
so I can polish that work off and file a bug for it.

5. GNOME Shell keyboard + mousetweaks. Thoughts?

6. If it does get written to GNOME Shell, would this be better as an 
extension rather than a component?

Best wishes,
Magdalen
Magdalen Berns | 21 Nov 01:18 2013
Picon

Mousetweaks: integrate into GNOME Shell or keep in its current form?

Hi all,

Sorry for the epic email. I was speaking to mclasen and halfline about
the mousetweaks discussion I started in a private email thread with the
MT developers Gerd and Francesco and, rather than ccing people at random
intervals it seems more appropriate to forward to the gnome-shell and
accessibility lists so others can comment!

Hope the thread below makes sense, but just to summarise the discussion
it is about whether or not to build Mousetweaks into GNOME Shell as
there were a couple of of considerations which need to be thrashed out
before a decision can be arrived at. 

Unfortunately I had to paste the thread from different parts or bits
would have got missed so let us know if there's anything too confusing
to figure out from the text below and I can try to help.

Magdalen

Magdalen Berns <magdalenberns <at> gmail.com>
	
22 Oct
		
to Gerd, Francesco
Hi Gerd, Francesco,

How are you both doing? I wonder if you got my email about mousetweaks a
while back? It may have got lost in the lists.

Thanks,
Magdalen
Gerd Kohlberger
	
23 Oct
		
to marmuta, me, Francesco
Hi Magdalen,

yeah I didn't see your mail until now. Sorry. Francesco and I haven't
really talked about the future of mousetweaks since your gsoc mails.
(congratulations by the way)

I think porting mousetweaks in its current form to wayland is not going
to work. To implement hover-click we would need 2 things: a) get global
mouse-motion events and b) synthesize/fake mouse button events. A
regular application can do neither under wayland. I can think of 2 ways
to solve this, either move everything into gnome-shell as you suggest,
or keep mousetweaks as a standalone daemon and use at-spi.

at-spi has API for global mouse-events (AtspiEventListener + "mouse:*"
events) and for faking mouse events (atspi_generate_mouse_event()), but
both operations don't work under wayland at the moment. Until those
things are implemented we can't start our port.

Reimplementing mousetweaks in gnome-shell would have a lot of
advantages. It would be easy to get mouse-events and the click-selection
window could be integrated directly into the chrome. It's currently
impossible to drag things around in the Activites overview, because you
can't change the hover-click type from within the overview. Another
advantage would be that we save a lot of code. Probably 90% of
mousetweaks only deals with being a daemon and getting various events,
the actual hover-click logic is only a tiny part.

There is however one problem, if all the features move into gnome-shell
then mousetweaks becomes a GNOME-only solution. At the moment
mousetweaks works fine on Unity, lxde and even KDE. It can also be used
as a service. For example the default on-screen keyboard on Ubuntu
(onboard) integrates mousetweaks into its interface. You can activate
hover-click and select the different click-types directly with the
keyboard.

I would actually prefer to just start working on a hoverclick.js
component for gnome-shell (or you could Magdalen if you like), but
loosing the onboard integration is a big problem. Francesco, what do you
think? I'm guessing you're not even running gnome-shell.

Cheers.

CC'ing marmuta (main onboard developer)

marmuta, what do you think about droping mousetweaks and also
implementing hover-click? The at-spi dependency is already there and it
might even be easier to do it ourselves than to do ipc with mousetweaks.
It would at least resolve the issues with hiding the click-selection
window.

Magdalen Berns <magdalenberns <at> gmail.com>
	
23 Oct
		
to Gerd, Francesco, marmuta
Hi Gerd,

On 23 October 2013 09:20, Gerd Kohlberger <gerdko <at> gmail.com> wrote:

    Hi Magdalen,

    yeah I didn't see your mail until now. Sorry. Francesco and I
haven't really talked about the future of mousetweaks since your gsoc
mails. (congratulations by the way)

Thanks!

    I think porting mousetweaks in its current form to wayland is not
going to work. To implement hover-click we would need 2 things: a) get
global mouse-motion events and b) synthesize/fake mouse button events. A
regular application can do neither under wayland. I can think of 2 ways
to solve this, either move everything into gnome-shell as you suggest,
or keep mousetweaks as a standalone daemon and use at-spi.

atspi is  now in GNOME Shell too but there are problems because it is
making synchronous calls at the moment.

    at-spi has API for global mouse-events (AtspiEventListener +
"mouse:*" events) and for faking mouse events
(atspi_generate_mouse_event()), but both operations don't work under
wayland at the moment. Until those things are implemented we can't start
our port.

    Reimplementing mousetweaks in gnome-shell would have a lot of
advantages. It would be easy to get mouse-events and the click-selection
window could be integrated directly into the chrome. It's currently
impossible to drag things around in the Activites overview, because you
can't change the hover-click type from within the overview. Another
advantage would be that we save a lot of code. Probably 90% of
mousetweaks only deals with being a daemon and getting various events,
the actual hover-click logic is only a tiny part.

 
I will try this out.

    There is however one problem, if all the features move into
gnome-shell then mousetweaks becomes a GNOME-only solution. At the
moment mousetweaks works fine on Unity, lxde and even KDE. It can also
be used as a service. For example the default on-screen keyboard on
Ubuntu (onboard) integrates mousetweaks into its interface. You can
activate hover-click and select the different click-types directly with
the keyboard.

This might be moving to gnome-shell as well. There was talk of it in
GUADEC but I don't know what was decided.

    I would actually prefer to just start working on a hoverclick.js
component for gnome-shell (or you could Magdalen if you like), but
loosing the onboard integration is a big problem. Francesco, what do you
think? I'm guessing you're not even running gnome-shell.

Me too.

    Cheers.

    CC'ing marmuta (main onboard developer)

    marmuta, what do you think about droping mousetweaks and also
implementing hover-click? The at-spi dependency is already there and it
might even be easier to do it ourselves than to do ipc with mousetweaks.
It would at least resolve the issues with hiding the click-selection
window.

Can I cc Alejandro into this thread as well?
Francesco Fumanti
	
23 Oct
		
to Gerd, me, marmuta
Hi Magdalen,

I am pleased to read that you are still interested in the accessibility
features, and particularly in mousetweaks.

On 2013-10-23 10:20, Gerd Kohlberger wrote:

    Hi Magdalen,

    yeah I didn't see your mail until now. Sorry. Francesco and I
haven't really talked about the future of mousetweaks since your gsoc
mails. (congratulations by the way)

    I think porting mousetweaks in its current form to wayland is not
going to work. To implement hover-click we would need 2 things: a) get
global mouse-motion events and b) synthesize/fake mouse button events. A
regular application can do neither under wayland. I can think of 2 ways
to solve this, either move everything into gnome-shell as you suggest,
or keep mousetweaks as a standalone daemon and use at-spi.

    at-spi has API for global mouse-events (AtspiEventListener +
"mouse:*" events) and for faking mouse events
(atspi_generate_mouse_event()), but both operations don't work under
wayland at the moment. Until those things are implemented we can't start
our port.

    Reimplementing mousetweaks in gnome-shell would have a lot of
advantages. It would be easy to get mouse-events and the click-selection
window could be integrated directly into the chrome. It's currently
impossible to drag things around in the Activites overview, because you
can't change the hover-click type from within the overview. Another
advantage would be that we save a lot of code. Probably 90% of
mousetweaks only deals with being a daemon and getting various events,
the actual hover-click logic is only a tiny part.

    There is however one problem, if all the features move into
gnome-shell then mousetweaks becomes a GNOME-only solution. At the
moment mousetweaks works fine on Unity, lxde and even KDE. It can also
be used as a service. For example the default on-screen keyboard on
Ubuntu (onboard) integrates mousetweaks into its interface. You can
activate hover-click and select the different click-types directly with
the keyboard.

    I would actually prefer to just start working on a hoverclick.js
component for gnome-shell (or you could Magdalen if you like), but
loosing the onboard integration is a big problem. Francesco, what do you
think? I'm guessing you're not even running gnome-shell.

You are right: I have not been running gnome-shell for many months.

The advantages of going GNOME-only seem to be primarily from the point
of view of the implementation. The dwell user would get tied to
gnome-shell unless each desktop environment implements its own click
accessibility features. This would be a clear regression for people
relying on these features compared to the current situation.

Assuming Wayland finally offers the things that the mousetweaks daemon
needs to be able to work. Could mousetweaks not be enhanced that it
checks which display server is running and run for that particular
server if it is already supported by mousetweaks? (I suppose that MIR
might have also to be considered in the near future.) The different
desktop environments could (continue to) use the daemon similarly to how
Onboard is doing it.
Am I missing something, when I assume that gnome-shell could offer some
sort of GUI that uses the mousetweaks daemon as a service?

Going the at-spi2 way: The first incarnation of mousetweaks used the old
at-spi until it was ported to X to remove the at-spi dependency. at-spi2
is a clear improvement in confront to the old at-spi. I see the
advantage of using at-spi2, as (I assume) the daemon does not have to be
adapted to the display servers. The code will probably be simpler and
easier to maintain. But, what are the drawbacks compared to a daemon
based on the display server? I don't have the necessary know-how to
evaluate it, but I wonder whether it will work for example with all the
toolkits.

    CC'ing marmuta (main onboard developer)

    marmuta, what do you think about droping mousetweaks and also
implementing hover-click? The at-spi dependency is already there and it
might even be easier to do it ourselves than to do ipc with mousetweaks.
It would at least resolve the issues with hiding the click-selection
window.

Gerd, does this mean that the implementation of the ipc is more
complicated than the implementation of the click features by using
at-spi2?

Moreover, this leads to the question of whether a mousetweaks based on
at-spi2 makes sense at all, unless we want to avoid that everybody
implements its own version of the click accessibility features.

Cheers,

Francesco

PS: Gerd, could you please add some pieces of information to the
mousetweaks section of the following page?
https://wiki.gnome.org/Accessibility/Wayland
marmuta
	
23 Oct
		
to Francesco, Gerd, me
Technically we probably could, at least until we move on with Onboard
too and start targeting Wayland and/or MIR. I can't tell yet how much of
this would survive the porting, same for all the other X tricks in
Onboard.

Assuming we did it, how would that work with Onboard in gnome-shell?
There are two competing hover-click providers then, would we enable the
gnome way in gnome-shell and fall-back to Onboard's implementation
anywhere else? Wouldn't we then still need to be able to communicate
with the new shell-mousetweaks?
Magdalen Berns <magdalenberns <at> gmail.com>
	
24 Oct
		
to marmuta, Francesco, Gerd
Hi all,

A problem we have is that mousetweaks in its current form won't work
under Wayland. Or at least I do not think so based on what I am finding
out about it. The easiest way to make it work in gnome is to implement
it into GNOME Shell but I do not know whether that could/should mean the
standalone is abandoned altogether. If so that is not ideal.

I do not see a reason to abandon mousetweaks as a standalone (other than
lack of time and resources) but I do not know enough about the what work
(if any) is currently needed for mousetweaks to continue to work in as a
standalone outside of wayland. What can you all tell me about that?

Kind regards,
Magdalen
marmuta
	
25 Oct
		
to me, Francesco, Gerd
Hi,
>
> A problem we have is that mousetweaks in its current form won't work
> under Wayland. Or at least I do not think so based on what I am
> finding out about it.
I'm wondering, is there any way to implement mousetweaks at the evdev
level? Events could probably be generated with /dev/uinput.
> The easiest way to make it work in gnome is to
> implement it into GNOME Shell but I do not know whether that
> could/should mean the standalone is abandoned altogether. If so that
> is not ideal.
>
> I do not see a reason to abandon mousetweaks as a standalone (other
> than lack of time and resources) but I do not know enough about the
> what work (if any) is currently needed for mousetweaks to continue to
> work in as a standalone outside of wayland. What can you all tell me
> about that?
Only Gerd can answer that, but I guess once the main desktops switched
away from X, there will be few incentives to keep maintaining it.
Moving parts of it to Onboard then, as he suggested, may make sense,
because for many desktops there is no other convenient way to enable
mousetweaks anyway.

Here's a thought, though: how about keeping standalone mousetweaks as a
cross-desktop unified interface. It would provide the old functionality
for X-based desktops, but only act as a proxy where desktop specific
implementations are available, e.g. the shell implementation in GNOME
shell. Would that make sense?
>
>
> Kind regards,
> Magdalen

Best regards, M.
Gerd Kohlberger
	
25 Oct
		
to me, Francesco, marmuta
On 23.10.2013 17:16, Magdalen Berns wrote:

    Hi Gerd,

    On 23 October 2013 09:20, Gerd Kohlberger <gerdko <at> gmail.com
<mailto:gerdko <at> gmail.com>> wrote:

        Hi Magdalen,

        yeah I didn't see your mail until now. Sorry. Francesco and I
haven't really talked
        about the future of mousetweaks since your gsoc mails.
(congratulations by the way)

    Thanks!

        I think porting mousetweaks in its current form to wayland is
not going to work. To
        implement hover-click we would need 2 things: a) get global
mouse-motion events and b)
        synthesize/fake mouse button events. A regular application can
do neither under
        wayland. I can think of 2 ways to solve this, either move
everything into gnome-shell
        as you suggest, or keep mousetweaks as a standalone daemon and
use at-spi.

    atspi is  now in GNOME Shell too but there are problems because it
is making synchronous
    calls at the moment.

        at-spi has API for global mouse-events (AtspiEventListener +
"mouse:*" events) and for
        faking mouse events (atspi_generate_mouse_event())__, but both
operations don't work

        under wayland at the moment. Until those things are implemented
we can't start our port.

        Reimplementing mousetweaks in gnome-shell would have a lot of
advantages. It would be
        easy to get mouse-events and the click-selection window could be
integrated directly
        into the chrome. It's currently impossible to drag things around
in the Activites
        overview, because you can't change the hover-click type from
within the overview.
        Another advantage would be that we save a lot of code. Probably
90% of mousetweaks
        only deals with being a daemon and getting various events, the
actual hover-click
        logic is only a tiny part.

    I will try this out.

I found 2 things that don't work in the overview. You can't move windows
between viewports and you can't rearrange the icons in the launcher.
Both things aren't show-stoppers but it would be nice to have everything
work.

        There is however one problem, if all the features move into
gnome-shell then
        mousetweaks becomes a GNOME-only solution. At the moment
mousetweaks works fine on
        Unity, lxde and even KDE. It can also be used as a service. For
example the default
        on-screen keyboard on Ubuntu (onboard) integrates mousetweaks
into its interface. You
        can activate hover-click and select the different click-types
directly with the keyboard.

    This might be moving to gnome-shell as well. There was talk of it in
GUADEC but I don't
    know what was decided.

Do you mean hover-click controls in caribou? This could solve the
overview problem because caribou can pop up there.

        I would actually prefer to just start working on a hoverclick.js
component for
        gnome-shell (or you could Magdalen if you like), but loosing the
onboard integration
        is a big problem. Francesco, what do you think? I'm guessing
you're not even running
        gnome-shell.

    Me too.

        Cheers.

        CC'ing marmuta (main onboard developer)

        marmuta, what do you think about droping mousetweaks and also
implementing
        hover-click? The at-spi dependency is already there and it might
even be easier to do
        it ourselves than to do ipc with mousetweaks. It would at least
resolve the issues
        with hiding the click-selection window.

    Can I cc Alejandro into this thread as well?

Sure. Just cc people you think might be interested.

Cheers.
Gerd Kohlberger
	
25 Oct
		
to marmuta, Francesco, me
Yes that's my main concern. Most mousetweaks users I've had contact with
were using Ubuntu and probably Unity.

        The advantages of going GNOME-only seem to be primarily from the
        point of view of the implementation. The dwell user would get
tied to
        gnome-shell unless each desktop environment implements its own
click
        accessibility features. This would be a clear regression for
people
        relying on these features compared to the current situation.

Yes.

        Assuming Wayland finally offers the things that the mousetweaks
        daemon needs to be able to work. Could mousetweaks not be
enhanced
        that it checks which display server is running and run for that
        particular server if it is already supported by mousetweaks? (I
        suppose that MIR might have also to be considered in the near
        future.) The different desktop environments could (continue to)
use
        the daemon similarly to how Onboard is doing it.

If we only depend on atspi and not use any display server specific
functions then we don't need different backends. The backends would be
in the atspi registry. I don't know if there are any plans for a MIR
backend in atspi.

        Am I missing something, when I assume that gnome-shell could
offer some sort of
        GUI that uses the mousetweaks daemon as a service?

No that would still be possible.

        Going the at-spi2 way: The first incarnation of mousetweaks used
the
        old at-spi until it was ported to X to remove the at-spi
dependency.
        at-spi2 is a clear improvement in confront to the old at-spi. I
see
        the advantage of using at-spi2, as (I assume) the daemon does
not
        have to be adapted to the display servers. The code will
probably be
        simpler and easier to maintain. But, what are the drawbacks
compared
        to a daemon based on the display server? I don't have the
necessary
        know-how to evaluate it, but I wonder whether it will work for
        example with all the toolkits.

The mouse-event parts of atspi are independent from the toolkit support
so that shouldn't be a problem.

I can think of 2 regressions. The cursor animations are X specific and
have to be removed. I don't think it's possible to implement them under
wayland or mir. It could work from within gnome-shell, the shell
magnifier also manipulates the cursor sprite. But I also wouldn't mind
loosing this feature, it never worked reliably even on X. I'm curious,
do any of you see the cursor animations? When hover-click is activated
the mouse cursor should fill up with a color before a click happens.

The other thing are mouse wheel events. Currently mousetweaks stops the
hover-click timer if the wheel is used. eg. if you scroll down on a web
page with the wheel you don't want mousetweaks to randomly click
somewhere in between. atspi only supports button 1-3.

            CC'ing marmuta (main onboard developer)

            marmuta, what do you think about droping mousetweaks and
also
            implementing hover-click? The at-spi dependency is already
there
            and it might even be easier to do it ourselves than to do
ipc with
            mousetweaks. It would at least resolve the issues with
hiding the
            click-selection window.

    Technically we probably could, at least until we move on with
Onboard
    too and start targeting Wayland and/or MIR. I can't tell yet how
much of
    this would survive the porting, same for all the other X tricks in
    Onboard.

Onboard without xkb, xinput and xtest sounds almost impossible.

    Assuming we did it, how would that work with Onboard in gnome-shell?
    There are two competing hover-click providers then, would we enable
the
    gnome way in gnome-shell and fall-back to Onboard's implementation
    anywhere else? Wouldn't we then still need to be able to communicate
    with the new shell-mousetweaks?

I didn't think of that. Maybe always use onboard's and disable the other
one, but that could get complicated fast, particularly if there are
multiple other implementations.

        Gerd, does this mean that the implementation of the ipc is more
        complicated than the implementation of the click features by
using
        at-spi2?

hover-click is really just a timer. If the timer finishes we send a fake
click, if the mouse is moved before that, we reset the timer and start
again. If an app can already get global mouse events and synthesize
clicks then this requires only a couple lines of code.

        Moreover, this leads to the question of whether a mousetweaks
based
        on at-spi2 makes sense at all, unless we want to avoid that
everybody
        implements its own version of the click accessibility features.

Yes, but what I fear will happen is that nobody implements them. We can
work on shell and onboard, but it would disappear everywhere else. With
Canonical's CLA I certainly won't contribute anything to Ubuntu.

Cheers.
Gerd Kohlberger
	
25 Oct
		
to marmuta, me, Francesco
Hi,

On 25.10.2013 02:17, marmuta wrote:

    Hi,

        A problem we have is that mousetweaks in its current form won't
work
        under Wayland. Or at least I do not think so based on what I am
        finding out about it.

    I'm wondering, is there any way to implement mousetweaks at the
evdev
    level? Events could probably be generated with /dev/uinput.

evdev and uinput was my first thought as well. Unfortunately all the
files are root:root, mousetweaks would have to be root or use some sort
of suid helper. It's also complicated to use evdev directly, you need
udev for PNP, figure out the device types yourself and you have to
disconnect from all devices once a VT switch occurs. (requires talking
to the DRM, again root only) Examples for that are in weston-launch.c
and the weston evdev files.

        The easiest way to make it work in gnome is to
        implement it into GNOME Shell but I do not know whether that
        could/should mean the standalone is abandoned altogether. If so
that
        is not ideal.

        I do not see a reason to abandon mousetweaks as a standalone
(other
        than lack of time and resources) but I do not know enough about
the
        what work (if any) is currently needed for mousetweaks to
continue to
        work in as a standalone outside of wayland. What can you all
tell me
        about that?

mousetweaks uses a lot of X specific function calls throughout the code.
All of those would have to be replaced with at-spi equivalents. Once
this is done mousetweaks should work everywhere at-spi does, including
wayland and maybe even MIR in the future. I'll start working on a port
to atspi over the weekend to see if there are any unexpected problems.

    Only Gerd can answer that, but I guess once the main desktops
switched
    away from X, there will be few incentives to keep maintaining it.
    Moving parts of it to Onboard then, as he suggested, may make sense,
    because for many desktops there is no other convenient way to enable
    mousetweaks anyway.

    Here's a thought, though: how about keeping standalone mousetweaks
as a
    cross-desktop unified interface. It would provide the old
functionality
    for X-based desktops, but only act as a proxy where desktop specific
    implementations are available, e.g. the shell implementation in
GNOME
    shell. Would that make sense?

Wouldn't this require that mousetweaks is always installed? It's
installed by default on Ubuntu but I don't know what other distributions
do. In a way gnome-settings-daemon already acts as that proxy. It
monitors the 'dwell-click-enabled' key and launches mousetweaks. Maybe
it could instead check if gnome-shell is running and use mousetweaks
only as a fallback.

Cheers.

        Kind regards,
        Magdalen

    Best regards, M.

Francesco Fumanti
	
25 Oct
		
to Gerd, marmuta, me
Hi,
I am probably wrong, but I interpreted marmuta's remark more broadly:

By standalone mousetweaks, I understood a package containing the daemon
and a standalone gui application that could start and control the daemon
by itself; for example over dbus (I am assuming here, that the daemon
can be started over dbus).

Thus, people on distributions not offering mousetweaks, could install
the package and make use of it through the provided gui application. And
distributions wanting a better integration, could only use the daemon
and offer their own graphical interface.

Cheers,

Francesco
Magdalen Berns <magdalenberns <at> gmail.com>
	
25 Oct
		
to Piñeiro, Francesco, Gerd, marmuta
cc Alejandro

On 25 October 2013 13:59, Francesco Fumanti <francesco.fumanti <at> gmx.net>
wrote:

    Hi,

    On 2013-10-25 13:55, Gerd Kohlberger wrote:

                A problem we have is that mousetweaks in its current
form won't work
                under Wayland. Or at least I do not think so based on
what I am
                finding out about it.

            I'm wondering, is there any way to implement mousetweaks at
the evdev
            level? Events could probably be generated with /dev/uinput.

        evdev and uinput was my first thought as well. Unfortunately all
the files are root:root, mousetweaks would have to be root or use some
sort of suid helper. It's also complicated to use evdev directly, you
need udev for PNP, figure out the device types yourself and you have to
disconnect from all devices once a VT switch occurs. (requires talking
to the DRM, again root only) Examples for that are in weston-launch.c
and the weston evdev files.

                The easiest way to make it work in gnome is to
                implement it into GNOME Shell but I do not know whether
that
                could/should mean the standalone is abandoned
altogether. If so that
                is not ideal.

                I do not see a reason to abandon mousetweaks as a
standalone (other
                than lack of time and resources) but I do not know
enough about the
                what work (if any) is currently needed for mousetweaks
to continue to
                work in as a standalone outside of wayland. What can you
all tell me
                about that?

        mousetweaks uses a lot of X specific function calls throughout
the code. All of those would have to be replaced with at-spi
equivalents. Once this is done mousetweaks should work everywhere at-spi
does, including wayland and maybe even MIR in the future. I'll start
working on a port to atspi over the weekend to see if there are any
unexpected problems.

            Only Gerd can answer that, but I guess once the main
desktops switched
            away from X, there will be few incentives to keep
maintaining it.
            Moving parts of it to Onboard then, as he suggested, may
make sense,
            because for many desktops there is no other convenient way
to enable
            mousetweaks anyway.

            Here's a thought, though: how about keeping standalone
mousetweaks as a
            cross-desktop unified interface. It would provide the old
functionality
            for X-based desktops, but only act as a proxy where desktop
specific
            implementations are available, e.g. the shell implementation
in GNOME
            shell. Would that make sense?

        Wouldn't this require that mousetweaks is always installed? It's
installed by default on Ubuntu but I don't know what other distributions
do. In a way gnome-settings-daemon already acts as that proxy. It
monitors the 'dwell-click-enabled' key and launches mousetweaks. Maybe
it could instead check if gnome-shell is running and use mousetweaks
only as a fallback.

    I am probably wrong, but I interpreted marmuta's remark more
broadly:

    By standalone mousetweaks, I understood a package containing the
daemon and a standalone gui application that could start and control the
daemon by itself; for example over dbus (I am assuming here, that the
daemon can be started over dbus).

    Thus, people on distributions not offering mousetweaks, could
install the package and make use of it through the provided gui
application. And distributions wanting a better integration, could only
use the daemon and offer their own graphical interface.

    Cheers,

    Francesco

Piñeiro
	
25 Oct
		
to jdiggs, me, Francesco, Gerd, marmuta
On 10/25/2013 05:18 PM, Magdalen Berns wrote:
> cc Alejandro

Hi, thanks for the forward.

I  have some comments, suggestions below.

>
>
> On 25 October 2013 13:59, Francesco Fumanti
<francesco.fumanti <at> gmx.net> wrote:
>
>     Hi,
>
>
>     On 2013-10-25 13:55, Gerd Kohlberger wrote:
>
>                 A problem we have is that mousetweaks in its current
form won't work
>                 under Wayland. Or at least I do not think so based on
what I am
>                 finding out about it.
>
>             I'm wondering, is there any way to implement mousetweaks
at the evdev
>             level? Events could probably be generated
with /dev/uinput.
>
>
>         evdev and uinput was my first thought as well. Unfortunately
all the files are root:root, mousetweaks would have to be root or use
some sort of suid helper. It's also complicated to use evdev directly,
you need udev for PNP, figure out the device types yourself and you have
to disconnect from all devices once a VT switch occurs. (requires
talking to the DRM, again root only) Examples for that are in
weston-launch.c and the weston evdev files.
>

Well, although I don't have a lot of experience with Wayland, the
feeling that I have is that the main idea is Wayland being more simple
that X, and moving a lot of the functionality to the clients (example:
window decorators now is a responsibilit of the client), but at the same
time right now is really complex from the client side to implement some
of the stuff that was possible before with X. As far as I understand
that paragrah, before X exposed that functionality, so clients didn't
have to talk directly to evdev/uinput, and now is not possible.

>
>                 The easiest way to make it work in gnome is to
>                 implement it into GNOME Shell but I do not know
whether that
>                 could/should mean the standalone is abandoned
altogether. If so that
>                 is not ideal.
>
>                 I do not see a reason to abandon mousetweaks as a
standalone (other
>                 than lack of time and resources) but I do not know
enough about the
>                 what work (if any) is currently needed for mousetweaks
to continue to
>                 work in as a standalone outside of wayland. What can
you all tell me
>                 about that?
>
>
>         mousetweaks uses a lot of X specific function calls throughout
the code. All of those would have to be replaced with at-spi
equivalents. Once this is done mousetweaks should work everywhere at-spi
does, including wayland and maybe even MIR in the future. I'll start
working on a port to atspi over the weekend to see if there are any
unexpected problems.
>

Well, that idea makes sense in the theory, but there are some problems:
 * On Wayland: there are still several questions about how to implement
some of the current API on Wayland. For example, you mentioned some
problems using evdev/uinput on mousetweaks. I foresee a similar problem
with at-spi (that also runs as a user process).
  * On X: one of the outcomes of investigating how to reimplement some
of the current functionality of at-spi2 on Wayland, is the conclusion
that the usage of X on at-spi is obsolete. Needs and update, and
probably some of the current functionality is not working.
  * at-spi2 itself: other of the outcomes of that investigation is
realizing that at-spi2 API needs an update. Current API is confusing.
Hopefully can be partially solved improving the documentation, but
likely, it would be required to tweak the API itself. Any feedback would
be welcome.

Finally, FWIW, there are some running threads about Wayland and
accessibility on gnome-accessibility-devel list and on the wayland-devel
list itself [1]. Probably it would be good to collaborate publicly on
those discussions, and see what the people with more experience on
Wayland thinks.

Thanks for all this information

Best regards

[1]
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011487.html
marmuta
	
26 Oct
		
to Gerd, Francesco, me
I don't see the animation for the default arrow, but all other cursors,
caret, resizing, etc. fill up with what looks like the orange selection
color.
>
> The other thing are mouse wheel events. Currently mousetweaks stops
> the hover-click timer if the wheel is used. eg. if you scroll down on
> a web page with the wheel you don't want mousetweaks to randomly
> click somewhere in between. atspi only supports button 1-3.

>
> >>
> >>> CC'ing marmuta (main onboard developer)
> >>>
> >>> marmuta, what do you think about droping mousetweaks and also
> >>> implementing hover-click? The at-spi dependency is already there
> >>> and it might even be easier to do it ourselves than to do ipc with
> >>> mousetweaks. It would at least resolve the issues with hiding the
> >>> click-selection window.
> > Technically we probably could, at least until we move on with
> > Onboard too and start targeting Wayland and/or MIR. I can't tell
> > yet how much of this would survive the porting, same for all the
> > other X tricks in Onboard.
>
> Onboard without xkb, xinput and xtest sounds almost impossible.
It won't be easy, I agree, but I suspect there will be alternatives, no
way there won't be a replacement for xkb.
xinput might not be essential, scanner and click generation could
perhaps switch to GdkDevice.
xtest could perhaps be replaced with uinput (daemon?). I have an old
uinput branch of Onboard that kinda worked. If a rudimentary
osk_uinput.c would help you anything with mousetweaks let me know.
Else we could revisit at-spi2 for generating key-strokes, but there's no
consistent separation between press and release, unfortunately.
All the GUI stuff will hopefully just work, I had it start up in Weston
a year ago or so, and it looked alright.

> >
> > Assuming we did it, how would that work with Onboard in gnome-shell?
> > There are two competing hover-click providers then, would we enable
> > the gnome way in gnome-shell and fall-back to Onboard's
> > implementation anywhere else? Wouldn't we then still need to be
> > able to communicate with the new shell-mousetweaks?
>
> I didn't think of that. Maybe always use onboard's and disable the
> other one, but that could get complicated fast, particularly if there
> are multiple other implementations.
I think, if there indeed will be multiple implementations, we better
yield to them in Onboard. No collisions that way and Onboard wouldn't
have to deal with the platform's intricacies. Activities view and the
locked down password dialog in GS come to mind.
> >
> >>
> >> Gerd, does this mean that the implementation of the ipc is more
> >> complicated than the implementation of the click features by using
> >> at-spi2?
> >>
>
> hover-click is really just a timer. If the timer finishes we send a
> fake click, if the mouse is moved before that, we reset the timer and
> start again. If an app can already get global mouse events and
> synthesize clicks then this requires only a couple lines of code.
>
>
> >> Moreover, this leads to the question of whether a mousetweaks based
> >> on at-spi2 makes sense at all, unless we want to avoid that
> >> everybody implements its own version of the click accessibility
> >> features.
>
> Yes, but what I fear will happen is that nobody implements them. We
> can work on shell and onboard, but it would disappear everywhere
> else. With Canonical's CLA I certainly won't contribute anything to
> Ubuntu.
>
> Cheers.
>
Cheers, M.
Gerd Kohlberger
	
28 Oct
		
to marmuta, Francesco, me
Thanks. It's the same here.

        The other thing are mouse wheel events. Currently mousetweaks
stops
        the hover-click timer if the wheel is used. eg. if you scroll
down on
        a web page with the wheel you don't want mousetweaks to randomly
        click somewhere in between. atspi only supports button 1-3.

                    CC'ing marmuta (main onboard developer)

                    marmuta, what do you think about droping mousetweaks
and also
                    implementing hover-click? The at-spi dependency is
already there
                    and it might even be easier to do it ourselves than
to do ipc with
                    mousetweaks. It would at least resolve the issues
with hiding the
                    click-selection window.

            Technically we probably could, at least until we move on
with
            Onboard too and start targeting Wayland and/or MIR. I can't
tell
            yet how much of this would survive the porting, same for all
the
            other X tricks in Onboard.

        Onboard without xkb, xinput and xtest sounds almost impossible.

    It won't be easy, I agree, but I suspect there will be alternatives,
no
    way there won't be a replacement for xkb.
    xinput might not be essential, scanner and click generation could
    perhaps switch to GdkDevice.
    xtest could perhaps be replaced with uinput (daemon?). I have an old
    uinput branch of Onboard that kinda worked. If a rudimentary
    osk_uinput.c would help you anything with mousetweaks let me know.

How did you open fd? I'm getting

gerd <at> box01:~$ ll /dev/uinput
crw------- 1 root root 10, 223 Okt 21 17:34 /dev/uinput

    Else we could revisit at-spi2 for generating key-strokes, but
there's no
    consistent separation between press and release, unfortunately.
    All the GUI stuff will hopefully just work, I had it start up in
Weston
    a year ago or so, and it looked alright.

            Assuming we did it, how would that work with Onboard in
gnome-shell?
            There are two competing hover-click providers then, would we
enable
            the gnome way in gnome-shell and fall-back to Onboard's
            implementation anywhere else? Wouldn't we then still need to
be
            able to communicate with the new shell-mousetweaks?

        I didn't think of that. Maybe always use onboard's and disable
the
        other one, but that could get complicated fast, particularly if
there
        are multiple other implementations.

    I think, if there indeed will be multiple implementations, we better
    yield to them in Onboard. No collisions that way and Onboard
wouldn't
    have to deal with the platform's intricacies. Activities view and
the
    locked down password dialog in GS come to mind.

ok.
Gerd Kohlberger
	
28 Oct
		
to Piñeiro, me, Francesco, marmuta, jdiggs
Hi Alejandro,

On 25.10.2013 18:24, Piñeiro wrote:

    On 10/25/2013 05:18 PM, Magdalen Berns wrote:

        cc Alejandro

    Hi, thanks for the forward.

    I  have some comments, suggestions below.

        On 25 October 2013 13:59, Francesco Fumanti
<francesco.fumanti <at> gmx.net
        <mailto:francesco.fumanti <at> gmx.net>> wrote:

            Hi,

            On 2013-10-25 13:55, Gerd Kohlberger wrote:

                        A problem we have is that mousetweaks in its
current form won't work
                        under Wayland. Or at least I do not think so
based on what I am
                        finding out about it.

                    I'm wondering, is there any way to implement
mousetweaks at the evdev
                    level? Events could probably be generated
with /dev/uinput.

                evdev and uinput was my first thought as well.
Unfortunately all the files are
                root:root, mousetweaks would have to be root or use some
sort of suid helper.
                It's also complicated to use evdev directly, you need
udev for PNP, figure out
                the device types yourself and you have to disconnect
from all devices once a VT
                switch occurs. (requires talking to the DRM, again root
only) Examples for that
                are in weston-launch.c and the weston evdev files.

    Well, although I don't have a lot of experience with Wayland, the
feeling that I have is
    that the main idea is Wayland being more simple that X, and moving a
lot of the
    functionality to the clients (example: window decorators now is a
responsibilit of the
    client), but at the same time right now is really complex from the
client side to
    implement some of the stuff that was possible before with X. As far
as I understand that
    paragrah, before X exposed that functionality, so clients didn't
have to talk directly to
    evdev/uinput, and now is not possible.

On X the XTest extension makes it easy to synthesize mouse events and
you can poll for the mouse position and button state. The code in
mousetweaks to do that is exactly the same as in the at-spi-registryd.
At the time we didn't want to use at-spi because you had to do the
enable a11y/restart the session dance and it seemed better to just
rewrite those parts. But now that a11y is always-on it's just code
duplication.

                        The easiest way to make it work in gnome is to
                        implement it into GNOME Shell but I do not know
whether that
                        could/should mean the standalone is abandoned
altogether. If so that
                        is not ideal.

                        I do not see a reason to abandon mousetweaks as
a standalone (other
                        than lack of time and resources) but I do not
know enough about the
                        what work (if any) is currently needed for
mousetweaks to continue to
                        work in as a standalone outside of wayland. What
can you all tell me
                        about that?

                mousetweaks uses a lot of X specific function calls
throughout the code. All of
                those would have to be replaced with at-spi equivalents.
Once this is done
                mousetweaks should work everywhere at-spi does,
including wayland and maybe even
                MIR in the future. I'll start working on a port to atspi
over the weekend to see
                if there are any unexpected problems.

    Well, that idea makes sense in the theory, but there are some
problems:
      * On Wayland: there are still several questions about how to
implement some of the
    current API on Wayland. For example, you mentioned some problems
using evdev/uinput on
    mousetweaks. I foresee a similar problem with at-spi (that also runs
as a user process).
       * On X: one of the outcomes of investigating how to reimplement
some of the current
    functionality of at-spi2 on Wayland, is the conclusion that the
usage of X on at-spi is
    obsolete. Needs and update, and probably some of the current
functionality is not working.

mousetweaks only uses 2 at-spi functions, the generateMouseEvent method
and an EventListener to listen for "mouse:*" events. Does this mean that
those things will no longer work on X once wayland support is added?

I've now uploaded a new 'wayland' branch to git. On X everything seems
to work as before but on wayland mousetweaks just sits there and waits
for at-spi events that never arrive. And I've also updated the wayland
accessibility page. Hope that's ok.

https://git.gnome.org/browse/mousetweaks/tree/?h=wayland
https://wiki.gnome.org/Accessibility/Wayland

       * at-spi2 itself: other of the outcomes of that investigation is
realizing that at-spi2
    API needs an update. Current API is confusing. Hopefully can be
partially solved improving
    the documentation, but likely, it would be required to tweak the API
itself. Any feedback
    would be welcome.

    Finally, FWIW, there are some running threads about Wayland and
accessibility on
    gnome-accessibility-devel list and on the wayland-devel list itself
[1]. Probably it would
    be good to collaborate publicly on those discussions, and see what
the people with more
    experience on Wayland thinks.

Ok, thanks for the info.

Cheers,
Gerd
marmuta
	
28 Oct
		
to Gerd, Francesco, me
I probably just changed permissions to 666. That code was for
investigating lost key-strokes back then, not really meant to be
shipped. However, when cornered in Wayland/MIR, with uinput the only
way out, I would consider building a uinput daemon that opens the
device as root.
Piñeiro
	
28 Oct
		
to Gerd, me, Francesco, marmuta, jdiggs
Hi,

On 10/28/2013 11:35 AM, Gerd Kohlberger wrote:
> Hi Alejandro,
>
>> Well, although I don't have a lot of experience with Wayland, the
>> feeling that I have is
>> that the main idea is Wayland being more simple that X, and moving a
>> lot of the
>> functionality to the clients (example: window decorators now is a
>> responsibilit of the
>> client), but at the same time right now is really complex from the
>> client side to
>> implement some of the stuff that was possible before with X. As far
>> as I understand that
>> paragrah, before X exposed that functionality, so clients didn't have
>> to talk directly to
>> evdev/uinput, and now is not possible.
>
> On X the XTest extension makes it easy to synthesize mouse events and
> you can poll for the mouse position and button state. The code in
> mousetweaks to do that is exactly the same as in the at-spi-registryd.
> At the time we didn't want to use at-spi because you had to do the
> enable a11y/restart the session dance and it seemed better to just
> rewrite those parts. But now that a11y is always-on it's just code
> duplication.

During GUADEC, Keith Packard, a X developer, attended the accessibility
BOF. He mentioned that using XTest to synthesize mouse events is ok, but
not the best for tracking mouse position. Basically due the need of
polling. He mentioned that it would be better to use recent additions to
X, specifically xinput2. He event bloggued about that:
http://keithp.com/blogs/Cursor_tracking/

Anyway, it is true that if mousetweaks were doing the same that at-spi2,
I agree that just using at-spi2 would be better, to avoid replicate
code.

>>
>> Well, that idea makes sense in the theory, but there are some
problems:
>>   * On Wayland: there are still several questions about how to
>> implement some of the
>> current API on Wayland. For example, you mentioned some problems
>> using evdev/uinput on
>> mousetweaks. I foresee a similar problem with at-spi (that also runs
>> as a user process).
>>    * On X: one of the outcomes of investigating how to reimplement
>> some of the current
>> functionality of at-spi2 on Wayland, is the conclusion that the usage
>> of X on at-spi is
>> obsolete. Needs and update, and probably some of the current
>> functionality is not working.
>
> mousetweaks only uses 2 at-spi functions, the generateMouseEvent
> method and an EventListener to listen for "mouse:*" events. Does this
> mean that those things will no longer work on X once wayland support
> is added?

Sorry if I didn't explain myself properly. What I mentioned about X
doesn't have any relation with adding wayland. What I wanted to say is
that some of the code is using somewhat old X methods that it would be
to replace (ie, with some xinput2 stuff). But we don't foresee any
regression there.

>
> I've now uploaded a new 'wayland' branch to git. On X everything seems
> to work as before

Good to know. As I said, although ideally we would like to update the
code that depends on X, with the proper X methods, we will not do that
if that means a regression. If we do that, we will ping you.

> but on wayland mousetweaks just sits there and waits for at-spi events
> that never arrive.

Well, the problem is that on at-spi2 there are not a equivalent
implementation relying on wayland. Basically, we are on a situation of
not being sure how to do that using just wayland methods, with something
similar to what you commented on previous emails.
> And I've also updated the wayland accessibility page. Hope that's ok.

Yes it is ok, and in fact, welcomed. Thanks for the update.

BR

_______________________________________________
gnome-shell-list mailing list
gnome-shell-list <at> gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list

Gmane