Re: Good OO Bindings for Gtk+

Tim Janik <> writes:

> On 14 Apr 1999 wrote:
> > The gtk.defs file in the GTK+ distribution is the current
> > "standard format". It lists:
> > 
> >  Enumeration definitions
> >  Flag (bit-field) definitions
> >  Some information on memory-management for "boxed" types -
> >   (opaque types that are not GTK+ objects)
> >  Functions (not nearly complete)
> > 
> > It does not cover signals or object arguments (both of which,
> > can, in theory be queried from a running GTK+ library)
> i'd like to oppose somewhat to your "in theory" qualification ;)
> the gtkquery tool under gle/tools/gtkquery.c in the CVS module gle
> can be used to produce dumps of the widget heirarchy and lists all
> signals introduced by a certain widget class (the GleEditor widget
> features a signal list for one of its input fields as well).  as for
> runtime queries of the argument system (this could be featured by
> gtkquery as well, just haven't thought of that yet), the function
> gle_gobject_setup_args() in gle/gle/glegobject.c implements code to
> walk and register all object arguments of any given object, and
> gle_gwidget_rebuild_child_args() in gle/gle/glegwidget.c does the
> same for child args of any given widget.
> so while you claim that queris would work in theory, there's some
> pretty alife code in GLE practicing this very thing on a daily basis
> (at least on my system) extremely happily. ;)

My "in theory" qualification was more directed at the
fact that the query process has to be bootstrapped with
a list of gtk_foo_get_type() calls. That means, you can't
spit out the full type tree without compiling some C code.

I could image some day having a registry of GTK+ widgets 
so that you could install a .so in a standard directory,

 $ gtk-registry-update

And then programs could just query the complete list
of available widgets and instantiate them completely
dynamically. Of course, that isn't all that interesting
right now, since you can't actually query object

(The other limitation I know of is that for some types
of queries you have to instantiate an object first - you
can't just query the type system)

But, I didn't mean to imply that the querying code
doesn't work.


(Hmmm, that reminds me - the other place which has pretty
complete parsing code for GTK+ header files is the
gtk-doc system... actually a lot more comprehensive

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