Re: [gnome-bindings] Redefining the defs format =)
- From: James Henstridge <james daa com au>
- To: Mark Patton <mpatton jhu edu>
- Cc: Ariel Rios <ariel linuxppc org>, gnome-bindings ximian com, mvo zagadka de
- Subject: Re: [gnome-bindings] Redefining the defs format =)
- Date: Sun, 15 Apr 2001 23:27:10 +0800 (WST)
On Sun, 15 Apr 2001, Mark Patton wrote:
> First of all, it's great to see some discussion here. I tried at least
> once to get some sort of discussion going on improving the defs format
> without any success.
>
> I've been working on Tcl bindings for Gtk 2.0 for a while now. Because
> noone here seemed interested in cooperating I ended up defining my own
> format, but if there was an authorative definition I would certainly
> use it and help with maintenance.
I guess I only really told people about my work on the pygtk and
gtk-devel-list lists and irc. If anyone else is looking for help writing
bindings, hopefully this list will be a good starting point.
A snapshot of my bindings is available at:
http://www.gnome.org/~james/pygtk2-SNAP-20010408.tar.gz
It will require python >= 2.0, glib and gtk+ >= 1.3.3 to compile. There
are some dynamic linker problems at present that will cause some
difficulty in actually using the bindings. Patches are available at:
http://bugzilla.gnome.org/show_bug.cgi?id=50707
>
> For every public C function I need:
> - the name (available)
> - the class it belongs to (available)
> - the C return type and arg types (available)
> - the GTypes correpsonding to those C types (not available ?)
>
> I can go from the C type to the Gtype with a fair degree of accuracy
> using various heuristics, but it's ugly. Perhaps instead of including
> the GTypes with every function we could just define a mapping from
> the C type to the GType. The defs format seems to have some provision
> for this, with "type", but it doesn't seem to be used in gtk.defs
You mean the upper-case-with-underscores-with-TYPE-in-the-middle version
of the classname? That sounds like a useful thing to add to the defs
format (for objects, boxed, enums and flags at least).
>
> The defs format seems to define a great deal of information that does
> not seem needed given Glib's intropspection abilities. For example
> defining the enums, flags, and signals seems like overkill. All of the
> information needed can be queried at runtime. Maybe there is some
> language binding that makes good use of this information?
There is info in the format that I am not using either. Havoc wrote the
new defs specification while working on his Inti C++ bindings. I don't
know how much of the stuff in the spec he actually planed on using and how
much he was just guessing would be useful.
I assume that some of the info most interpreted languages would just grab
via introspection may be useful for compiled languages where these things
can't be done at runtime.
>
> Slightly unrelated: we should also get together to make sure the various
> libraries we want to wrap register things like enums, flags, and boxed
> types with the Glib type system. For example GdkPixbuf doesn't register
> some enums and misc. pointers in Gtk aren't registered.
Gtk 2.0 is actually quite good in this reguard. The number of uses of
GTK_TYPE_POINTER is down, and getting lower. If there is any specific
bugs you have found, the gtk+ maintainers would probably appreciate it if
you log them in bugzilla.gnome.org. Remember to set the 2.0 milestone on
your bug after creating it so it doesn't get forgotten.
James.
--
Email: james daa com au
WWW: http://www.daa.com.au/~james/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]