[Kde-accessibility] Re: KDE and AT-SPI [was: Re: Is it the time for "KSpeach"?]

[Bill Haneman]

Hi Aaron:

Our first order of business is getting what we have, working.  When the
Linux/GNOME accessibility infrastructure was being developed, and when
the Linux Accessibility Working Group meeting recommended embracing the
GNOME architecture as our standard, DBUS did not exist.

I agree that in the future alternative implementations of our IDL and
protocols should be actively explored.  Re-directing effort into a
replacement now, when we are just starting to get our existing vertical
stack working, serves no good purpose.

I insert a few more comments below...

On Wed, 2004-09-15 at 20:04, Aaron Seigo wrote:
> On September 15, 2004 12:27, Bill Haneman wrote:
> > On Wed, 2004-09-15 at 19:16, Aaron Seigo wrote:
> > > except that the overwhelming majority of desktop applications don't need
> > > a "truly object oriented, network capable object protocol" of the
> > > magnitude of CORBA.
> >
> > Maybe.  But accessibility does, at least if you want to support more
> > than just GNOME/KDE apps written with C/C++ running on a single, local
> > machine.
> 
> you do know that DBUS is network aware/transparent, right? that's one of the 
> shortcomings of DCOP that it addresses.
> 
> C/C++ isn't a valid issue either as bindings to DBUS are trivial, as the 
> numerous bindings to DCOP provide an existing example. it's not a complex 
> library.

Last time I looked into it DBUS did not have sufficient expressiveness
to handle at-spi.  And Java/OpenOffice is a problem; how easy would it
be to write DBUS client/server implementations in Java?

> GNOME/KDE isn't an issue either as things such as HAL, which are not even GUI 
> apps, are using DBUS with success. DBUS was designed with this clear 
> separation between any GUI (let alone a specific one) and IPC in mind.
> 
> are there other objections not encompassed by the three points you listed?
> 
> > > has this ever been a useful asset in terms of accessability and ATK in
> > > particular to date? theoretical benefits don't really count, but if it
> > > has proved useful, bully.
> >
> > Yes; OpenOffice uses the Java ORB for its accessibility, as do all
> > Java/Swing apps on GNOME. 
> 
> isn't this the same as saying that GNOME uses CORBA for accessibility right 
> now? to whit, if DBUS was used, could (and would not) these applications 
> follow suit? 

As I have already said, there are a number of requirements that would
need to be met before a different communications protocol could be
substituted.  Perhaps we're at the point where some of them are now
satisfied by DBUS... but see below.

> especially if that meant allowing a single, desktop-appropriate 
> protocol that was used by things as disparate as hardware device discovery by 
> the OS kernel and remote control of GUI apps? i imagine it'll be a cold day 
> in hell when CORBA is used for something like HAL, which is why they are 
> using DBUS. we have the source to OOo and Java accessability bindings 
> (AFAIK?), let's use that advantage.
>
> > Oracle uses Java/Swing as its means of 
> > deploying a number of accessible applications for users with
> > disabilities, and there are other real-world examples.  In the workplace
> > this can be a significant thing.
> 
> if Oracle uses Java/Swing, and Java/Swing were to use DBUS as part of the 
> above theorized transition, then would Oracle's tools inherit this 
> accessability capability or is Java/Swing really that messed up in this 
> regard?

I don't know what a Java implementation of DBUS would look like, or how
difficult it might be.  I assume it would be possible.

> > > DBUS will likely give us interoperability this same interoperability in a
> > > right-size container. i agree that we shouldn't jump projects such as the
> > > accessability frameworks onto it until it is Ready(tm), but i do think it
> > > is useful to understand why DBUS is needed and to state "these are the N
> > > bullet points we need covered for it to be useful for us". this is how we
> > > can work towards unified, useful technologies =)
> >
> > I don't have any problem with making DBUS better.  But better in this
> > way means bigger.  So an alternate path would be to keep CORBA/ORBit2
> > for the tasks that needs industrial-strength "Object Request Brokerage",
> > and keep DBUS lean and mean.
> 
> do any of our needs actually align with "industrial-strength" ORB 
> capabilities? or are we using a bulldozer to dig back-yard flower beds?

Well, yes.  If you want details, read the IDL.

> and i'm really not sure how much bigger DBUS would have to become to service 
> the needs here. seriously, show me the desktop apps that need the power of 
> CORBA that are deployed in common situations, not including apps that have 
> been made to use it "just because" but which actually leverage these features 
> in a meaningful way.
> 
> the rest of the Open Source desktop world, from kernel servicse on up, is 
> marching towards the "lean, mean" style of DCOP and the more featureful DBUS 
> or is already there. if at all possible aligning with this movement means 
> avoiding future interop problems and lowering the system requirements for 
> accessible software. i mean, wouldn't it be nice to be able to easily tap 
> into HAL for hardware discovery provided by the kernel rather than building a 
> DBUS / CORBA bridge or using both IPC mechanisms?

I don't see the relevance of what you are saying about HAL.  HAL is
important to accessibility, yes, but I see no reason for integration
with the AT-SPI "user interface" protocols.

- Bill

> -- 
> Aaron J. Seigo
> Society is Geometric
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility