gutopia-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rgui-dev] Camelot


From: Curt Hibbs
Subject: RE: [rgui-dev] Camelot
Date: Wed, 28 Aug 2002 10:14:25 -0700

Tom Sawyer wrote:
>
> while i have not heard each of your final thoughts on the matter, i'm am
> now quite certain what we must do.
>
> the key concept here is TIME. we all want this thing ASAP. but i won't
> allow that to keep us from making GUtopIa the best that it can be. we
> will do what we have to do. period.

I feel like pendulum, swinging from wild fantasy, to stark reality, and now
back to realistic pragmatism.

My previous mini-push for SWT was born out of my utter frustration at not
being able to solve the threading problem for FreeRIDE's current choice of
FOX. When I saw little bit of leaning toward SWT, my gut reaction was "cut
your FOX losses and go for it".

Then reality set it, and hence the recent wxWindows postings. And now,
ultra-reality is bringing me back to my original priority -- FreeRIDE. I am
still very much interested in GUtopIa (which is why I provided as much
support as I have), but more as a user of GUtopIa than as a developer.

> having said that, you would be mistaken to think that using something
> like wxWindows is going to be the great time saver. why? because it
> doesn't exist. but even so, more importantly it makes us dependent on
> another layer of code. indeed, the way out of this has become
> increasingly clear to me: reduce the code requirements as much as
> possible. and that can only mean one thing.

Of course you meant that the Ruby bindings to wxWindows doesn't exist. But
when you say that wxWindows would not be a timesaver, I have to disagree.
More on this below...

> this is what we shall do:
>
> we will use Ruby/DL to bind straight to the required .dll/.so libraries
> to build our respective GUtopIa Interfaces. nothing in between, no extra
> layers. perhaps a little akward having to embue our Ruby with some
> C-esque script, but it will be clean, direct, fast, and, best of all, we
> can start on it NOW.

This approach just replicates the problem we have with the SWT approach.

You make it sound like a wxWindows layer isn't doing anything useful, just
sitting there slowing things down. When, in fact, it is doing a very large
portion of what you would have to do in Ruby, but faster because its written
in C. Plus its mature, stable, debugged, and already available and just
about every platform. The idiosyncratic problems that inevitably come up on
each platform have been delt with and fully debugged (did I mention that
this code is debugged?). WxWindows already supports I18N and native
integration.

It would seem to me to be a very stable platform upon which built a
rubyesque meta-api.

I'd be willing to bet that Ruby/DL bindings directly to the Windows APIs
would alone be more work than developing wxWindows bindings (especially once
you include all of the Ruby code needed bridge the
behavior/functionality/window-bug gaps).

> hence, we will delegate like so:
>
>   Windows   : Bob and Curt
>   Linux GTk : Tom
>   MacOS X   : ? (have to find someone. anyone?)
>   ParaGUI   : Leon
>   Wise      : Kero (have to work out multi-platform issue, we'll talk)

While I'm not bowing out completely, I probably have to join Laurent in
saying that my primary passion is FreeRIDE. Although work on a wxWindows
binding to Ruby would be very much in line with FreeRIDE's short-term needs
(with an eye on GUtopIa for the long-term).

Curt





reply via email to

[Prev in Thread] Current Thread [Next in Thread]