Martin Man wrote:
I’ve prepared a short proposal on how to quickly (but without loosing
features) create qt3 extension module for ruby, …, if you are interested
please read on and comment. This proposal came from the fact that we have
actually gcc-xml output of all qt3 headers that can be reused somehow…
note that such proposal does not include any talk about signals and slots,
these have to come yet, but it hopefully covers the c++ overloading
I proposed a similar solution already. Please refer the last thread on qt.
I could imagine some improvement to your solution:
ooops, must have missed this one, but I admit I was checking just ruby-qt
For each qt class with virtual functions an overridable and not overridable
version. This would improve performance in the very commmon case, when you
know that you don’t want to reimplement any virtual functions.
well that sounds nice, but it means walking manually thru all the header files
and marking which funtion will be overridable and which not, and this I’m
willing to give up in favor of full automatic generation, unless someone wants
to make this monkey work (only once, but it has to be done)…
For the overridable class, I would create a function pointer table (playing
the same role as the virtual function pointer table.), having the pointer to
the original virtual methods. If a new method on the ruby-side is defined,
then it could change the pointer in this new method table. This, again,
would improrve runtime.
this seems quite nice (concerning the speed issues), but how would you catch
the method creation (in ruby) so that you can swap the function pointers ??
Some weeks ago, I created the XML files for qt3 using xmlgcc. This was
fairly straightforward. I also created a small Ruby programm using REXML,
that parses the generated representation and builds an internal
representation which could be used to generate the wrapper.
yup, I suppose I’m playing with your files, thanx, I’ve yesterday also crafted
something that already can produce some basic code, usless yet though…
I planned to write a complete wrapper using this implementation, since the
SWIG has some annoying features including the strangeness for the .new
I hope these were fixed in 1.3.12, that’s why I’m proposing to use swig
finally, since all this wrapping into VALUES and back is not trivial…
Additionally, I would like to see a more intuitive handling of properties,
all the methods setXXX could be renamed to XXX=,
I hope this could be done quite easily in cases where return type of method is
void and method acceppts only one parameter and matches /^set[A-Z][a-zA-Z_]+/
and a block oriented wrapping of signals. I.e., I would like blocks to be
connectable with signeals immediately, which would be the real Ruby way.
yes, that would simply be cool…
Best regards, Christian
P.S. I’ll take a look at your script, thanx…
On Tue, Jun 11, 2002 at 10:19:49PM +0900, Christian Szegedy wrote:
The things that make a person a good programmer are the same ones
that stop him from being a good manager.
– derrickh @ slashdot.org