[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Gnome2::IconList bug
- From: "Ross McFarland" <rwmcfa1 neces com>
- To: gtk-perl-list gnome org
- Subject: Re: Gnome2::IconList bug
- Date: Thu, 5 Feb 2004 13:42:36 -0500 (EST)
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]