Re: [java-gnome-hackers] Motion event and eventmask

[Vreixo F. L. <met...@ya...>]

Hi,

Attached you can find an improved implementation of enable/disable events.
I've finally implemented the option c), i.e., caching the event mask changed until the Widget is realized.
Please take a look at it.
The patch also includes my previous commit, this way you can compare both solutions, and the original will remain under revision control.
If nobody has any opinion against the idea of exposing event masks in Widget instead of gdk.Window, I'd like to propose this for merging into mainline.

Cheers
Vreixo



----- Mensagem original ----
De: Vreixo Formoso Lopes <met...@ya...>
Para: Java-Gnome Hackers <jav...@li...>
Enviadas: Quarta-feira, 20 de Maio de 2009 11:16:54
Assunto: [java-gnome-hackers] Motion event and eventmask

Hi,

I send you the patch implementing the ideas I told you last week, regarding how to expose EventMask.
Instead of requiring developers to retrieve the GdkWindow, and set the event mask there, I have implemented enable/disable events as methods of Widget. Such methods take care of realizing the Widget if needed.

There is, however, a problem with this idea, that was also present previously, in the way VisibilityNotify was handled. 
The problem is that a widget cannot be realized until it is added to its parent. As we automatically realize a widget when needed, if the user connects,  for example,  to VisibilityNotify signal before adding the widget to a parent container, we will get an ugly Gtk-Critical.

So we have 3 alternatives:

a) Document that problem in the methods that can suffer it (enable/disableEvents and connect(VisibilityNotify) afaik), and prevent the Gtk-Critical by checking correctness in advance and throw IllegalStateException or such when needed.

b) Forget about automatically realize Widgets, and expose gdk_window_set_events (maybe as a pair enable/disable methods) in gdk.Window, requiring the user to use the same technique as in pure Gtk. Signals that need it (VisibilityNotify, MotionNotify...) should document how to address this.

c) Another alternative, much more complex, is to internally connect (in Widget) to a signal such as realize-event (is this correct?), and set the event mask there. In this case, events-related functions check if there is a GdkWindow: if not, the changes are stored internally until the realize signal is received.

I am not really conviced of what is the best solution... ideas?

Cheers
Vreixo



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com