FXRuby or wxRuby?
baalbek
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
Curt Hibbs
> 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
da...@vallner.net
> 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
gabriele renzi
> 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.
olof sivertsson
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
Randy Kramer
> 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?
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
Curt Hibbs
> 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.
>
>
> 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
Randy Kramer
---<good stuff snipped>---
Curt,
Thanks!
Randy Kramer
Gerardo Santana Gómez Garrido
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.
--
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
Lothar Scholz
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.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Lothar Scholz
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.
Stefan Lang
> 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.
NET/System.Windows.Forms {Open,Save}FileDialog does.
Perhaps it's based on assembly signature or assembly name
and version.
--
Stefan
Stephan Mueller
> 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
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'
Curt Hibbs
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
Stephan Mueller
* Gerardo Santana Gómez Garrido <gerardo...@gmail.com> [050808 21:42]:
> [details about QtRuby]
Great! :)
Cheers,
Steph.
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 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
baalbek
> 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
Neil Hodgson
> 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.
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
Curt Hibbs
But FreeRIDE uses FXRuby/Fox, and Fox does not use the Windows standard
dialog. Therefore FreeRIDE would have to do this itself.
Curt
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
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.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Lothar Scholz
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.
>> 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.
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.
da...@vallner.net
> Hello david,
>
> 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.
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.
Lothar Scholz
>> 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> 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.
>> 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.
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,
>
> >> 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> 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.
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
Lothar Scholz
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.
Dominik Schlütter
Gerardo Santana Gómez Garrido <gerardo...@gmail.com> wrote:
> 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 OSNews:
http://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