But after learning about FXRuby, it is apparent to me that there is more
activity going on with FXRuby (now at version 1.2.x. wxRuby seems parked
at version 0.6, last updated at nov-2002).

I don't know FOX/FXRuby at all, but would like to hear someone's opinion
of the good/bad/ugly of those two toolkits.

It seems to me that FXRuby is the way to go.

I'm not sure when the next release will be, but rapid progress is being
made. I'd suggest subscribing to the wxRuby ML since you are already
familiar wxWidgets.

It all depends on whether you want to play around with the GUIs, or plan to
actually deploy a graphical Ruby application. For the former case, I guess
anything goes, for the latter, the end users might feel weird with a non-native
GUI.

So we switched to ruby-gtk2 and use glade to draw our GUI's and
connect signals to events. The API is wonderful, everything works as
expected. Good docs. We redid our entire GUI (ok, it's a small app) in
just 10 hours. Linux is the main platform for it, although it might be
possible to run in win as well with some work.
http://ruby-gnome2.sourceforge.jp/

QtRuby also seems to have a nice API, but I haven't gotten it to work.
http://developer.kde.org/language-bindings/ruby/

Never tried FXRuby, mainly because it looks just plain ugly. (But
looking plain ugly on all platforms is better than wx that works on
some platforms and not others...)

2. My needs include a full featured text editor (my first preference is that
it have all the functionality of nedit), and to start with, an HTML
"renderer"--eventually I'd want to replace that with something more like a
real browser.  Does wxWidgets have anything like those?

   http://rubyforge.org/mail/?group_id=35

And the wxRuby home page is here:

   http://wxruby.rubyforge.org/

Your best bet would be to ask these questions on the wxRuby ML, I'm not
closely involved any more.

Curt,

Thanks!

Here's a 'hello world':
http://developer.kde.org/language-bindings/ruby/index.html

And it's already working with Qt4:
http://www.kdedevelopers.org/node/1123

Ruby and Qt seems like a perfect match since both are thought OO from
scratch. And you keep your application multiplatform, with a native
looking GUI.

dvn> The "ugly" says is all. FOX looks very foreign to me on Windows, doesn't seem to
dvn> even try to look like the XP widgets do. I stopped playing with FreeRIDE
dvn> because of the file dialog used, which doesn't remember the last location
dvn> visited, for example.

No toolkit does this as it is the task of the GUI application itself,
otherwise different open dialogs would show the same directory. So you
must blame FreeRIDE here.

FOX 2.0 will have theming. There is a patched FOX version out there
(search the mailing list) which already uses the windows theming API and
looks as native as you want it. Unfortunately you can't link this
together with FXRuby.

dvn> It all depends on whether you want to play around with the GUIs, or plan to
dvn> actually deploy a graphical Ruby application. For the former case, I guess
dvn> anything goes, for the latter, the end users might feel weird with a non-native
dvn> GUI.

Right. But if the target audience are also technical people the different
FOX look is not so important. In times of skins, web applications and
dozens different GUI themes, the consistence look is not so important
anymore.

b> I know wxWindows for C++ rather well, and have started to use wxRuby.

b> But after learning about FXRuby, it is apparent to me that there is more
b> activity going on with FXRuby (now at version 1.2.x. wxRuby seems parked
b> at version 0.6, last updated at nov-2002).

Looked at wxRuby yesterday and the last huge checkin was 30 hours ago.
Active but maybe a little bit to active if you want a stable system.
I wouldn't even sure if they now have an API that they want to keep
stable.

b> I don't know FOX/FXRuby at all, but would like to hear someone's opinion
b> of the good/bad/ugly of those two toolkits.

One of the best things is that FOX is that it is without doubt the winner
when it comes to speed problems. Populate the FXTreeList with 10000
items in less then a second ? No problem for FOX. Odr do you want to
put up a complex form dialog in 100 ms - don't try this with QT oder GTK.

And if you ever need to do something special, so you have to modify
the C++ source then you will see that FOX is miles ahead to GTK or
QT's internal architecture.

b> It seems to me that FXRuby is the way to go.

The major problem are no unicode, restricted widget set (no styled
text widget - but scintilla works as third party, no HTML widget), a
really bad implementation of menus and no theming.

You can see more information and examples here:
http://developer.kde.org/language-bindings/ruby/index.html

From that same page, a translation to QtRuby of Qt Tutorial #1
http://developer.kde.org/language-bindings/ruby/tutorial/tutorial.html

There is even a QtRuby shell where you can create widgets
interactively from the command line.

Hello world in QtRuby:

#!/usr/bin/ruby

require 'Qt'
a = Qt::Application.new(ARGV)
hello = Qt::PushButton.new("Hello World!", nil)
hello.resize(100, 30)
a.mainWidget = hello
hello.show()
a.exec()

For KDE applications you change require 'Qt' for require 'Korundum'

On 8/8/05, Stephan Mueller <d4...@web.de> wrote:

I am very sorry to hear that. wxRuby is still definitely a beta-quality
product. Until recently, only a few people have contributed much code to
the project, so it has evolved rather slowly. There seems to be some
good momentum now, with several people submitting code patches, so
hopefully this will change.

 > The main obstacle was bad docs,

Understandable. We have been focused on getting the basic code working
as a first step. I would rate the documentation as about average for a
FLOSS project. Definitely better than many, but still rough.

 > even the docs at wx's main site are confusing.

I think there is a lack of good examples and tutorials, but otherwise I
have found the wx docs to be pretty complete. I would be interested to
know which parts are confusing.

 > The wx API interface seems rather bloated in general and this
 > translates over to wxRuby.

True. Solving this will be our next phase, after we get a basic wrapper
working. That's the approach that FXRuby took as well, since the FOX API
was a bit heavy.

Once we have wxRuby working, we can add lots of Ruby sugar on top to
make the API much more pleasant. The wx API is definitely not the
cleanest of the GUI toolkits. That's partly due to its maturity (10+
years), and partly due to its use of native widgets where possible.

 > We also had problems getting the sizers to work as we wanted,

Sizers can be a challenge. Perhaps that's the part of the wx docs that
you found confusing, and I would probably agree. The sizer API is a bit
odd, and some of the docs still describe the deprecated mechanism that
was replaced by sizers. It will be interesting to see if we can cook up
some really cool ruby-ish API improvements for sizers. At a minimum, we
can create several good examples.

 > and things working on windows and not working on Linux etc.

There are a few features that are only available on specific platforms
due to native-widget issues. Not many, though. Generally, wx itself
works very well across multiple platforms. wxRuby probably has more
issues at this point, but we plan to fix them.

 > The final nail in the coffin was when we hit the (known)
 > bugs and had to code around them.

Yup. I sure wish wxRuby could have made faster progress.

 > So we switched to ruby-gtk2

That's a fine toolkit, and I'm glad it is working for you. It isn't
really fully cross-platform, so it's not directly comparable.

 > QtRuby also seems to have a nice API, but I haven't gotten it to work.
 > http://developer.kde.org/language-bindings/ruby/

I haven't tried QtRuby, but also has different strengths and weaknesses
compared to wxRuby. Qt has much more restrictive licensing for example.

 > Never tried FXRuby, mainly because it looks just plain ugly. (But
 > looking plain ugly on all platforms is better than wx that works on
 > some platforms and not others...)

FXRuby is a great toolkit, and probably the one I would recommend to
anyone who needs a full-featured cross-platform GUI toolkit today. The
main reason I choose to work on wxRuby instead is because FOX doesn't
use native widgets.

And of course there are still other toolkits that weren't mentioned
here. Each has some advantages and disadvantages.

* Gerardo Santana Gómez Garrido <gerardo.sant...@gmail.com> [050808 21:42]:

Cheers,

I like wxRuby, and in spite the somewhat lacking documentation for
wxRuby, one can get by with the docs for wxWindows, which are quite good.

That said, I have read some complaints about the supposed slow speed of
wxRuby, but so far I'm very satisfied with the speed of the wxRuby
application I'm working on now (it is at least 'fast enough').

    QTime before = QTime::currentTime();
    QListView * table = new QListView(win);
    table->addColumn( "My column" );
    QString temp("My field %1");

    for (int i = 0; i < 10000; i++) {
        new QListViewItem( table, temp.arg(i) );
    }

    QTime after = QTime::currentTime();
    win->show();
    QTime afterShow = QTime::currentTime();

    qDebug(QString("Time to load 10000 QListViewItems: %1 ms showing
QListView: %2 ms")
        .arg(before.msecsTo(after))
        .arg(after.msecsTo(afterShow)));

I get:

Time to load 10000 QListViewItems: 169 ms showing QListView: 2598 ms

So about 3 seconds for 10000 items. Most of that is drawing which will vary
according to different styles used, or whether running Qt on Windows or Mac
OS X.

There is an example called 'widgets' in Qt which has lots of different
widgets and is much bigger than any dialog, I changed the code to time how
long it took:

    QTime before = QTime::currentTime();

    MyWidgetView* w = new MyWidgetView;
    a.setMainWidget( w );

    QTime after = QTime::currentTime();

    w->show();

    QTime afterShow = QTime::currentTime();

    qDebug(QString("Time to load dialog: %1 ms showing dialog: %2 ms")
        .arg(before.msecsTo(after))
        .arg(after.msecsTo(afterShow)));

I got:
Time to load dialog: 345 ms showing dialog: 32 ms

I not sure if you could notice the difference between 100 ms and 345 ms, but
certainly the toolkits are roughly comparable in speed. FOX probably has a
smaller memory footprint than Qt though.

http://raa.ruby-lang.org/project/preferences/

I wrote it to use with FXRuby, but there's nothing particularly
fox-bound about it, except for the version of the four-split.rb example
that remembers splitter and window positions. It works just fine to
remember directories in FXFileDialogs and their ilk.

RD> I not sure if you could notice the difference between 100 ms and 345 ms, but
RD> certainly the toolkits are roughly comparable in speed. FOX probably has a
RD> smaller memory footprint than Qt though.

Sorry there were many tests that shows that FOX is faster
then QT. I don't have time to search them in the mailing list just to
present them here in the mailing list - simply accept this.

QT is in many cases far from reaching this especially with the layout
algorithms for complex dialogs eat up a lot of time as the layout is not
deferred.

No it's not.

Did you ever look at the FOX source code ?
It seems to me that like many toolkits trolltech tried to make the use of
the buildin widgets as easy as possible but not the subclassing and
customization of them.

RD> easy to customise. For instance, in Qt 4 you can customise the model for a
RD> 10000 item tree view, so it only loads the view from the model on a lazy
RD> basis when the data needs to be displayed on the screen. Then your timings
RD> above about FXTreeList wouldn't be directly comparable.

Okay, but this adds much more work to the programmer, something that is not
necessary for FOX. And normally the only time when you want to do this
is when displaying for example database records where the retrieving
of the data is expensive, not the display of it.

Sorry FOX has a lot of weaknesses and for many many people QT is
without doubt a much better solution, but speed and design (if you
need some special customized GUI ideas) are not among them.

I also have a hunch Windows automatically stores the last location used by an
instance of a native File Dialog somewheres in the registry, at least while the
program is running. I'll have to toy around with SWT or wxPython to verify
that.

Still, the discussion was which of two toolkits to use, and I think it is very
unlikely a synthetised widget toolkit can by definition "get things right"
sooner or more completely than a native one, and there's always a quirk lurking
behind the corner.

Skinning and theming is more of an issue for the OS, or window manager if you
wish, and having your application apply its own settings is not really an
advantage.

dvn> Still, the discussion was which of two toolkits to use, and I think it is very
dvn> unlikely a synthetised widget toolkit can by definition "get things right"
dvn> sooner or more completely than a native one, and there's always a quirk lurking
dvn> behind the corner.

Correct. The question is: do you want a multiplattform toolkit ? If
not then the answer is almost always the native toolkit (i guess it's
vruby in this case). Otherwise it depends on your target audience and
your required features. With wxwidgets you easily get into platform
specific problems that you can for example avoid with a synthetised
one.

If you need exact match of look and feel, for example for MacOSX
programs for the average user, you don't have any chance to use
anything other then carbon/cocoa.

Correct, this only applies to Windows. On MacOSX you simply don't have
themes only Aqua (in a blue or grey flavour). On Linux there are so
many and so many different desktops and window manager that it makes
no sense to talk about this, at least if you don't market the
application as Gnome or KDE application. Only on Windows you have a
standarized theming API with multiple different looking themes.

dvn> Strange I never hear the argument about L&F consistency not being important from
dvn>  any end users.

I never heard it from any of the Arachno Ruby users.

Instead they request application level consistency, which means i want your
application to behave like IntelliJ, Eclipse, Emacs, VI etc.

A friend of mine is responsible for a CD burning program, and you know
what he here from end users: Why don't you make it L&F like Nero.