[paragui-dev] swigable paragui, etc.

[Leon Torres]

Hi,

My Paragui/ruby project is moving along pretty well, thanks to the awesome
swig project and the handy swig integration in Paragui. Most
things are working fine already, including callbacks and proper
downcasting. However, there are a few issues that are giving me some
headaches. So I'd like to bounce these questions/recommendations off the
list:

1) Multiple inheritance is not well supported in swig. This is causing
   every EventObject/MessageObject to be ignored (DropDown, MenuBar,
   SpinnerBox) by swig. I suggest that these objects be split into two
   classes: a basic one that doesn't subclass EventObject and a
   subclass that does. The functionallity provided by EventObject isn't
   necessary because of custom callback bindings in the swig interface.

2) Exiting from Ruby with a PG_Application running causes a segfault.
   Without studying the Paragui shutdown process, is there an obvious
   reason why this is happening? Is there some mandatory shutdown
   procedure that needs to be followed for a clean exit?

3) I found a way to separate the concerns between specific language
   bindings and the core project without having to create independent
   projects. This will break the old python bindings and cause a few
   changes in the GNU autotool setup. However, the Ruby stuff should
   provide a template to recover the python stuff, which is obsolete
   anyway, and jump start bindings to other languages. Still, I believe
   that the language bindings should be in separate projects for
   maintenance reasons. The setup I'm using now can be converted to that
   system with minimal effort. Which should it be?

4) There's no point in backporting the swig stuff to work with
   Paragui < 1.0.2. If someone wants the bindings, they should upgrade. ;)
   If the bindings are separated into different projects, version issues
   will be easier to handle. In particular, one version of the bindings
   might work across several paragui versions.

Bonus info: I'm documenting my work as well as I can. This should increase
the probability that Paragui gets swiged to a variety of scripting
languages. Viva paragui! :)

Extra info: The interface that swig vomits is ugly. C++ style functions
aren't very good looking in Ruby. Also, Paragui is Yet Another GUI TK
in the family of gui tks. Some Ruby enthusiasts have decided to mitigate
these two problems for all gui tks by creating an abstraction API layer
that sits on top of the gui tk of choice, sort of like JDBC/ODBC sits on
top of the choice of database. But it's Ruby only. Feel free to browse
the GUITopia project at:

  http://www.rubygui.org/cgi-bin/wiki.pl

Also, I won't be quitting this effort very soon. I really want to finish a
game I've been writing. If something gets in the way, I'll probably try to
break that wall down. See point (1) above. ;)

Cheers,
Leon