Re: [g-a-devel]Gnome-speech and the callbacks

["Draghi Puterity" <mp baum de>]

Hi Michael, hi All,

first the good news. Callbacks are working. It was some weird build problem
I cannot explain, but after an "make uninstall" followed by a "make install"
on gnopernicus and gnome-speech everything seems to work as expected, I
receive the notification. Thank you for your help and soory for triggering a
false alarm.

Please see also my coments below, after MP.

Best regards,
Draghi


----- Original Message -----
From: "Michael Meeks" <michael ximian com>
To: "Draghi Puterity" <mp baum de>
Cc: "Bill Haneman" <bill haneman sun com>; "Marc Mulcahy"
<marc mulcahy sun com>; "accessibility mailing list"
<gnome-accessibility-devel gnome org>; <firma baum ro>
Sent: Friday, January 17, 2003 11:27 AM
Subject: Re: [g-a-devel]Gnome-speech and the callbacks


> Hi Draghi,
>
> Just noticed this thread;
>
> On Thu, 2003-01-16 at 15:21, Draghi Puterity wrote:
> > Well, for some reasons it doesn't work for me, GS events are not comming
and
> > calling bonobo_main is not an option because it is blocking.. Could you
> > please try this in one of the AT-SPI demo programs and send me some
working
> > code? It would help me a lot.
>
> The first step is to ensure that you have build ORBit2 with
> --enable-debug, and exported ORBIT2_DEBUG=traces, and ensured that there
> is in fact valid traffic flying around from A to B.
>
> The 2nd is to check that you are not getting exceptions fired on
> registration.
>
> The 3rd is to check that you are registering the CORBA interface of an
> associated bonobo object; ie.
>
> GNOME_Speech_register (registry, BONOBO_OBJREF (impl_obj), ev);
>
> instead of passing 'impl_obj' itself - which would cause acute problems
> ;-)

MP: Thank you for detailing these steps of Bonobo debugging. I'm sure they
will save me the day some day. But as I said everything was OK, I have used
BONOBO_OBJREF as I have inspired my code from Marc's  tester.

>
> > If this is not the way it is done with bonobo, I will do what I need on
> > my side.
>
> Don't. Please stop and think before adding yet another redundant (and
> broken) level of abstraction to gnopernicus. Why do you need to
> associate more data with the client ?

Speech markers are used (among other things) in gnopernicus to pan the ROI
of the magnifier on the screen so that it shows what is currently being
spoken. Same for Braille, I might want to autoscroll the Braille so that it
shows what is currently being spoken.

So from the higher perspective (in a very simplified scenario) :

1. I get an Accessible object from AT-SPI and I extract the text from it
2. I send this text to GS (there is a queue involved) which will speak it
asynchronously
3. When I get the callback I need find the Accessible whose text is
currently beeing spoken in order to retrive its coordinates.
4. Having the coordinates I set the new magnifier ROI.

Now I thought that a good way to achive point 3 would be to be able to pass
to the GS a gpointer to the original Accessible (actually a gpointer to some
structure containing the Accessible but this is irelevant for the purpose of
the discussion). This was the rationale of my request to Marc. I wasn't
aware that there is a "Bonobo way" to do this, and the "user_data" parameter
seemed as a harmless addition to API for Bonobo ignorant I am. (BTW, Michael
is there any other Bonobo doc besides the (incomplete) API on the web? ).

>
> Why can you not simply tie that data to the BonoboObject that
> implements the listener and emit a GObject signal on that ? what do you
> hope to add by adding another layer of wrapping ?

MP: I'm not sure I understand exactly what you and Bill are saying with
tieing that data into the listener. Are you suggesting that before each call
to GNOME_Speech_Speaker_say I should modify my "uplink" in the Callback
object? ("uplink" would be for example the Accessible pointer in the example
above, ore something more complex include some state). Anyway, this is what
I understood and plan to do.

in fact it seems to me
> that you need to substantially bin the existing speech API / abstraction
> in favour of a cleaner one - could this be it ? :-)
>

MP: I thought we already discussed this after your code review (or you just
want to nag me? ;) ). SRS is ugly, it was a hack to have something working
until a reasonable GS was here, and now that I finally have a GS that meet
my minimal needs I'm in process of redesign it.

> I'd be interested in your design document / thoughts if you're knocking
> one up - it'd be great to have this really clean / polished in
> gnopernicus.

I have the same goals, I want a really clean SRS, but sorry documentation
comes after features in my priority list (for strong reasons I don't want to
discuss here). I will try to put better comments in the code and than kindly
ask you and the comunity for a code review.

>
> Regards,
>
> Michael.
>
> --
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>

Best regards #2,
Draghi