FXRuby or wxRuby?

[Richard Dale]

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.

I tried this timing test on my 800 MHz G3 iBook running Linux with Qt 3.3.4:

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.

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.

That sounds pretty subjective to me. I think Qt is very well designed and
easy to customise. For instance, in Qt 4 you can customise the model for a
10000 item tree view, so it only loads the view from the model on a lazy
basis when the data needs to be displayed on the screen. Then your timings
above about FXTreeList wouldn't be directly comparable.

-- Richard

 

[Joel VanderWerf]

But FreeRIDE uses FXRuby/Fox, and Fox does not use the Windows standard
dialog. Therefore FreeRIDE would have to do this itself.

Curt

Sorta going off on a tangent here, as usual, but after working with
Fox's registry for a while I went off and wrote a more ruby-oriented
library for saving "preferences". Naturally, it uses yaml, and the
preferences persist between program invocations and not just method
invocations. Naturally, it's called "preferences". It's at:

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.

 

[Lothar Scholz]

Hello Richard,

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.
RD> That sounds pretty subjective to me.

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.

 

[david]

Hello david,
=20
dvn> The "ugly" says is all. FOX looks very foreign to me on Windows, d= oesn'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.
=20
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.

In this specific example, the dialog still looks very out of place on XP.=
And
the default location opened for a file dialog -is- the work of the GUI to=
olkit,
which should respect the default platform policy for that. Which would
obviously not be an issue if the dialog was the one provided by the OS wi=
dget
set.

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

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 an= d
looks as native as you want it. Unfortunately you can't link this
together with FXRuby.

I still have personal issues about reinventing the wheel. With synthethis=
ed
widget toolkits, you still usually go off and re-do the logic of applying=
the
theme on each OS. Or maybe not, I'm not going to pretend I've ever seen G=
UI
toolkit code here.

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 l=
urking
behind the corner.

Right. But if the target audience are also technical people the differe= nt
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.

I'm a technical person and I'm ticked off to no end by applications havin=
g an
out-of-place L&F. Right now I'm having problems giving my desktop a white=
on
black look to save what's left of my eyesight -precisely- because each an=
d
every app has its own mechanism of skinning, and applies system defaults =
rather
randomly. Gray88 text on a white background everywhere, because authors o=
f
skins, IDE editor settings, and stylesheets -always- presume I use a whit=
e or
light background, but don't bother to change the text colour settings alo=
ng. I
have an urge to stab someone in the eye with a rusty fork each time that
happens.

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.

Strange I never hear the argument about L&F consistency not being importa=
nt from
any end users.

 

[Lothar Scholz]

Hello david,

dvn> I still have personal issues about reinventing the wheel. With synthethised
dvn> widget toolkits, you still usually go off and re-do the logic of applying the
dvn> theme on each OS. Or maybe not, I'm not going to pretend I've ever seen GUI
dvn> toolkit code here.

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.

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

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.

 

[Gerardo Santana Gómez Garrido]

Hello david,
=20
=20
dvn> I still have personal issues about reinventing the wheel. With synth= ethised
dvn> widget toolkits, you still usually go off and re-do the logic of app= lying the
dvn> theme on each OS. Or maybe not, I'm not going to pretend I've ever s= een GUI
dvn> toolkit code here.
=20
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 qu= irk lurking
dvn> behind the corner.
=20
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.
=20
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.

I can have multiplatform and native look and feel with Qt. Here is a
screenshot of Qt Designer on MacOS X:

http://www.trolltech.com/images/screenshots/qt_designer_mac.png

The same application looks native on Windows too:

http://www.trolltech.com/images/screenshots/qt_designer_windows.png

--=20
Gerardo Santana G=F3mez Garrido
http://www.openbsd.org.mx/santana/
"Entre los individuos, como entre las naciones, el respeto al derecho
ajeno es la paz" -Don Benito Ju=E1rez

 

[Lothar Scholz]

Hello Gerardo,


GSGG> I can have multiplatform and native look and feel with Qt. Here is =
a
GSGG> screenshot of Qt Designer on MacOS X:

GSGG> http://www.trolltech.com/images/screenshots/qt_designer_mac.png

It's only a part of the look. There is much more then this in apples
application styleguide. Even with 4.0 you can't generate non trivial
native looking MacOSX applications. Drawers, Window local modal loops
(aka sheets) are still not supported.

And you always need different icons, different drag and drop,
different menu structure etc.

We discussed this a lot of times here on the mailinglist.


--=20
Best regards, emailto: scholz at scriptolutions d=
ot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
=20

 

[Dominik Schlütter]

Hi,

I can have multiplatform and native look and feel with Qt.

Not really. This uses some widgets you find in other Mac OS X
applications, but there are some faults - e.g. you usually don't see
those increase/decrease counter thingies and the order of the buttons is
wrong. On Mac OS that should be "Cancel" first and "OK" on the right.

Here is a screenshot of Qt Designer on MacOS X:

http://www.trolltech.com/images/screenshots/qt_designer_mac.png

The same application looks native on Windows too:

http://www.trolltech.com/images/screenshots/qt_designer_windows.png

To me (as a Mac user) the application in the first screenshot does look
like a windows tool with Mac widgets. That's also true for the
'Designer' application itself, which doesn't use the standard Cocoa
toolbars but something else (like the one found in Adobe Reader, at
least the icons are o.k.). Althouhg it has been improved from previous
versions of QT.


Regards,

Dominik.

 

[Sander Jansen]

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

I always loved this article on OShttp://osnews.com/story.php?news_id=10633

Best Quote: " I'm staring at my Windows taskbar right now and out of 7
launched applications, there are 6 not looking totally (or not at all)
native. And Winamp isn't even started (neither is iTunes).":

Sander