java-gnome-hackers

[java-gnome-hackers] Motion event and eventmask

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

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

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

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

[Andrew C. <an...@op...>]

On Fri, 2009-05-22 at 22:08 +0000, Vreixo Formoso Lopes wrote:
> ... an improved implementation of enable/disable events.
> The patch also includes ...

So I did a partial merge of Vreixo's 'event-masks' branch. Certainly all
the work exposing EventMask was excellent and that deserved to go in
regardless.

The part I wasn't comfortable with was the enableEvents() /
disableEvent() idea that Vreixo has. In unrelated work I found myself
exposing Widget's setEvents() and addEvents() methods, then remembered
Vreixo had worked on EventMask, and turned to his 'event-mask' branch.
Most of what he wrote for enableEvents() was sound, so I just used that
text for setEvents().

I also merged the MotionNotifyEvent interface and connect() stuff in
Widget.

Since I'm not entirely sure what he was doing that ran him into trouble,
so I'm sure we'll need a bit more [getEvents() + some more Flag stuff?]
to satisfy his need, but I wanted to get the good stuff in so we could
focus on the diff of just the difficult part.

++

I feel like I'm getting better at cherry picking. The trick for the
gatekeeper (me) is to `bzr revert` the bits we're not ready to accept,
then committing the remaining diff as the merge. That means

a) history isn't lost and we DO incorporate code we are ready to accept,

b) future diffs of the contributor's branch against 'mainline' are
smaller.

c) what goes into 'mainline' is clean but requires

d) people contributing branches with work-in-progress like this to then
"revert" when *they* next merge 'mainline' into their own
work-in-progress branch.

That way they keep their changes, (it's not up to me to tell them they
can't have whatever code they want) but they can continue to stay up to
date.

In hindsight, this is what John wrote about here:
http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html

That's not exactly how I manage things, but the basic idea is similar.
Interesting all the same.

++

Anyway, I'll try and warn when I've done a partial merge so that
contributors working on a given feature branch can be aware to be
careful if merging 'mainline'.

Speaking of which, 'event-masks' merged to 'mainline' as at revno 713.

AfC
Sydney

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

[Andrew C. <an...@op...>]

On Wed, 2009-05-20 at 09:16 +0000, Vreixo Formoso Lopes wrote:
> for example,  to VisibilityNotify signal before adding the widget to a
> parent container, we will get an ugly Gtk-Critical.

There are quite a few things in GTK that don't work if you do them in
the wrong order, and not having a child in a parent comes up quite a
bit.

Maybe we just have to tell people to make sure they pack their child
into a parent before connecting to this signal?

AfC
Sydney