[Wxruby-dev] Rethinking my Approach to SWIG'ing wxWindows

[Curt Hibbs]

I've been trying to get moving on SWIG'ing wxWindows and I am having second
thoughts about just "porting" the wxPython interface files (although I would
still make use of them).

But before I get to that, let me say a little about what I've done to get
where I am right now. Since I am new to both SWIG and wxWindows, I wanted to
make sure that I had a good, working build of wxWindows, and that I could
successfully the Ruby samples that came with SWIG. Here's my activity log
(the false-steps have been edited out):

- wxWindows Installation
   - Unpacked the distribution
   - Built wxWindows
   - Ran sample apps to verify the build
- SWIG Installation
   - Unzipped the windows SWIG distribution
     (includes pre-built windows binary)
   - Added SWIG-1.3.14 to my path
- Ruby SWIG examples, building:
   - Unpacked Ruby source into <rubysrc>
   - Built ruby (did this to get config.h, needed by swig)
   - defined RUBY_INCLUDE = <rubysrc>
   - Defined RUBY_LIB = <rubyrc>\msvcrt-ruby17.lib
   - Opened & Built: \SWIG-1.3.14\Examples\ruby\simple\example.dsp
   - Opened & Built: \SWIG-1.3.14\Examples\ruby\class\example.dsp

As I started to look at porting the wxPython, I realized that I would have
to "swallow the elephant whole" instead of taking it in nice little
"bite-sized chunks".

I tried to identify a minimal set of wxPython interfaces that I could port
and then actually test in a running program. This turned out to be much
larger that I wanted. Then, on top of that, I would need to spend a
considerable amount of time analyzing and determining what is
python-specific and what is not (or what is still applicable to Ruby). All
this while coming up to speed with both wxWindows and SWIG. And then, when
things don't work, figuring it out could be very time-consuming (so many new
areas, such much initial code).

What I would rather do is take a very incremental approach where I start off
with something very simple (like a SWIG'ed wxWIndows interface that only
lets you create and destroy a top-level window). This simple start can then
be incrementally built-out. Since each addition is small, when something
goes wrong you know where to look. The wxPython interface files can be used
as a source of "advice" and from which to cut-and-paste snippets of code.

So unless someone else has a better idea, that is how I am going to proceed.

Once I have that initial, minimalistic api SWIG'ed I will check that code in
to CVS and then come up with groupings of the remaining apis that Bob and I
(and anyone else) can divide and conquer in parallel.

Curt