Re: libgoocanvasmm



This ought to be a quick one.

class GooCanavs::ItemSimple inherits from Glib::Object

class GooCanvas::Ellipse inherits from GooCanvas::ItemSimple and Glib::Object

I've got warnings like such:
../../libgoocanvas/libgoocanvasmm/ellipse.h:28: warning: direct base 'Glib::Object' inaccessible in 'GooCanvas::Ellipse' due to ambiguity

Which I realize are the multiple inheritance problems. Thing is I tend to avoid multiple inheritance like the plague.

The problem is when trying to construct an ellipse I'm doing this:

Ellipse::Ellipse( const Glib::RefPtr<Item>& parent, gdouble center_x, gdouble center_y, gdouble radius_x, gdouble radius_y )
    :
        gobject_(goo_canvas_ellipse_new(parent->gobj(),center_x,center_y,radius_x,radius_y,NULL))
{
}

Which don't work cause of the ambiguity.

So, what do I do now?

Thanks in advance,

Paul
 
On 9/27/06, Murray Cumming <murrayc murrayc com> wrote:

> Yeah, my conversions are all sorts of wonky.
>
> I'm trying to follow examples in gtkmm and libgdamm but its getting
> confusing. I'm making some headway though.
>
> If goocanvas has types that are only listed in a private header, yet are
> the
> types of properties, isn't that a bug of somesort?  Or at least not
> right...
>
> http://gooey.ecn.uiowa.edu/goocanvas/GooCanvasItemSimple.html#id2706330
>
> Anything in the properties list that has GooCairo* as the type only exists
> in goocanvasprivate.h

Yes, that seems like a bug. At the least, those properties should be
marked as not being public API. Please CC me on any email or bugzilla (if
there is one) report you make.

> So none of the information go listed in *_methods.defs where the other
> types
> got listed like they were supposed to.

I don't think gtkmm actually uses that part (information about objects) of
_methods.defs anyway.

> If so, I'll patch goocanvas and submit it.



Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com




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