Re: [g-a-devel]Source of mouse:button events

[Bill Haneman <Bill Haneman Sun COM>]

Hi Bernard:

I understand your objectives better now.  I was starting to suspect that
you were doing something like user-interface logging or automation; so I
guessed right :-)

In your case, the toolkit-specific events seem like a reasonable choice
since you are interested in logging some toolkit-specific information. 
If you want to know what "toolkit events" are supported for gtk+, the
events correspond to the signal names documented in the gtk+ API
documentation, prefixed with 'gtk'.  For instance, the gtk+ docs for
GtkButton list a "clicked" signal; this corresponds to a toolkit event
in the 'Gtk' namespace, for class 'GtkButton', having detail 'clicked':

Gtk:GtkButton:clicked

Thus registering a listener in at-spi for "Gtk:GtkButton:clicked" should
work, but hasn't been tested very thoroughly.

best regards,

Bill

On Fri, 2003-09-26 at 09:41,
gnome-accessibility-devel bernard-hugueney org wrote:
> Hi Bill, thank you for all your help !
> 
> Le Vendredi 26 Septembre 2003 09:14, Bill Haneman a écrit :
> > Hi Bernard:
> >
> > Toolkit-specific events are intentionally undocumented, as we don't
> > want to encourage their widespread use.
> 
> I understand.
> 
> >
> > I still do not understand the problem you are trying to solve; can
> > you give more context?  In the context of assistive technologies it
> > is not clear what you are doing.  If you are trying to build some
> > sort of test or automation tool then there are a number of factors
> > to consider.  As I said, you should be receiving (and listening
> > for) state changes to widgets in response to user actions such as
> > mouse button clicks or even mouse enter and exit events, not the
> > device events themselves.  The same is true for keyboard events;
> > except for the case of command keys for your application, it's
> > often better to monitor text-changed events and other widget state
> > changes than monitor keyboard events directly.  Key echo can be
> > another exception in some situations, but it depends on user
> > preference and the exact problem your application is trying to
> > solve.
> >
> 
> I want to study user-GUI interactions. For that purpose, I need to log 
> them. I was not satified with the two most common approaches:
> 1) application-level logging : requires to patch the apps to log the 
> events.
> 2) system-level (Xserver) logging : too low-level, no application 
> semantics.
> 
> That's why I want to get the best of both worlds with a 
> toolkit-oriented approach. At-spi seemed perfect for it. I thought I 
> could easely log that, for example, Button with text "OK" child of 
> widget labelled "Do you want to quit" child of application named 
> "OpenOffice.org 1.1.0".
> I still think I can have this kind of information, but not as easely 
> as I hoped for.
> 
> User-GUI interactions goes both ways. I understand that assistive 
> technology is more interested in the GUI->user way. I still think I 
> can nevertheless also use it to get user->GUI informations.
> I'm not only interested by the application's response (text inserted), 
> but also by the user action that triggered it (mouse middle click?, 
> Ctrl-V?, normal keyboard input?)
> 
> > Please try to avoid the use of toolkit-specific events; I do not
> > see the relevance to your charset issue, which is a bug.  That bug
> 
> Well, as a workaround for the bug, which seems to occur only with 
> OO.org, I was about to translate the strings myself when I get them 
> from OO.org toolkit. I was the use OO.org toolkit specific events to 
> know when I have to translate the strings.
> 
> > is currently being investigated; we are currently explaining the
> > issue to StarOffice/OpenOffice engineering.
> 
> Thanks alot for  that. As I wasn't sure it was a bug or some 
> misunderstanding of mine, I resolved to workaround the behavior 
> instead of holding my breath :-)
> 
> Thanks a lot for your help.
> 
> Bernard
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel