Re: [g-a-devel] [Accessibility-atspi] AT-SPI and D-Bus

[Bill Haneman <Bill Haneman Sun COM>]

Hi Gunnar, Olaf, and all:

I am sorry if this discussion started "on the wrong foot". 
Unfortunately the timing is not good for me, as I will be on vacation
starting in a couple of hours, and I have been in meetings all day.  So
I can't give it all the attention it deserves.

The "call the g_mainloop when needed" solution seems to me like a good
way to deal with the "glib mainloop problem".  I understand your point
about needing to know when to do this, but I would be optimistic that we
could find a reasonable solution.  If it requires adding some API to ATK
so that non-gmainloop clients could hook in to some other notification
mechanism, that would be fine with me.

I also don't wish to block discussions on migrating AT-SPI to DBUS, but
rather wish to participate in them constructively so that we can discuss
our various concerns.  It's clear that DBUS is perceived as a more
"neutral" technology than CORBA, so that's a plus.  But as Will
indicated, IDL-based interfaces have a number of advantages over
hand-coded bindings; this is in fact my biggest complaint with the
'cspi' client bindings, and why even though I wrote them, I don't want
to see them used as the primary compatibility layer.  The beautiful
thing about the pyORBit bindings to AT-SPI, for instance, is that if I
add the "new_method" call to AccessibleText, a python client can
immediately call text.new_method without any hand-coding required for
the python bindings.  

I look forward to having some constructive discussions about how one
would best achieve our goals with DBUS, and some explorations of what
the remaining gaps/barriers are.   (But unfortunately, not this week!)

Best regards,

Bill

> In fact the "problems with the way glib is written" are glib mainloop 
> issues. From what Harald Fernengel (the developer at Trolltech who writes 
> the AT-SPI bridge for Qt/KDE), there are two ways to integrate Qt 4.x with 
> the glib mainloop:
> 
> 1. Usually use the Qt event loop and only call the glib mainloop if you 
> know that something in ATK needs to be processed.
> 
> There are two reasons why something in ATK needs to be processed: The first 
> one is that you just have some changes in the GUI which in turn create 
> AT-SPI events which will be generated. The second one is that data arrives 
> on a socket which is used for the CORBA communication. This is the harder 
> part as you do not know which of the sockets that are opened by your 
> application are the ones that are used by ORBit2.
> 
> 2. Let Qt 4.x run in the glib mainloop.
> 
> This way you only have one main loop, so that you do not need to know when 
> to call the glib mainloop. Instead there are other problems. If what I 
> heard is correct, then there is no way in glib to disable a timer, and it 
> is an expensive operation to create or destroy a given timer. The problem 
> with that is that Qt makes heavy use of QTimers (which _can_ be disabled, 
> so that they do no longer fire events), so there you have performance 
> problems.
> 
> It may be that I misunderstood some of the points when Harald told me about 
> them, but I trust him that he knows what he is talking about.
> 
> Gunnar Schmi Dt
> -- 
> Member of KDE's Technical Working Group
> Co-maintainer of the KDE Accessibility Project
> Maintainer of the kdeaccessibility package
> http://accessibility.kde.org/
> 
> ______________________________________________________________________
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel