Re: events for no-window widgets



On Wed, Sep 22, 2010 at 11:43 AM, Havoc Pennington <hp pobox com> wrote:
> A couple other ideas, just to put more options in the pile.
>
> Minor concern. gdk_event_set_coords() and set_source() could be
> problematic in that GdkEvent would become a mutable non-GObject. This
> is normally considered Bad language-binding-wise. Though in this case,
> the implications are perhaps limited since events don't "stick around"
> and multiple proxies for one event would probably be OK.
>
>
> Another API for getting events to no-window widgets, would drop
> GdkEvent for this, and add something like:
>
> /* pretend these are opaque objects with accessors but that's too much
> typing in this email ;-) */
>
> typedef struct {
>  gdouble x, y; /* widget relative */
>  GtkWidget *source;
>  GdkDevice *device;
>  /* rest of any useful fields here */
>  GdkEvent *event; /* original event in case you need window or root
> relative, or whatever */
> } GtkButtonPress;
>
> struct GtkEventReceiverClass {
> void (* button_press) (GtkEventReceiver*, GtkButtonPress*); /* this
> bubbles the button press. */
> }
>
> There could or could not be a "base class" for GtkButtonPress,
> KeyPress, etc. and a "base signal" ::bubble that was emitted for all
> of them. It could be that each button_press, button_release, etc.
> bubbles separately with its own vfunc directly. Without the base
> class, you never actually have to name this GtkEvent or use the word
> event, which avoids some of the namespace collision.
>

This sounds like a nice approach. In order to get something going,
I've started to experiment with implementing pick(). First attempt is
here:
https://bugzilla.gnome.org/show_bug.cgi?id=633209
It seems to work mostly ok, according to the included testcase.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]