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



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.

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? 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?

> > 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?

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?

-- 
Aaron J. Seigo
Society is Geometric



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