wxruby users - Aug 2004 - wxclasses-2.4.2.xml

I couldn''t find the original tex document that the author of the xml 
file converted from. Anyone knows where it is?

I am toying with the idea of _not using_ the xml file. Either getting 
the wx header files thru SWIG (I assume you guys have thought about this 
before already, any specific problems?), or continue with the template 
generator in the current wxruby-4.0.

The RUBY port of the SWIG seemed to be developed by the author of 
FXRUBY, guess it might be good to communicate with the FXRUBY camp as 
well, then.

Cheers,
Phuah Yee Keat

Phuah Yee Keat wrote:
> I couldn''t find the original tex document that the author of the
xml
> file converted from. Anyone knows where it is?
>
> I am toying with the idea of _not using_ the xml file. Either getting 
> the wx header files thru SWIG (I assume you guys have thought about 
> this before already, any specific problems?), or continue with the 
> template generator in the current wxruby-4.0.
Actually, you''re swinging back through old-old wxruby history. The 
wxruby I saw on savannah was doing exactly what you are talking about. 
Kevin would have to fill you in on the details, but I know it was a lot 
of work.
>
> The RUBY port of the SWIG seemed to be developed by the author of 
> FXRUBY, guess it might be good to communicate with the FXRUBY camp as 
> well, then.

We''ve been in contact with them. We''re following their
approach to
garbage collection.

Nick

Nick wrote:
> Actually, you''re swinging back through old-old wxruby history. The
> wxruby I saw on savannah was doing exactly what you are talking about. 
> Kevin would have to fill you in on the details, but I know it was a lot 
> of work.
Ok, so the wxruby went thru this

using swig directly ->
using wxpp.rb templating engine (current wxruby) ->
using xml with swig (wxruby-swig)

right?

I think I will browse thru the old-old mailing lists to get the 
details... ;)

Cheers,
Phuah Yee Keat

Phuah Yee Keat wrote:
> Ok, so the wxruby went thru this
> 
> using swig directly ->
This was before I got here. Curt checked a version of it into CVS in 
December 2002, but I never tried it. It was never widely released, but 
it was checked into cvs at the savannah site. I''m not sure whether it
is
still there or not. It is described at the bottom of the Changelog that 
is part of wxruby.

Independently, Park Heesob created a working wxruby without using any 
template or swig tools. Everything was hand-coded (lots of copy and 
paste), but it worked and supported lots of classes.

He handed it off to me in May 2003, and it became wxruby 1.0. Probably 
75% of the code in wxruby 0.4 is still Park Heesob''s work.
> using wxpp.rb templating engine (current wxruby) ->
Because I hate copy-and-paste, and based on what I learned when I helped 
create Ruby/FLTK, I could see that a template solution was needed. I was 
aware of swig, but every time I had tried to learn it, it seemed way too 
complex and painful.

So instead, I wrote wxpp from scratch, a little bit at a time. New 
classes were added using wxpp, and I was slowly converting existing 
classes to .t files as well. As it supported more classes and special 
cases, wxpp became more complex.

Someone asked why we weren''t using swig, so I investigated it again. It
had only recently added good C++ support ("directors"), so I realized 
that it would be much more powerful than wxpp, plus many people are 
already familiar with creating swig .i files.

Swig was the wrong choice back when wxruby started, but I am convinced 
it is the right method now. I view wxpp as a pale shadow of swig.
> using xml with swig (wxruby-swig)
But I wanted to avoid writing all the .i files from scratch, and the wx 
.h files are too messy to import directly into swig. I tried to find wx 
wrappers using swig for other languages (wxPython, wxLua), hoping to be 
able to use their work. But their .i files were all tightly bound to 
their target language.

I found the xml file, and thought it would be easy to write a little 
ruby app that would convert the xml into generic wx .h files. Those 
files could be used by anyone swigging wx for any language. That''s why 
the wxruby-swig .i files are separate from the .h files.

Unfortunately, the xml file is not quite accurate, so my extractor has 
to perform several fixes. And the xml file is quite large, so REXML was 
not able to process it effectively. I chose NQXML because I wanted a 
pure-ruby solution, rather than depending on a binary tool.

That''s where we are today.

---

Someone mentioned a project that uses swig itself to create the generic 
wx .h files as a first pass, and then runs swig again on those .h files 
to create the .cpp files. That seemed more complicated than the existing 
approach, so I have not explored it. I find the swig syntax to be pretty 
complex and hard to work with, actually, so I would rather have a ruby 
tool than a second set of swig control files.

You can find the latex source documents that are used to create the xml 
file in the wxWindows cvs tree under:
   wxWindows/docs/latex/wx

I don''t know if they are included in any of the wx distribution
packages.


Thanks again for your interest in wxruby,

Kevin