From kde-accessibility  Tue Dec 11 16:21:57 2007
From: Willie Walker <William.Walker () Sun ! COM>
Date: Tue, 11 Dec 2007 16:21:57 +0000
To: kde-accessibility
Subject: Re: [Kde-accessibility] [g-a-devel] [Accessibility] Re:
Message-Id: <475EB925.4030209 () sun ! com>
X-MARC-Message: https://marc.info/?l=kde-accessibility&m=119740363120445

Hi Rob:

Though I helped create the Java accessibility API proper, I'm not quite 
sure how the CORBA stuff is handled.  I've only worked on a few bugs in 
the java-access-bridge (see 
http://svn.gnome.org/svn/java-access-bridge/trunk), it's still a slight 
bit beyond me.

It's probably obvious, but the main code seems to live in these 
directories.  The one I play in the most is the 'impl' one:

http://svn.gnome.org/svn/java-access-bridge/trunk/bridge/org/GNOME/Accessibility/
http://svn.gnome.org/svn/java-access-bridge/trunk/impl/org/GNOME/Accessibility/
http://svn.gnome.org/svn/java-access-bridge/trunk/registry/org/GNOME/Accessibility/

As part of the build, I believe an idlgen pass is done that creates all 
the stub/skeleton stuff that lives under the idlgen directory.  I'm 
going to be digging a bit more in there this week, so I hope to learn more.

Will

Rob Taylor wrote:
> Michael Meeks wrote:
>> On Mon, 2007-12-10 at 21:57 +0000, Rob Taylor wrote:
>>> Supporting com.sun.java.accessibility shouldn't be hard, but we really
>>> need with some input from people who understand how accessibility is
>>> exposed by AWT/SWT/Swing..
>> 	Surely there should not be a per-toolkit wrt. simply bridging to a
>> different IPC mechanism. And indeed, the plus for Java of course would
>> be that it should be faster than using TCP sockets, more secure, and (of
>> course) will work on stock Linux systems (that disable IPv4/6 sockets).
> 
> I think I could definitly do with a bit more of a background on how java
> toolkits expose themselves. Could you quickly go though what components
> do which bits and how corba currently ties in?
> 
>>>> I'm a bit confused by the slowdown, though.  I thought that programs
>>>> that use UNIX sockets to connect to the ORBit2 server will continue to
>>>> do so even when TCP/IP is enabled.  My understanding was that enabling
>>>> TCP/IP with ORBit2 just made it possible for programs that want to use
>>>> TCP/IP to also be able to connect to the ORBit2 server (such as Java
>>>> programs).
>>> Well, the slowdown occurs when you disable local sockets, so no suprise
>>> there :)
>> 	I'd also expect a (small) slowdown just enabling IPv4 sockets, whether
>> they are used or not (and they're not preferred clearly), since in
>> itself that ~doubles the size of each object profile we marshal.
> 
> Actually we did seem see that, but it was small enough a difference  (~
> 5%) that it could have been noise.
> 
> Rob
>> 	HTH,
>>
>> 		Michael.
>>
> 
> 

_______________________________________________
kde-accessibility mailing list
kde-accessibility@kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility