Re: Goocanvas issues



On 5/20/07, Paul Davis <pjdavis engineering uiowa edu> wrote:
On 5/20/07, Murray Cumming <murrayc murrayc com> wrote:
> On Sat, 2007-05-19 at 18:03 -0500, Paul Davis wrote:
> > Hey,
> >
> > I'm running into a some new issues with these wrappings. The biggest
> > roadblock right now is the wrapping of GooCanvasTable.  Its got a list
> > of child properties and I'm not sure on the best way to wrap them.
>
> I don't see any list:
> http://webcvs.freedesktop.org/cairo/goocanvas/src/goocanvastable.h?view=markup
>
>
> Do you mean the list in the base class?:
>
> struct _GooCanvasGroup
> {
>   GooCanvasItemSimple parent_object;
>
>   /* An array of pointers to GooCanvasItems. The first element is at the
>      bottom of the display stack and the last element is at the top. */
>   GPtrArray *items;
> ...
> }
>
> That's almost certainly a private struct field and I see no API for accessing it.
> It should probably be hidden in the C API.
>
>
> If you mean the varargs for this:
>
> GooCanvasItem*
> goo_canvas_table_new (GooCanvasItem  *parent,
>                       ...)
> {
>   GooCanvasItem *item;
>   va_list var_args;
>   const char *first_property;
>
>   item = g_object_new (GOO_TYPE_CANVAS_TABLE, NULL);
>
>   va_start (var_args, parent);
>   first_property = va_arg (var_args, char*);
>   if (first_property)
>     g_object_set_valist (G_OBJECT (item), first_property, var_args);
>   va_end (var_args);
>
>   if (parent)
>     {
>       goo_canvas_item_add_child (parent, item, -1);
>       g_object_unref (item);
>     }
>
>   return item;
> }
>
> you can wrap that as
> Canvas();
> and
> Canvas(Item& parent);
>
> and just let the application coder use canvas.property_*() = something.
>
> >  I
> > looked at Gtk::Table and its implementation. It uses a
> > Table_Helpers::Child class that contains the child-properties
>
> It provides access to the children, but not to the child properties, I
> think. Let's ignore the child properties unless we find they are
> necessary.
>
> It would be nice to have generic child property support for other gtkmm
> containers.
>
> >  and
> > allows for STL-Container like access to the children. This Child uses
> > a GtkTableChild object thing that I don't think exists for the
> > GooCanvasTable equivalent.
> >
> > Any help or ideas on how to wrap that object would be most welcome.
> >
> > I've found a bit of a bug when using
> > Goocanvas::Canvas::get_root_item().  The Glib::RefPtr< Goocanvas::Item
> > > object thats returned contains an GooCanvasItem thats only ref'ed
> > once. So when the RefPtr goes out of scope, the root item dies, which
> > causes a segfault internally in GooCanvas.
>
> Yes, you usually need to use the refreturn option on get methods, with
> _WRAP_METHOD. I have done that now in the libgoocanvasmm svn.
>
> > I think  I've verified this, becuase if I store the root item's RefPtr
> > as a class member ( so it doesn't get destroyed till the end of the
> > program ) the segfault disappears and when the program exits, there's
> > an error about g_object_unref fails the G_IS_OBJECT( object ) test (
> > Which I'm assuming means it got destroyed by one or the other and the
> > second destruction is failing.
> >
> > So basically, I need to add a ref operation somewhere, but I'm
> > uncertain as to where this should happen.
> >
> > In other news, quite a bit of the GooCanvas API has been wrapped. I'm
> > starting to work on getting the examples up and going.
>
> Thanks for this. Please keep mentioning stuff that you get stuck on,
> trying to be precise about what part of the API it is.
>
> --
> Murray Cumming
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
>
>

Hey,

Got fed up with not having the goocanvas api online so i've posted it
for now at:
http://gooey.ecn.uiowa.edu/goocanvas_api/html/

The list of child properties is on the GooCanvasTable page at:
http://gooey.ecn.uiowa.edu/goocanvas_api/html/GooCanvasTable.html#id2599395

I think there was a bit of misscomunication. Generally when I'm trying
to figure out how to wrap something, I try and find an example in
Gtkmm. In this case I was using Gtk::Table. This next paragraph is
only about Gtk::Table.

Gtk::Table uses a Gtk::Table_Helpers::TableChild class. This class is
where the child properties can be accessed. This class wraps a Gtk
object.

----

Now, in GooCanvas. There is no TableChild object for GooCanvasTable.
Therefore I don't really have the ability to use the Helper class
(AFAIK).

For now I'm going to try and wrap as much as I can, although, the
child properties seem like the sort of thing that should be used by
application coders.

In other news, is there a decent way of determining when I need to use
refreturn on  a _get() method? Would I just need to check the C docs
or source to find if it gets ref'ed before the object is returned?

Thanks,
Paul Davis


I've run into another issue with getting C->C++ types mapped
correctly. Specifcally, I can't fill in a property with a
Cairo::RefPtr<Cairo::Pattern> object.

In itemsimple.hg, I have this:
_WRAP_PROPERTY("fill-pattern",Cairo::RefPtr<Cairo::Pattern>)

I'm attempting to use it like such:
Cairo::RefPtr<Cairo::Pattern> create_pattern() { ... }
item->property_fill_pattern() = create_pattern() ;

But its generating this error:
(lt-demo:27094): GLib-GObject-WARNING **: unable to set property
`fill-pattern' of type `GooCairoPattern' from value of type
`glibmm__CustomBoxed_N5Cairo6RefPtrINS_7PatternEEE'

I've posted a message on the goocanvas list asking about the GooCairo*
types. I've also been looking through the properties in Gtkmm that use
RefPtr's and I can't find anywhwere that they do something special to
account for the refptr being passed in. (Like making a call to
Glib::unwrap or what not).

Anyone have an idea?

Thanks,
Paul Davis



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