Re: [g-a-devel] [Accessibility] Re: [Accessibility-atspi] D-Bus AT-SPI - The way forward

Willie Walker <[email protected]>
Newsgroups gmane.comp.kde.devel.accessibility,gmane.comp.gnome.accessibility.devel
Message-ID <[email protected]>
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.
>>
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.