GUI programming for WinXP/Linux/OSX?

[Une bévue]

I never tried it. However, if you give me a short list of FOX
applications, I'll be glad to try them and report my opinions.

i never get more deeper than "hello workd" ;-)

the same for QtRuby and Java-Swing-Ruby (JRuby is toooo slow).

for ui design i'm mostly doing Cocoa (and RubyCocoz) and Java-SwingX
years ago...

for the time being i don't have a need for X-platform however within
weeks or month i'll need that.

 

[Une bévue]

see also http://wxwidgets.org/about/screensh.htm

is that working on Mac OS X, any experiment ???

 

[Sean Bryant]

see also http://wxwidgets.org/about/screensh.htm

My vote goes for wxWidgets. Which there are ruby bindings I believe.
wxWidgets translate to native bindings. Or at least they should.
Check out their site: http://www.wxwidgets.org/

Ruby bindings: http://wxruby.rubyforge.org/wiki/wiki.pl

 

[Reid Thompson]

Reid Thompson wrote:
=20
=20
is that working on Mac OS X, any experiment ???
=20

I've little to no experience with wxwidgets -- but I know that it is a
highly regarded cross-platform toolkit. =20

someone may have already mentioned wxglade...
http://wxglade.sourceforge.net/


there is also widestudio
http://www.widestudio.org/EE/index.html

http://www.widestudio.org/EE/prog-ruby/prog.html

 

[Marcelo]

Try wxPython: www.wxpython.org

Fits on all your requests, and is very mature.

Roman Hausner ha escrito:

 

[John Gabriele]

[snip]

As of now, the following choices seem to be available:

= Tk: comes with Ruby, so should be easy to deploy.
= Qt
= GTK
= JRuby plus some Java GUI, preferably SWT
= It seems there is also FXRuby (http://www.fxruby.org/)
(non-native widgetset).

And probably wxRuby too.

Does anyone know of some objective comparisons of these
approaches? Especially with regard to learning curve,
stability, integration with Ruby, interactive GUI design,
and ease of deployment?
As I said, I am new to GUI programming, so this all looks
a bit intimidating at the moment.

Here are some pretty general guidelines that I follow:

1. Browse around the various project's mailing lists. See which ones
you think tend to be the most helpful. Note, more mature toolkits with
good docs may be less active, but you can still see if user questions
are getting answered.

2. Have a look at the project's docs. Whichever toolkit you go with,
you'll be spending a lot of time with their docs.

3. Have a look at the project's various sample programs. The simpler
ones are often just a page of code. Then maybe look for some sample
code that uses a feature you know you'll be using, and see what you
think.

4. Finally, if they come with a GUI builder tool (like GTK's Glade),
you might try it out. Could save you a lot of time.

Note, re. GTK+ on Mac OS X:
http://developer.imendio.com/projects/gtk-macosx . The project still
seems to be moving along.

---John

 

[Alex Fenton]

see also http://wxwidgets.org/about/screensh.htm

is that working on Mac OS X, any experiment ???

Yes. The old (0.6.0) series is based on WxWidgets 2.4.2 and doesn't look completely native. It's actively developed on OS X for ppc and intel.

There is support for OS X-specific idioms, such as the placement of the 'About' menu item, and arrangement of dialog buttons.

ruby-cocoa and interface builder give the optimal range of Apple-specific widgets and layouts, but is obviously not cross-platform.

alex

 

[Mc Osten]

i never get more deeper than "hello workd" ;-)

well, it doesn't need to be your stuff
I simply don't know any application that uses it (and never looked for
one). So if you were aware of such an application, I would have tried it
gladly.

However, it looks like you do have a mac too, so I suppose if you knew
those applications, you would have tried them by yourself.

 

[Mc Osten]

I may be wrong, but I'm pretty sure FOX uses X11 under OS X. (But I
don't like how FOX looks on Windows or X as it is, so I may be biased)

From wikipedia:
Both Qt and wxWidgets have some support for programming natively on Mac
OS and Mac OS X platforms, which FOX currently does not support.

I suppose you are right.

And what about FLTK? And XUL? In fact it may be quite interesting...

 

[Joel VanderWerf]

M. Edward (Ed) Borasky wrote:
...

1. Tk is ugly, but it's a "de facto standard" and does come built-in. ...
The app I'm building will have a Dia/Visio/XFig/Inkscape-like "drag and
drop shapes onto a canvas" GUI, but not a full diagramming package. I've
actually considered using one of the open-source diagramming packages as

Tk does have a rather nice 2D Canvas widget with various shapes, layers,
groups, etc. I'd love to see a similar widget in Fox...

 

[Une bévue]

Yes. The old (0.6.0) series is based on WxWidgets 2.4.2 and doesn't look
completely native. It's actively developed on OS X for ppc and intel.

The old (0.6.0) series of what, i didn't catch it ))

There is support for OS X-specific idioms, such as the placement of the
'About' menu item, and arrangement of dialog buttons.

fine !

it is using C++ ? or could we use also C (works better with ruby) ?

ruby-cocoa and interface builder give the optimal range of Apple-specific
widgets and layouts, but is obviously not cross-platform.

yes a know, i'm using that framwork however i plane an X-platform app in
the near future...

 

[Une bévue]

However, it looks like you do have a mac too, so I suppose if you knew
those applications, you would have tried them by yourself.

right !

the most "live" app i'am using on mac, being not X11 dependant, are
SwingX-java and Swt-java (for X-platform).

i think also they are F-Script-Cocoa app, able to run on other platform
because Objective-C is also available over windows (by using gnustep ?)
and sure over *nix...

 

[Alex Fenton]

The old (0.6.0) series of what, i didn't catch it ))

wxRuby - http://wxruby.rubyforge.org/ - the ruby interface to WxWidgets.

PS - I meant to say that 0.6.0 is NOT being actively developed, but wxruby2 IS under active development on all major platforms.

it is using C++ ? or could we use also C (works better with ruby) ?

It's C++, but the ruby wrapper is generated using SWIG: http://www.swig.org/ to simplify the wrapping - it's a large library.

alex

 

[Une bévue]

wxRuby - http://wxruby.rubyforge.org/ - the ruby interface to WxWidgets.

PS - I meant to say that 0.6.0 is NOT being actively developed,
but wxruby2 IS under active development on all major platforms.


It's C++, but the ruby wrapper is generated using SWIG:
http://www.swig.org/ to simplify the wrapping - it's a large library.

fine thanks, everything is done by gem install in a few time ))

minimal/minimal.rb is working )))

 

[M. Edward (Ed) Borasky]

Both Qt and wxWidgets have some support for programming natively on Mac
OS and Mac OS X platforms, which FOX currently does not support.

I suppose you are right.

And what about FLTK? And XUL? In fact it may be quite interesting...

I don't think FLTK has a Ruby binding yet.

 

[MonkeeSage]

Just a note about Tk -- it has built-in *bindings* in ruby, not a
built-in toolkit. You still need the Tcl/Tk backend, which must be
installed seperately on windows or *nix or mac. Not to mention that
Tile must be installed seperately (for the tk 1.8 stable branch at
least). Unless I've missed something, the only thing built-in about Tk
is the bindings, not the toolkit itself.

Regards,
Jordan

 

[Mc Osten]

I don't think FLTK has a Ruby binding yet.

<http://ruby-fltk.sourceforge.net/>
<http://sourceforge.net/projects/ruby-fltk/>

However, I never tried it.

 

[Une bévue]

<http://ruby-fltk.sourceforge.net/>
<http://sourceforge.net/projects/ruby-fltk/>

did u get some screenshots elsewhere ?

 

[Mc Osten]

did u get some screenshots elsewhere ?

No.
I just googled this one.

 

[M. Edward (Ed) Borasky]

The cross-platform GUI solutions tend to have little (or big!)
deviations from the normal native GUI application behavior on one or
more of their supported platforms. It often turns out to be worth it to
separate the GUI from the rest of your project, and then you can do the
GUI separately on each platform using whatever tools you would use if
that was the ONLY platform you had to support, and do the rest of your
project in whatever you want (e.g., Ruby), because the users will never
have to see it.

At first, this sounds like about 4 times as much work, as you are doing
your project's code, plus three separate GUIs. However, the GUIs should
be pretty simple.

If you make the GUI and the rest of the project communicate using some
kind of RPC over TCP, you even get, for pretty much free, the ability to
have the GUI remote.

Or use Rails and make a browser-based GUI with Ajax.