RE: [rgui-dev] Camelot

[Tom Sawyer]

On Wed, 2002-08-28 at 11:14, Curt Hibbs wrote:
> I feel like pendulum, swinging from wild fantasy, to stark reality, and now
> back to realistic pragmatism.

that's a good sign, in means your are taking all sides and not being
dogmatic.
 
> 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.

so i take it your going to head back to FOX and figure it out? that's a
good approach, if it can be solved (somehow someway i'm sure) but i must
encourage you to consider your future, a la Massimiliano's post.
 
> 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 approach just replicates the problem we have with the SWT approach.

no it actually dosen't, this approach removes a whole layer of concern.
no matter how the backend works, GUtopIa's Meta-API will have to be
translated into it, whether it be SWT or other. So why add all the work
of building a binding to SWT? That is what is done away-with in my
approach. Let each developer responsable for a backend create a GUtopIa
interface to meet the GUtopIa spec, and that's all --nothing else to
worry about.
 
> 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).

well, perhaps, if Bob were almost done. but you know what, even so, i'd
rather not be dependent on YAL (Yet Another Layer). just more place for
bugs to creep in, less control in our court, etc. by delegating the
various backends, we can quickly build GUtopIa and take on the likes of
wxWindows readily. why? cause we'd be using Ruby, not C. just ask Leon
about that ;-)

> > 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, and Laurent, if you want something bad enough, you will fight for
it. you will do what needs to be done. i understand if you have other
things on your plates. but it seems to me, you both want this. you both
see the importance of getting something like this out there, for Ruby,
for FreeRide. so why won't you bite the bullet? MAKE the time! Even just
a little bit, working as a team, can go a long long way.

lets do this thing and lets do it right. give me your hand and i'll show
you just how fast and well we can make this happen.

~tom