Re: GtkBuildable type resolver



On Thu, 2007-06-07 at 10:45 -0300, Johan Dahlin wrote:

> Do you have one list per binding, or one big "metadata database" which
> shared between all third party libraries?

It's just one hash table. It's handled transparently (and internally) as
a resource within the jar file we turn out.

But no, it doesn't matter where the data comes from (some special cases
are hard coded), it just needs to exist before some pointer comes back
across the C/Java boundary that we don't already have a Proxy for.

The classic (and indeed requirement defining) example is
glade_xml_get_widget(); we of course have no idea what we get back from
a call like that. Instantiating a Widget would be incorrect, of course -
we need to instantiate the most fully derived type.

> You're likely to run into this "interesting" problem when wrapping
> GStreamer 

Thanks for the heads up.

On Thu, 2007-06-07 at 16:36 +0200, Murray Cumming wrote:
> The gtkmm Glib::wrap() system examines the base class and falls back
> to that.

Yeah, I've been meaning to do something along those lines in our
Plumbing.objectFor() to deal with this. Glad to hear it works ok for you
most of the time.

AfC
Vancouver

Attachment: signature.asc
Description: This is a digitally signed message part



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