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

Re: Gnome2::IconList bug



Ross McFarland said:
> muppet said:
>> but, yes, this appears to be a dependency problem.  it looks like
>> Gnome2 will have to depend on Gnome2::Canvas as well as Gnome2::VFS...
>> *or* have Gnome2's boot code register a type mapping for GnomeCanvas.
>>
>> this trick will actually work, i think; multiple mapping registrations
>> are fine, especially for GObjects, because it's just GType to name.
>> (for boxed types it's dangerous to lose the wrapper class, but GObjects
>> don't have that problem.)  so in Gnome2::IconList's BOOT section you
>> should be able to get away with
>>
>> 	gperl_register_object (GNOME_TYPE_CANVAS, "Gnome2::Canvas");
>>
>> libgnomeui depends on libgnomecanvas, so GNOME_TYPE_CANVAS should be
>> available.  no typemaps are strictly needed, because gperl_get_object()
>> does all the work from GTypes.
>
> i'd much prefer it depending on Gnome2::Canvas, as i don't like the idea of
> having an object around who's parents member may or may not be accessable
> based on whether or not you've use Gnome2::Canvas somewhere. it won't be
> obvious to developers what has happened when they can't see the methods on
> this objects parent type, when it says that it is that type, both in the pod
> doc and ISA.

looking through my local changes i saw that nothing's been commited to address
this problem. as i said before i really think the correct solution is to make
Gnome2 depend on Gnome2::Canvas, for above stated reasons. just figured since
nothing was ever decided i'd try to get the discussion going again.

-rm



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