RE: GUI's and the Rouge, Part III (yes, finally) 1/2

On Wed, 2002-07-24 at 08:39, Steve Tuckner wrote:
> What about WX-Windows. There is no ruby bindings for it, but would that fit
> the bill?

hi steve,

wxWindows is a good gui tookit, no doubt. but this clip from its webpage
makes it unsuitable for out purposes:

"wxWindows is not a translator from one GUI from another; it cannot take
a Motif application and generate a Windows application, for example. You
need to learn a new API. However, the wxWindows API has been praised for
its intuitiveness and simplicity, and can be far easier to learn and use
than a native GUI API such as Motif or Windows. Porting from MFC is
particularly easy due to its similarity: one user has ported his CASE
tool from MFC to wxWindows in a couple of weeks."

we require something common, i.e one api for all platforms. the Rouge
project sought to do this by translating to native guis where possible,
allowing for extension in the other cases. this translation is a
duanting task, if even reasonably possible. i purpose instead the use of
a themeable gui engine that can thus mimic the look and feel of the
native guis. this is a much more doable endeavor.

thanks for the suggestion though. i wish wxWindows could do the job. but
alas it cannot. did you have a chance to look at ClanLib. it is my hope
that this library will be suitable. i've studied in for awhile and it
looks quite promising.

~transami

> 
> Steve Tuckner
> 
> -----Original Message-----
> From: Curt Hibbs [mailto:[e-mail]]
> Sent: Wednesday, July 24, 2002 9:23 AM
> To: ruby-talk ML
> Subject: RE: GUI's and the Rouge, Part III (yes, finally) 1/2
> 
> 
> Tom Sawyer wrote:
> 
> [snip]
> 
> > it was stated that a main goal of Rouge was to create a cross-compatible
> > gui api that "boiled down" into the native gui of each platform. in my
> > first post on these matters, i pointed out how ungodly difficult that
> > would be (as i had been trying to do that myself). in the end either you
> > left to "patch" your app for each platform or you simply have to give up
> > the features that they hold in common (at best). it really is simply too
> > much of pain to create such an system, not to mention maintaining it as
> > those underlying native api change. yet the goal os a native look and
> > feel is not unachievable by other means. the solution is simply a matter
> > of using an underlying gui engine that is sufficiantly themeable. since
> > all the major gui's are now themable themselves, we simply need to code
> > a theme manager that can import the themes of those other guis. we need
> > not use their underlying api, only their look and feel! so that's what
> > can be done to solve that dilemma: use a sufficantly themeable gui api
> > and crreat and Themes and Behaviors Manger to emulate the look and feel
> > and even draw upon the native theme configuration files. this is a much
> > managable task then trying to channel down to the native guis
> > themselves. the only trick of course is finding that themeable gui api.
> 
> This issue wasn't so much native look-and-feel as it was native integration
> (its not the same). Native integration means that the widgets have the same
> behavior as native widgets (usually, because they *are* native widgets).
> Sean Russell made a pretty clear case for this in this posting:
> 
> 	http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/32029
> 
> Sean also mentioned SWT from the Eclipse project, which *does* this for
> Java:
> 
> 	http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
> 
> I think I said this before, but (just in case), the problem that the
> FreeRIDE project had (and still has) finding an adequate Ruby GUI toolkit
> that simultaneously satisfied the need for both native integration and
> internationalization. Of course other features are important, too, but these
> were the two big ones that just couldn't be found in one package.
> 
> Curt
> 
> 
-- 
~transami