Re: [gtk-list] Boxed events

[Owen Taylor <owt1 cornell edu>]

Kenneth Albanowski <kjahds@kjahds.com> writes:

> Ugh, I've just been trying to get events re-adapted to Perl, and it's not
> much fun. It appears that events really don't fit into the "boxed" 
> metaphor very well (or I am misunderstanding the boxing process.) Unlike
> the other _ref and _unref procedures, gdk_event_copy actually returns a
> copy of the original event, and a different pointer (which complicates
> quite a bit the procedure needed to make sure Perl always uses the same
> Perl shadow object for a particular GdkEvent object.) 

I think this is a real limitation of Marius's current description -
it treats all structures as opaque objects. Which doesn't make sense
for languages that actually have something like structures. But since
it was indicated that better GDK support is underway for guile-gtk,
perhaps this will change.

> It's also unclear how to allocate a gdk object from scratch (or whether an
> application would ever need to do this.)

gdk_event_copy just copies the data in the event and increments the
reference count on the 'window' field. 

Probably the safest way to create a new event in C is something like:

  GdkEventCrossing myevent;
  GdkEvent *new_event;
  myevent.type = GDK_EVENT_ENTER;
  myevent.window = XXX;
  myevent.subwindow = XXX;
  myevent.detail = GDK_NOTIFY_ANCESTOR
  new_event = gdk_event_copy (&myevent);

(Note: this isn't right reference-count-wise for gdk_event_put...)

(You can ignore the XEvent* in the GdkEventOther - that's just a hook
for low-level hacking, that I don't think is being used currently. No
GTK program will actually get GdkEventOther events unless they make
calls into X directly.)

Although, in C, events can be cast into the appropriate subtype, sort
of like derived objects, I think they really should be seen as
discriminated unions.

I suspect the right thing to do in Perl is going to create a
structure that has the fields of the arm of the union selected by
the type field, copying the window field normally. (that is, doing
a gdk_window_ref, and unref'ing in the destructor for Gdk::Window)

{ type => 'enter_notify,
  window => XXX
  subwindow => XXX
  detail => 'ancestor' }

This doesn't however match the current Perl CORBA/ILU mapping for a 
discriminated union, which is (approximately):

  { _type => 'enter_notify',
    _value => { window => XXX, 
                subwindow => XXX, 
                detail => 'notify_ancestor' }

(The underscores are superfluous, but present in COPE. Because of the 
C and C++ bindings, enumeration values need to unique within an
interface)

How to represent this in gtk.defs is another matter. The obvious thing
would be to add ways to define records and discriminated unions. (The
union type should not need all the complexity of CORBA unions, though:

(define-union GdkEvent GdkEventType ;; defines discriminator type
 (GdkEventCrossing enter-notify leave-notify) ;; multiple values for 1 arm
 (GdkEventButton button-press button-release)
  ...
)

should be sufficient. Even implementing this is a bit silly, since
there is only one union type currently used. (I think GtkDitherInfo
is private). Maybe events should just be a special case...

A structure/record type probably has a stronger case. With the proper
definitions, it should be easy to generate accessor functions for
languages like guile. 

Regards,
                                        Owen

(Hmmm, that was longer than I meant it to be...)