On Thu, 2003-09-18 at 15:24, Andres Becerra Sandoval wrote:
>
> I have tested wxWindows in linux and windows 98 (with a free borland
> command line compiler) and the library works fine, have you tested in other
> platforms (winXP?, another Unix?)
>
> I am curious about your idea, have you evaluated the difficulty
> (time+people) needed for this task?
>
> Best regards,
>
Well there are a couple of different approaches one could take to
implementing it. The Python people created wxPython using SWIG, which is
widely supported and available; however, it would take time to create an
extension to SWIG for Oz, which would be desirable to take advantage of
all that SWIG has to offer and standardize on wrapping strategies.
As an alternative to SWIG I am intrigued by a lesser known "wrapper
generator" specifically aimed at the complexities of C++ libraries,
called CABLE (http://public.kitware.com/Cable/HTML/Running.html).
Specifically, CABLE's approach allows you to write generators that are
capable of parsing arbitrarily complex C++ code and defining the output
for all cases (SWIG has limitations for arbitrarily complex C++ code).
However, currently its maintainer only has a generator for TCL, nor does
it appear to be widely used. I do however prefer CABLE's approach to
SWIGs.It is cleaner and more consistent with C++ Zen Mastery.
Then there's the old fashioned way: Code the C++ extensions directly and
write Oz wrappers by hand.
Given that in order to write extensions for SWIG or CABLE one must
possess intimate knowledge of the desired output for Mozart, I'm leaning
toward the third mainly as an exercise in acquiring that intimacy.
I have not attempted to quantify the LOE yet, but it would not be a
trivial endeavor to do correctly. wxWindows is a complex API and a
feature-rich toolkit, and some thought needs to be done upfront about
how to make the extension to Oz not merely easy to use, but also robust,
secure, thread-safe and, on top of that, designed in a way that takes
advantage of Oz's semantics. A brute-force transliteration is not likely
to make it any of the above.
Another desirable feature is that it should be possible to use wx
primitives to write component widgets in Oz. It should also be easy to
write native wx components and create wrappers in Oz. So eventually the
project ought to pick either SWIG or CABLE and extend one of them to
facilitate/automate rapid development of future GUI components.
But thank you for your interest; perhaps we can establish a wx Task
Force, so to speak, to analyze wx and establish the requirements for the
first iteration of the integration?
Sincerely,
Bob Calco
Senior Software Architect
WebMD Practice Services, Inc.
Alachua, FL
bcalco@webmd.net
bobcalco@alltel.net
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.