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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
