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

[Laurent Julliard]

Curt Hibbs wrote:
> 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

So far you got it right :-)

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

This is exactl how I would have proceeded myself. Identify the base 
classes and then take the Window class which is (I guess) at the top 
of the class hierarchy and start from here.

One thing you could do as well is process the wxWindow code through 
some sort of code navigation utility that also generates class 
inheritance and you can easily see what are the base classes and how 
the widget classes are organized. From there take a top down approach

Keep going!

Laurent