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

[Bill Haneman <Bill Haneman Sun COM>]

Hi Bernard:

Toolkit-specific events are intentionally undocumented, as we don't want
to encourage their widespread use.

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.

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 is currently
being investigated; we are currently explaining the issue to
StarOffice/OpenOffice engineering.

regards, 

- Bill

On Fri, 2003-09-26 at 00:14,
gnome-accessibility-devel bernard-hugueney org wrote:
> Bonjour !
> Le Jeudi 25 Septembre 2003 20:06, Bill Haneman a écrit :
> > Hi Bernard:
> >
> > Some events, for instance key events and 'device' events such as
> > mouse:, are application-independant.  The event notification is
> > intended to inform you of the state of the device, not of an
> > application. Applications are responsible for relaying any
> > subsequent state changes.
> >
> > Different application toolkits and even different applications
> > treat such events differently, which is one reason why it is not
> > feasible to report the direct relationship between a device event
> > and a widget in a toolkit-independent way.
> 
> Thanks for the explaination, but I do not really understand how a 
> toolkit would not connect events to widgets.
> 
> >
> > What is it that you are trying to monitor?
> 
> I'd like to know which widgets are "receiving" the mouse:button 
> events.
> For keystrokes, it's mostly the focused widget, but when the user is 
> hoovering over menus, I don't know if he clicked on the last focused 
> one or not.
> Well, I guess I can look for mouse mouvement between the last focus: 
> and the mouse:button. Is ther another way than computing the area of 
> the focused menu and checking if the mouse is in ?
> The trouble is that for menu item, the relevant widget is the last 
> focused one, while for push button, it's the next focused one :-(
> 
> I just tought it would have been easier if the widget told me it was 
> clicked on. Maybe I should investigate toolkit-specifics events a la 
> Gtk:GtkWidget:button_press_event. I was reluctant to differenciate 
> according to the toolkit, but I think I will have to anyway because 
> of my charsets problems.
> 
> Do you know where I could find informations about toolkit-specific 
> event types (especially for OO.org, are they from java accessibility 
> API ?) ?
> 
> Thank you for your kind help,
> 
> B.