Re: New 'GObject' as base for GtkObject?

[Guillaume Laurent <glaurent worldnet fr>]

Owen Taylor <otaylor@redhat.com> writes:

> But, there are a lot of other issues involved in choosing a language
> than the number of characters I have to type.

No, but as trivial as this issue may seem it's a huge one.

> It adds many features that go beyond a simple object system. To name
> a few:
> 
>  - The signal system
>  - The argument system
>  - Refcounting
>  - Introspection including runtime queries of signals and arguments
>  - run-time type identification
>  - run time registration of new classes
> 
> If you created a C++ system to handle such objects, the amount of
> work you need to do beyond straight C++ is not trivial.

Certainly, but it would still be simpler than in GTK+, and be easier
to reuse.

But what you describe here is more like the ObjC runtime, with a bit
of Java mixed in (C++ has RTTI, though), so for these two languages
it's practicaly almost already in there.

> Or whatever. This will definitely be more typing than Python, and a
> bit more typing than C++, but it isn't nearly as painful as you make
> out.

It's not just typing, it's also having the compiler understand what
you're doing, checking it, and possibly optimizing it. And later on
have the debugger understanding it as well, or the people reading and
maintaining your code.

> > - These bindings are not always easy to do, and sometimes they are
> >   pretty damn difficult.
> 
> Suggestions as to how to make GTK+ better at creating bindings are
> very much on topic here.

Here are a few :

- use the signal system in a more coherent way. Is a signal
  user-emittable, is it actually a virtual function, etc... Ask Karl
  about this. We have like 4 or 5 flags to tailor the way our code
  generator wraps signals.

- avoid "Item" structures like GtkMenuEntry, GtkToolbarChild,
  GnomeUIInfo, etc...

- abstract callbacks in some way. A callback is not necessarily a
  function pointer.

But then it's obvious that these are just for C++. So is it really
worth the effort, I'm not sure.

>  - The set of languages that are suitable for writing a toolkit
>    in is much smaller than the set of interesting languages.

Yes, but it's just a tad bit smaller than the set of languages
suitable to write a large-sized application in.

> Java and C++ are the languages where a GTK+ binding is perhaps not so
> clearly a win - Java has standard toolkit APIs in AWT and Swing, with Swing
> (assuming performance) being quite nice.

Actually the place where Java is thriving right now is on servers. :-)

> C++ has a large community of developers and there are a number of
> actively developed native C++ toolkits.

Not so many. In the same league as GTK+, there's only Qt, which has
faults of its own.

The problem with C++ and Java is that they are both much more
expressive than C, but are compiled languages as opposed to Perl or
Python which you can extend using C itself.

> But that does not meant that language bindings are a bad idea.
> In general, I'd consider them a good thing. It is better to 
> have one or two well-done toolkits than 10-15 half-baked toolkits.

I certainly agree with that.

-- 
					Guillaume.
					http://www.worldnet.fr/~glaurent