[Wxruby-dev] RE: Greetings from an old member ( was: RE: [FR-devel] Greetings from a new member)

[Curt Hibbs]

Bob Calco wrote:
>
> Curt - could you send me what you've got working so far? I just
> upgraded my
> wxWindows to 2.3.4, which is said to be the last one before 2.4.0, and it
> fixes a lot of little bugs in prior development versions. Mostly memory
> leaks and list box crashes on XP.

(I'll put most of my comments at the end.) I'm still using 2.3.2, but I
should also update to the latest.

> Having played with wxWindows for a day or two all by itself in C++, I am
> moving away from the notion of SWIGing the whole wxWindows API. I suggest
> instead we create our own library, statically linked to
> wxWindows, in which
> we subclass those elements we want (adding components incrementally with
> each release) in such a way as simplifies interfacing to Ruby
> (and there are
> specific strategies built into the wxWindows object model to facilitate
> this).
>
> The advantage of having our library statically link to wxWindows
> is we need
> not distribute the whole honking 2.7 meg wxWindows DLL in addition to any
> DLL we create. Nor will our distribution depend on a specific version of
> wxWindows being installed (or not installed) on the target machine.

I agree that we should create a statically bound library (for all the
standard reasons of avoiding DLL hell), but I would prefer to create out
library in Ruby, not C++ (following the SWT approach).

> We may find it necessary to SWIG our derived library, but we may
> not. I say
> first we come up with a basic "version 1" object model of
> components we want
> to implement, with FreeRIDE's needs primarily in mind. For
> instance, we all
> like that Scintilla editor, and it just so happens that there is a
> contributor project, not compiled as part of the wxWindows library proper
> but included in the source download, that wraps the scintilla
> editor. We'll
> need to make sure our library includes that and whatever else it
> needs from
> wxWindows to compile in version 1.0. There is also, associated with that,
> the original source code to scintilla, including the LexRuby.cxx code. I
> want to modify that dramatically and use my RubyParser LIB to enhance
> scintilla's ability to syntax highlight Ruby code - and make that part of
> our version 1 gui library.

Yes, I also noticed the inclusion of scintilla.

> To summarize, I think just SWIGing wxWindows is insufficient to
> creating the
> optimal version 1 Ruby GUI library, as there are other libraries, add-ons,
> and otherwise components that also need to be part of the mix.
>
> In the end I want to deliver a single shared library that has
> everything we
> need, but only what we need, and a separate one that does the actual
> interfacing to Ruby. The Ruby wrapper classes on top of this
> library should
> of course be higher-level and aimed at making GUI plug-ins easy to write.

The plan I was contemplating was to SWIG the parts of wxWindows that we need
(and, as you said, "only the parts that we need") and then extend that
functioanlity in Ruby. Like SWT, we would have two interface layers -- a
low-level interfrace that maps directly to wxWindows, and a high-level
interface that provides a Rubyesque interface.

If there are parts of the extension code that absolutely, positively have to
be in C/C++, then it is my hope that these can be contained within the C/C++
code specified in the SWIG interface files. In this way, running SWIG and
building the results will end up creating the low-level part of wxRuby.

Thanks to Park's port from wxPytyhon, I have a working version of wxRuby
that SWIGs a large part of wxWindows (all the parts using by wxPython). It
successfully runs a simple notepad-like test application written in Ruby. It
is not fully debugged, and it has not been run on any platform other than
Windows.

What I wanted to do was to write a suite of unit tests to exercise the
low-level api, and flesh out the bugs. Then use this suite of unit tests to
build/test/debug wxRuby on other platforms. Subsequently (or in parallel),
the Rubyesque higher-level api would be layered on top of this lower-level
api.

I really need to take what I've got and check it in to CVS. It hasn't been
obvious to me how the repository directories should be structured (I know
Laurent initially copied the FOX directory structure, but that doesn't seem
to fit either). Since I have been the only one working on wxRuby, there was
no pressing need figure it out.

Right now I have everything lumped into a single "swig" subdirectory. In the
interest of expediency, I will just check this in as it currently is. Just
as a reminder, wxRuby CVS access us at:

        http://savannah.nongnu.org/cvs/?group=wxruby

Curt

PS
   Bob, you can call me anytime between 6am and 8pm Pacific time. If I can't
answer, just leave a message and  will call you back.