Re: [gdm-list] multiple at-spi starting commands




Francesco:

I'd think there should just be on at-spi-registryd per-user.  You
would need to test and see if there are problems with starting more
than one instance of it.

I realize that this question would have been more appropriate in the accessibility mailing list.

I just tried it and it seems trying to start another instance does not work.

It may work this way today, but there's probably no guarantee that
starting another instance won't cause problems in the future.

I have been told that the automatic start of at-spi-registryd in ubuntu has probably been disabled on purpose because of incompatibilities with certain hardware.

This seems badly broken to me.  What incompatibilities?  Are there
bugs filed about these issues?  I assume that Ubuntu doesn't disable
starting at-spi-registryd in the user's session.  If it works okay
in the session, how does hardware issues create problems for GDM
only?

In Ubuntu there is an option in the Assistive Technology Preferences to start at-spi. Enabling/disabling it requires a logout followed by a login. Trying to start at-spi in the ubuntu gnome session from the terminal does not work; it complains about xevie missing.

Why doesn't Ubuntu fix the bug by either adding xevie Xserver extension
or by fixing at-spi-registryd so it doesn't need xevie (if possible)?

GDM GUI's also must be restarted in order for accessibility features
to take effect.  This is because the daemon needs to start the GUI's
with the modules in this case.  If the GDM has been updated with the
new configuraton option (either by using gdmsetup or by using the
gdmflexiserver --command UPDATE_CONFIG" command), then GDM will start
future GUI's with accessibility.  So if you log in and log back out,
the new GUI should have a11y turned on.

I don't know whether at-spi is enabled by default.

With GDM, it would only be enabled by default if the configuration is
set up to enable the modules.  In SVN, this is off by default.  In the
session, I think different distros make different decisions about
whether to enable a11y.  The pro for doing so is that it is more easily
accessible to users who need a11y features.  The con is that the a11y
infrastructure does impact desktop performance and adds new avenues
for programs to snoop on each other.  I don't think there are any
known malicious exploits, but it is something to be concerned about.
This is why GDM doesn't enable a11y by default in SVN head.

The person who told me that was not sure; he talked about wacom devices. I did not insist further...

It sounds to me like your distro isn't really sure what bug they are
fixing by disabling accessibility in GDM.  There were some bugs when
we first changed the way GDM started at-spi-registryd that caused
some nasty bugs.  They may have added the patch at that time to work
around those bugs.

However, now I think GDM is starting at-spi-registryd properly, so
I'd bet if they reverse that patch that they will have no further
problems.

If they do, I recommend they let the GDM community know about the
problems so we can fix them rather than disabling accessibility
on their platform.

So I will add a gesture to start at-spi. Will I have to make sure that the command to start at-spi is only given once? Or will subsequent commands to start at-spi remain without effect, once at-spi is running?

Starting it via a gesture is less usable and probably prone to error.
I'd recommend working to fix the incompaitibiles with certain hardware
issues.  As a temporary workaround so you can focus on your more
interesting task of integrating onscreen, it's okay.  But it seems a
little odd to expect an end user to know they need to start a
daemon by hand before they can run AT programs.

Yes, I fully agree that it is odd to have a user first start at-spi manualy. First I made the gesture to start mousetweaks also start at-spi; but later I decided to give at-spi its own gesture, because in any case, all this gesture features will require the user to read documentation. So there is no problem to let the user know that he has to start at-spi before starting mousetweaks. (Hence my original idea about gdmgreeter; the intention was to make the user see what is available without having him read documentation).

Lets first get things working with the gesture listeners, then we can
discuss further how to make things available to users who don't read
the documentation.

I'd like to get patches upstream so that configure can identify (or
be configured with options) to specify which on-screen-keyboard
program should be used in the gesture listener configurations.  I'd
like to see that done first.  I'd also like to see this bug on your
platform where at-spi-registryd isn't being started get fixed.

In another email, you suggested that using the same gesture to start stop an application during gdmlogin should be done by the gesture software in gdm itself instead of scripts. This also sounds very sensible. I don't know whether I will be able to do it; I will look later at it... For now, I will propose the version with the scripts that is nearly ready.

The change probably wouldn't be too significant.  Note the code in
gdm2/gui/modules.  The keymouselistener.c file and the dwellmouselistener.c
are the two gesture listener code.  You'll notice the code isn't very large.
It wouldn't be too difficult to make the programs remember which gestures
they've started by process id.  Then it should kill that pid when it
receives the same gesture a second time.  It should probably toggle back
and forth so if I hit the gesture a 3rd time it starts, 4th time it
kills, etc.

Finally, you are also right that fixing the incompatibilities instead of disabling at-spi alltogether would be the better way. Unfortunately, I don't really know what is going on about this...

I'd file a bug against your distro and talk it through with whoever in
your distro is responsible for this area of the code.

You mention you are using Ubuntu.  Others on Ubuntu have complained about
this problem.  Do you not see this?

  http://bugzilla.gnome.org/show_bug.cgi?id=440948

Brian



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