Re: Hacking on Gnome2::Canvas

On Thursday, June 5, 2003, at 12:46 AM, Dov Grobgeld wrote:

I started hacking on implementing the Gnome2::Canvas tonight and
I made enough progress so that the following snippet of code works:

eeek! i started working on this, too. i got functional bindings in about two hours on monday, and spent several more hours porting portions of the canvas demo app. i was about to commit it to cvs but don't like the fact that it's currently done as part of Gnome2 --- since the canvas itself can be used without the gnome libraries, i'd like to have the bindings be usable without gnome as well.

    my $item = Gnome2::Canvas::Item->new($root,
                                     x1 => 50,
                                     y1 => 70,
                                     x2 => 200,
                                     y2 => 180,
    $item->signal_connect(event=>sub {print "I got an event!\n"; });

(Note that I choose to use a string argument for providing the type of
the canvas item as opposed to using the Gnome2::Canvas::Ellipse->get_type()
which in my opinion is ugglier. The cost is another string lookup
within Glib. If needed it should be pretty easy to support both syntaxes,
and perhaps then we can predeclare GNOME_CANVAS_ELLIPSE_TYPE etc const
subs for speed. (The string is the GLib registered type, btw)).

since these types are actual, registered GTypes, they should get actual perl package names and be referred to as such, e.g., you'd pass 'Gnome2::Canvas::Ellipse' to Gnome2::Canvas::Item->new.

it is a design decision of the bindings that the type id concept shall be completely replaced by perl package names.

But, I eventully got stuck on type mapping for the GnomeCanvasLine.
One of its properties is "points" which take an argument of type
GnomeCanvasPoints. The latter should be mapped from a perl list,
but how do I do that? Where do I define the type conversion from
a perl ARRAY-ref to the GnomeCanvasPoint structure?

there's not a clean way to do this, unfortunately, in the current object representation. i looked at this for quite some time the other day, and decided eventually that something like

$points = Gnome2::Canvas::Points->new (@coords);
@coords = $points->coords;

was the best solution under the current circumstances. the problem is that the code which will extract the C object from the perl wrapper is called deep within the library (gperl_value_from_sv, actually) during the call to g_object_set, so normal binding tricks don't work.

i've been talking offlist with pcg about possible changes to the object representation; if done right, that could provide a way to solve this perlishly.

I get the very informative ;-) error message:

internal nastiness: boxed wrapper contains NULL pointer at ./test-canvas line 37

basically, the autogeneration code registered standard code to handle the registered boxed type. you passed an array ref, which is essentially an RV pointing to an AV, to the function which extracts the boxed type from a wrapper which is an RV pointing to an IV, whose value is the pointer to a C structure describing the C object. since the RV didn't point to an IV, the value was 0, and that's how you got a NULL inside a boxed wrapper. it actually should've complained when it discovered that the wrapper wasn't derived from the proper class....

And finally, may I please have cvs write access btw so that I can put
back my work there?

talk to me off-list so we can combine our code and decide where to put it.

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