[Kde-accessibility] my crazy thoughts

[Olaf Jan Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Pupeno]
> Now I'm not thinking of using at-spi directly but to implement our own
> accessibility comunication method (anyway, I plan to take a lot of
> things from at-spi).

Wasn't Bill speaking of using bridging code? I think he said that both=20
AT-SPI and ATK depend on certain Gnome thinks, but that the dependencies=20
could go into the bridge.
If our APIs are close enough to the once AT-SPI or ATK is using, then=20
bridging should be fairly easy.

> Will it be posible to make a bridge to at-spi, yes, it will, everything
> is posible and I think of that bridge while designing whatever I design=
=2E

The bridge could be easier with ATK, or easier with AT-SPI. We could writ=
e=20
an ATK bridge first and change to AT-SPI later, if we find out that there=
=20
are problems.

But before we agree on how to code the bridge, we have to agree on how KD=
E=20
internally handles accessibility. Gunnar's and my idea was to use DCOP,=20
so the bridge could be a DCOP service.

> Will we be tyranic while Gnome isn't?

I think using a new katk that is well-designed, so that it can be bridged=
=20
to atk or at-spi, is all but tyrannic. It is rather good cooperation.

> But if I do an implementation from scratch I'll have some very good
> points that I can't another way, like, using KDE technologies as dcop
> as much as posible.

I never thought putting Gnome depedencies into kde-libs was a good idea.
That's why we talked about writing a bridge...

> Anyway, a bridge could be always built later.

I agree that the bridge only makes sense once we have that framework in=20
place. But writing that bridge should have priority over writing programs=
=20
like knopernicus or kosk, as it might help us sharing effords with the=20
Gnome team.

> As SadEagle said, this is an invasibe development as we'll have to
> touch a lot of things, so, this issue should be taken to kde-core-devel
> as well before deciding anything.

What we can do is to concretely work out possible architectures and then=20
ask TrollTech and kde-core to comment

> I am dreaming, but Qwidgets could be extended using something like
> QAccessible to hold all the information needed and dcop to export all
> that information.

As QAccessible and kde-libs code doing DCOP export already exist, this=20
seems to be a very realistic approach.

The approaches I see are:
1. Extend existing the qt object in DCOP in kde-libs (requires big change=
s=20
in kde-libs)
2.1 Export a new accessibility object in a) DCOP or b) MCOP in kde-libs=20
(requires big changes in kde-libs)
2.2 Export a new accessibility object in a) DCOP or b) MCOP at the=20
application layer. This would not be a long-term solution, but rather a=20
way of trying out things before moving them to 2.1 kde-libs later=20
(requires small changes in kde-libs and an extra library to be imported=20
by KDE programs that wish to be accessible).=20
3.1 Extend QAccessibleObject and export it to a) DCOP or b) MCOP in=20
kde-libs (requires changes to Qt and kde-libs)=20
3.2 Export enhanced QAccessibleObject at the application layer using a)=20
DCOP or b) MCOP to get started and switching to 3.1 later (requires=20
changes to Qt and kde-libs)=20
4. Try to put everything into Qt, so pure Qt applications can use this as=
=20
well

I personally would prefer to go with 3


> I think the main problem here is that the expert here, Bill, is closely
> related to ATK+AT-SPI and GAP development, even working for Sun, right
> Bill ? and on the other hand, the one in charge of making the desition,
> me, is a Pure KDE enthusiast.

I don't see a problem here. Bill suggested bridging code, which would fit=
=20
very well with your idea. Maybe you thought of depending stronger on ATK=20
then Bill ever suggested.

Olaf

- --=20
Olaf Jan Schmidt, KDE Accessibility team

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj3kohMACgkQoLYC8AehV8eB6QCfXScHzBXAC0P8aIgE7li7pp9G
o9MAoMNyJw/lab+4rtUvJ9jJLf7VtEmv
=3DU3xw
-----END PGP SIGNATURE-----