I know wxWindows for C++ rather well, and have started to use wxRuby.
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.
Regards,
Baalbek
baalbek wrote:
I know wxWindows for C++ rather well, and have started to use wxRuby.
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).
Actually, there is a *lot* of wxRuby activity going on. But you wouldn't know it if you're not subscribed to the wxRuby mailing list. The 0.6 version that you see has been totally rewritten using SWIG resulting in a must more robust wrapping of wxWidgets.
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.
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.
FXRuby is a good choice if you want a synthesized widget set that looks the same on all platforms. If you want native widgets, then wxRuby is the way to go.
Curt
Citát baalbek <rcs@bgoark.no>:
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 actually find even the 0.6 version very usable, most of the GUI classes are
there. Although I'd personally like a rebuild of the Windows version with
wxWidgets 2.6.0, but that's just a pet peeve for being on the bleeding edge
accompanied by a reluctance to compile extensions on a Windows box.
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.
The "ugly" says is all. FOX looks very foreign to me on Windows, doesn't seem to
even try to look like the XP widgets do. I stopped playing with FreeRIDE
because of the file dialog used, which doesn't remember the last location
visited, for example.
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.
David Vallner
My experience with wxRuby has not been very pleasent. The main
obstacle was bad docs, even the docs at wx's main site are confusing.
The wx API interface seems rather bloated in general and this
translates over to wxRuby. We also had problems getting the sizers to
work as we wanted, and things working on windows and not working on
Linux etc. The final nail in the coffin was when we hit the (known)
bugs and had to code around them.
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...)
Cheers,
Olof
Have you considered QtRuby?
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.
On 8/8/05, baalbek <rcs@bgoark.no> wrote:
I know wxWindows for C++ rather well, and have started to use wxRuby.
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.
Regards,
Baalbek
--
Gerardo Santana Gómez 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árez
Hello baalbek,
I know wxWindows for C++ rather well, and have started to use wxRuby.
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).
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.
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.
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.
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.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
david@vallner.net ha scritto:
The "ugly" says is all. FOX looks very foreign to me on Windows, doesn't seem to
even try to look like the XP widgets do. I stopped playing with FreeRIDE
because of the file dialog used, which doesn't remember the last location
visited, for example.
Maybe this can interest you: if you look at mondrian IDE, which should be now free/open sourced, you may notice it uses a native file selector on win32 even if it is using FOX, thanks to win32.rb.
It is extremely simple to take the file selection class and import it in freeride, since it basically just overrides FXFileDialog (IIRC).
I did it for my own use in the past, but I never contributed it to FR since I'm not sure about the legal issues.
1. So, where is the wxRuby mail list?
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?
regards,
Randy Kramer
On Monday 08 August 2005 07:14 am, Curt Hibbs wrote:
Actually, there is a *lot* of wxRuby activity going on. But you wouldn't
know it if you're not subscribed to the wxRuby mailing list. The 0.6
version that you see has been totally rewritten using SWIG resulting in
a must more robust wrapping of wxWidgets.
Hello david,
The "ugly" says is all. FOX looks very foreign to me on Windows, doesn't seem to
even try to look like the XP widgets do. I stopped playing with FreeRIDE
because of the file dialog used, which doesn't remember the last location
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.
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.
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.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
* Gerardo Santana Gómez Garrido <gerardo.santana@gmail.com> [050808 19:15]:
Have you considered QtRuby?
Does it work with the windows version of Qt4 as well? I was wondering if
this is just a KDE-only project or a really multiplatform qt wrapper.
Steph.
I'm posting this on behalf of Kevin Smith who is leading the current surge of wxRuby development.
----------------------------------
olof sivertsson wrote:
> My experience with wxRuby has not been very pleasent.
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.
Kevin
Curt Hibbs wrote:
baalbek wrote:
I know wxWindows for C++ rather well, and have started to use wxRuby.
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).
Actually, there is a *lot* of wxRuby activity going on. But you wouldn't know it if you're not subscribed to the wxRuby mailing list. The 0.6 version that you see has been totally rewritten using SWIG resulting in a must more robust wrapping of wxWidgets.
I'm glad to hear this!
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.
Baalbek
Lothar Scholz wrote:
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.
This is definitely a plus!
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.
Well, visually pleasing applications do tend to be favoured amongst the 'commoners' , even if they are slower.
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').
Baalbek
Lothar Scholz wrote:
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
Randy Kramer wrote:
Actually, there is a *lot* of wxRuby activity going on. But you wouldn't
know it if you're not subscribed to the wxRuby mailing list. The 0.6
version that you see has been totally rewritten using SWIG resulting in
a must more robust wrapping of wxWidgets.1. So, where is the wxRuby mail list?
The wxRuby mailing list is here:
http://rubyforge.org/mail/?group_id=35
And the wxRuby home page is here:
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?
There is an HTML widget, don't know about the text editor.
Your best bet would be to ask these questions on the wxRuby ML, I'm not closely involved any more.
Curt
On Monday 08 August 2005 07:14 am, Curt Hibbs wrote:
.NET/System.Windows.Forms {Open,Save}FileDialog does.
Perhaps it's based on assembly signature or assembly name
and version.
On Monday 08 August 2005 20:04, Lothar Scholz wrote:
> 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.
--
Stefan
Korundum is the KDE specific binding. QtRuby is about Qt only.
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 <d454d@web.de> wrote:
* Gerardo Santana Gómez Garrido <gerardo.santana@gmail.com> [050808 19:15]:
> Have you considered QtRuby?
Does it work with the windows version of Qt4 as well? I was wondering if
this is just a KDE-only project or a really multiplatform qt wrapper.Steph.
--
Gerardo Santana Gómez Garrido
"Entre los individuos, como entre las naciones, el respeto al derecho
ajeno es la paz" -Don Benito Juárez
Lothar Scholz:
> because of the file dialog used, which doesn't remember the last location
> 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.
Windows (2000/XP) remembers the directory on behalf of the application when using the standard file open and save dialogs. This is stored in the registry keyed on the application name in
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU
Neil
Hello Richard,
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.
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.
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.
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.
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.
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.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Citát Lothar Scholz <mailinglists@scriptolutions.com>:
Hello david,
> The "ugly" says is all. FOX looks very foreign to me on Windows, doesn't
seem to
> even try to look like the XP widgets do. I stopped playing with
FreeRIDE
> because of the file dialog used, which doesn't remember the last
location
> 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.
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 toolkit,
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 widget
set.
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.
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.
I still have personal issues about reinventing the wheel. With synthethised
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 GUI
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 lurking
behind the corner.
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.
I'm a technical person and I'm ticked off to no end by applications having 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 and
every app has its own mechanism of skinning, and applies system defaults rather
randomly. Gray88 text on a white background everywhere, because authors of
skins, IDE editor settings, and stylesheets -always- presume I use a white or
light background, but don't bother to change the text colour settings along. 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 important from
any end users.