<...snip...> > This lead us to three main tasks: > - - Qt: Creation and extention of QAccessible and family, it would be like > porting qaccessible_win32.cpp into qaccessible_unix.cpp but it won't be that > easy. qaccessible_win32.cpp depends on Win32, but that's not a problem. But > for qaccessible_unix.cpp we cannot say it simple will depend on Unix, it will > depend on ATK + AT-SPI + CORBA which leads to glib, Gnome and I don't think > Trolltech would accept this (Volker ?). So, I thought to do it plug in based. > So QATK would be a plug in. This plug in will depend on Qt and on glib and > will be developed outside Qt and will be loaded by qt if configured to do so > and available. Is this ok Volker ? I even thought that when this is done, the > Win32 Accessibility functions could be a plug in too to the same system. > Knowledge of Qt internal is needed here. Well, we will certainly not make Qt depend on ATK+AT-SPI+CORBA, even though it's not on me to make this decision. A plugin solution seems to be a reasonable idea, but requires Qt to be present as a shared library (since the plugin will also link against Qt) - this is not a problem for KDE, but software vendors often tend to ship Qt statically linked to avoid conflicts with existing Qt libraries. Plugin based solutions also tend to bring in all sort of trouble, e.g. difference in Qt versions the plugins and the applications depend on etc. Otherwise, interfacing with a plugin is technically no big issue. What I don't know though is how that plugin should handle the RPC, e.g. the requests for atk objects/interfaces from the accessibility client, but then I'm not extremely familiar with that stuff. -- Volker _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility