Re: [gtk-list] Re: Automatic generation of gtk+ interface
- From: Tero Pulkkinen <terop students cc tut fi>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Automatic generation of gtk+ interface
- Date: 03 Jul 1998 03:06:56 +0300
Elliot Lee <firstname.lastname@example.org> writes:
> > I disagree, because the C source code does not include all the necessary
> > information
> Hmm, what specific information is it missing?
What data members should be used by users? (think of GtkFileSelection and
buttons inside it -- users need access to it, but there's no way to determine
if they're public or private or if you should be able to read value or
set it on the fly etc..) Same situation is with many other widgets too...
Also think of GtkContainer's interface. There's no way to convert from
GList handling to proper C++ way of handling containers (==iterators)
and it should be clear that in C++ code, those GList thingys look like
a horrible hack. The common representation should be able to generate both
C's GList interface and completely different way of accessing the items
Same with strings? Passing in/out parameters?
Same kind of problems come with simple things like idle_add() and
idle_remove() thingys, no good way to convert automatically, if they're
represented in the low level format. (C++ version needs to handle callback
to member functions, static functions and function objects instead of
plain C function interface..) From more general format they can be
automatically generated.. etc.
Many places dont have consts in the C interface where in C++ there
MUST be consts available. (like specifying that some method doesnt
modify the object's state...)
=> basically all this means we're doing all interface changes by hand to
every language wrapper. (code usually is generated, but still need to
describe the interface to each of them separately..) And if gtk's interface
keeps changing like it looks to do, it'll take quite much effort to keep
up with changes and rarely used wrappers will not work right with any
gtk+ version available :)
> > specialized sollution to match exactly gtk+'s object model and which has
> > parser already available
> IDL comes to mind, if only because I'm sitting here working with it all
> day :) Andrew has libIDL doing parsing of .idl files into a nice tree of
> data structures, so you can use your tools to do whatever you want with
I agree that Idl would be one of the choices... Tho I'm not sure if it
allows describe things like signals or callbacks properly and flexibly
enough to generate all language wrappers or gtk+'s public interface
code from it though.
Guess I'm not really sure myself what it really should do...
well, this just shows that the issue needs more investigation...
-- Tero Pulkkinen -- email@example.com --
] [Thread Prev