Ruby-qt3 proposal (c++ based extensions)

ruby-talk
1

hi all,

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 problem…

rgds,
martin

p.s. there are some issues left, curious if someone is going to point them out
;-))

README (2.36 KB)

···

–
Brian: Have I got a big nose, Mum?
Mandy: Stop thinking about sex!
Brian: I wasn’t!
Mandy: You’re always on about it. “Will the girls like this?
Will the girls like that? Is it too big? Is it too small?”
– Life of Brian, Monty Python

2

Martin Man wrote:

hi all,

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 problem…

I proposed a similar solution already. Please refer the last thread on qt.
I could imagine some improvement to your solution:

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.

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. The drawback would be that the handling of
singleton methods can get quite complicated, if not impossible. This no tragedy,
but it must be documented then. (Using this strategy, the first proposal may
get unnecessary.)

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.

I planned to write a complete wrapper using this implementation, since the SWIG
has some annoying features including the strangeness for the .new methods.

Additionally, I would like to see a more intuitive handling of properties, i.e.,
all the methods setXXX could be renamed to XXX=, 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.

I have attached my intial Ruby script I planned to be the base of this new
wrapper generator. The most complicated part of the script (which I does not assume
to function 100%-ly correctly), is the output of type names and function
declarations based on the internal representation (The with_full_type methods).
However, this will be quite crucial for the planned wrapper generator.

Best regards, Christian

parse.rb (11.1 KB)

3

Martin Man wrote:

hi all,

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
problem…

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
yahoo group.

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
methods.

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,
i.e.,
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

rgds,
martin

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

4

I planned to write a complete wrapper using this implementation, since the SWIG
has some annoying features including the strangeness for the .new methods.

I don’t really want to stumble into the middle of the Qt3 part of this
discussion but I was curious about what strangeness you’re seeing from
SWIG for the .new methods? I have the feeling this has been fixed for
the recently-released SWIG-1.3.12 but it would be good to confirm that.

5

Stepping into the discussion…

From: Martin Man [mailto:Martin.Man@seznam.cz]
Sent: Tuesday, June 11, 2002 3:45 PM
To: ruby-talk ML
Subject: Re: ruby-qt3 proposal (c++ based extensions)

…

Additionally, I would like to see a more intuitive handling of
properties,
i.e.,
all the methods setXXX could be renamed to XXX=,

You can do something like the following on top of the extension:

module Qt2
class QObject
def setProperties hash
for k,v in hash
prop = k.to_s
send “set#{prop[0…0].upcase}#{prop[1…-1]}”, v
end
end
alias config setProperties
end
end

Example code:

action = QAction.new win, name

action.config :menuText => “Window”,
:statusTip => “Creates a new workspace window”,
:toolTip => “Create new main window”,
:accel => (CTRL+Key_N)

This is what I do for Qt2.

BTW, I like this thread very much :slight_smile:

– Christian

···

-----Original Message-----

6

Lyle Johnson wrote:

I planned to write a complete wrapper using this implementation, since
the SWIG
has some annoying features including the strangeness for the .new
methods.

I don’t really want to stumble into the middle of the Qt3 part of this
discussion but I was curious about what strangeness you’re seeing from
SWIG for the .new methods? I have the feeling this has been fixed for
the recently-released SWIG-1.3.12 but it would be good to confirm that.

I have not checked the newer versions of SWIG lately. However I disliked
that one can’t override the initialize for derived classes with different
parameters. I would be pleased to hear that it is already solved.

Best regards, Christian

7

Martin Man wrote:

Martin Man wrote:

hi all,

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
problem…

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
yahoo group.

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)…

I was unclear on that point: for each class (not for each function), I would like
to have one overridable version and one not overridable. This could automatically be
done by a Ruby script using the XML file.

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 improve 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 ??

“method_added”

Best regards, Christian

···

On Tue, Jun 11, 2002 at 10:19:49PM +0900, Christian Szegedy wrote:

8

I don’t really want to stumble into the middle of the Qt3 part of this
discussion but I was curious about what strangeness you’re seeing from
SWIG for the .new methods? I have the feeling this has been fixed for
the recently-released SWIG-1.3.12 but it would be good to confirm that.

I have not checked the newer versions of SWIG lately. However I disliked
that one can’t override the initialize for derived classes with different
parameters. I would be pleased to hear that it is already solved.

Yes, that is solved in SWIG-1.3.12! I didn’t like not being able to
override initialize either :wink:

9

Christian Boos wrote:

You can do something like the following on top of the extension:

…

Yes one can do a lot of top of an extension, e.g. one could write
a short Ruby script wrapping all methods beginning with set,
but it would be great (and more performant) if the extension
would be apriori nice, and would support the methods in question
natively.

Best regards, Christian