Slashdot Mirror
Cross-Platform GUI Toolkits (Again)?
Futurepower(R) queries: "It has been 2 1/2 years since the previous Ask
Slashdot about GUI Toolkits. There were many helpful comments then, such
as this
one. Since then, Slashdot has discussed wxWindows vs. MFC and considered the book, Creating Applications with Mozilla. The best comparison table is
apparently still the GUI Toolkit,
Framework Page. Which is the best cross-platform GUI toolkit that provides
native look and feel? Which is the best overall? What IDEs and other tools do
you use? What are the problems?" Slashdot also had a match-up between GTK+ and Qt, but some of you might have missed that one. How have recent changes in this ballpark changed your feelings on the issue?
I like wxWindows and especially it's a child project wxPython. wxPython is my favorite way to develop GUI apps because it is easy, flexible, cross-platform, and looks great. My only major wish for it is a Java port so Python/wxPython programs could be made portable to Jython. :)
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I like wxWindows but it's not nearly as well and copiously documented as Qt. Also, being able to build code in Linux, FreeBSD, OSX and Windows (at work) is very, very, very cool.
Qt all the way!
The heat from below can burn your eyes out
At my new employment I had a project that needed to be cross platform. I was itching to use Kylix, however it wasn't due to be finished for another 8 months. Looking into the details I saw that they built the corss platform support on QT.
After checking out the QT tutorials I was immediatly hooked. QT is intuitive; I can't think of many other APIs I would grace with this description. In addition to being well thought out it has a superb implementation. I've been using it happily for 2 years.
The only thing I miss is the strong third party component community that Delphi/Kylix has. I'm a huge fan of "buy don't build". You can really put quality touches on your app by finding the right component someone else has already made.
-R
available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).
You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!
-- You see what happens when you have fun with a stranger in the Alps?
What about Mozilla's XML based GUI - XUL?
Eclipse does have a few glitches in the Linux version.
For those that don't know, Eclipse is based on a unique IBM GUI toolkit called SWT. It has a Java API, but the underlying code is native. The supposed advantage of this is that it can be used by any Java programmer as an alternative to Swing, but it's faster. The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Since more GUI apps are run on Windows, there's more pressure to make the Windows code work right, and the Linux code is always a little behind.
I don't think there's any advantage to SWT these days, with Swing programming coming along so well. For anyone who doubts this, have a look at IntelliJ Idea, a really nice Java IDE that's Swing-based, and super fast. Frankly, I think Eclipse and SWT was a move to establish an IBM-centric Java community, with lots of vendor lock-in. Hijacking Java from Sun, if you will.
Eclipse *is* a really nice application, but I don't think IBM's motives in creating it were at all community-minded. And I don't have high regard, or high hopes, for SWT.
I'm a big fan of wxWindows - really nice look AND API, but I've had trouble getting any of the dialog editors to work (I'm under OS X), which has been something of an annoyance, since, as any GUI programmer can probably tell you, implementing GUIs entirely in code is a huge pain in the ass, and is harder to change later on than if you use a resource file...
A Minesweeper clone that doesn't suck
Swing works on a single platform: Java. And not all Java, either.
My impression is that wxwindows is is a bit different than the other tool kits mentioned because it tries to provide a wrapper to the underlining gui system rather than creating its own. That may limit its functionality and portablility a little, but it means that you really will get native look and feel across platforms. I would imagine that it also cuts down on memory and speed overhead.
For example, the way that Kuro5hin has dynamic threads. They keep a stub of each comment id, and then run javascript to dynamically load the comment's contents when requested.
I'm not sure whether it would have worked for you... real time graphical information -- so you needed to reload an image? How often?
It's not suitable when you want to change an image ten times a second, but if your application would suit 2 or 3 second updates then there's a lot you can do with Jabbascript.
Ahh Jabbascript.. the world doesn't know what you can do.
pyGTK with Glade is the EASIEST GUI toolkit. It may not be the "best" but I've built a commercial, cross platform application using it (here is a screenshot) and I am a complete retard at GUIs. It took a total of 2 weeks - from complete scratch. Porting it to Windows for my customers is just a matter of installing a few simple .exe's - they are used to that anyways. Because the GUI is actually a .glade XML file, I don't have to write any code at all every time I change it. It just makes more sense than having to worry about integrating your entire IDE into a GUI builder!
The C++ wrappers for GTK have come a long way. They make deriving new components a breeze -- just slap together something derived from the closest widget to what you need, add some hooks so you can put stuff into it and get stuff out and drop it into your favorite layout tool. The signal system is pretty slick too, and doesn't use a preprocessor. The signal system alone is worth looking at -- I could see using it in non-GUI projects.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I have to strongly agree, it's simple, it's reasonably clean, it's popular, it's been around long enough to well supported and accepted. And it runs on just about anything out there. And it's the default widget set for most of the most popular scripting languages: perl, python, ruby, and of course, tcl. Yet somehow it stays apolitical.
Of course, I may be accused of bias, since I'm the new Tcl/Tk maintainer for the Debian project. But in all honesty, I don't even care that much for tcl. It's ok, but nothing to write home about. It's tk I like, and tk that made me willing to adopt these packages.
For a very different (but interesting!) approach to x-platform dev, a company called Laszlo Systems has a "presenation server" that delivers full-fledged apps with real, desktop-style UIs into just about any browser. They have an XML- based application description language, combined with a JavaScript library -- all of this gets compiled by the server into SWF files (Macromedia Flash, version 5).
http://www.laszlosystems.com/
bottom line is it sounds like you get the benefits of things like SVG and XUL (standards-based, textual authoring) combined with the cross-browser, cross-OS/device compatibility and visual dynamism of Flash. No Flash authoring needed... XML only. Not a bad approach... and both the client (browser) as well as their server will run on Linux, Windows, Mac... etc.
Has anyone worked with this?
the issue with SWT seems to be openGL support. since the only current openGL support with Java seems to be thought Java3D which is tied in with Swing and Swing and SWT dont get along. this is all from readin posting on the SWT-dev mailing list. so if anyone has any idea on SWT+openGL, let me know!
Keet it real homies!
We don't work onsite, so this is not an issue, but there could be something applicable in my experience to your experience.
When we get a new project, it invariably requires some learning curve just to get our engineers up to speed. However, there is always some aspect of the project (like IDEs in your case) that someone has some proficiency in. That person is put on the project in order to provide help to other team members who may be complete newbies to the types of technologies necessary on the project.
This leads to less frustration on the part of inexperienced engineers as well as a boost on the learning curve. It also spreads knowledge around so that next time a project comes along with the same aspect as before the engineer who used to know nothing can take charge and teach others.
Tcl/Tk is great. Lots of people certainly get great mileage out of it doing "quick and dirty", but if you design your code right, it can be quite clean as well. Tcl is flexible enough, and has enough of its C API exposed that you can load OO as an extension - [incr Tcl] is a popular one, if you want to do OO. Of course, it's possible to do "design patterns" kinds of things even without that, you just have to be clever about it.
http://www.welton.it/davidw/
And these are just my biggest objectsions. The Tk widget set is not bad. It is quite ugly and limited, but good enough for a small GUI app. The underlying language though is absolute crap.
The only good thing about Tcl is that it provides a (relatively) easy way of interfacing with C code: you can expose C functions as Tcl commands (e.g. you could map Tcl command foobar to C function MyFooBar()). This is, in fact, what Tool Control Language was designed for: exposing C functions to a high-level script to facilitate easy automated testing. However, trying to write a real application in Tcl is an excercise in futility. There are much better alternatives available. But, if all you have is a hammer, everyting looks like a nail -- that is why Tcl is the "past and future king".
___
If you think big enough, you'll never have to do it.
I know people won't be into this, considering the crowd here, but all the same:
I use Squeak Smalltalk as my cross-platform toolkit of choice. Squeak includes a cross-platform GUI toolkit, as well as a cross-platform language, IDE, runtime and configurable world of libraries. Once you get out of the rut of Tk, GTK+, etc and get used to the programming style, it makes so much sense, it's almost scary. I was doing Python+(Tkinter or wxPython) before Squeak.
What most people here will gripe about is that Squeak's GUI system, Morphic can't be called from C, C++ or Perl at this point. It's possible, but so far our users have been happy enough with Smalltalk not to move away from it. Squeak also has it's own UI look and feel- it's not Windows, Mac OS, or GTK+ in appearance. I may be in the minority, but I prefer a clean look to poorly emulated widgets. By default, the look and colors are a bit kidsy, but like everything in a Smalltalk system (ala emacs, but easier!), it's very configurable.
Squeak supports a lot more platforms that most of the combos mentioned here. Right now, Squeak supports: Mac OS X, Mac OS Classic (System 7 - OS 9; m68k and PPC), Windows >= 95, DOS, WinCE (StrongARM, XScale, MIPS, SH4), X11 on any modern Unix-like, Linux framebuffer (Linux PDAs and kiosks), SDL (lending support to PicoGUI and others), OS/2, and the Acorn RiscOS. It also runs on bare hardware on stock x86 machines, complete with drivers written in Smalltalk. There might be more, but that's should be most of them.
No, I would reccoment it to people who are wanting to create a business app for a homogonized work environment, but it has many uses.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I wrote a white paper about this on new years day. The mingw project has made native Win32 binary development using Java and the SWT API possible. In my opinion this is the only true write once, compile anywhere solution.
Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.
Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native... and it secures you that 'out' in case you want to port later.
It's worth noting that all of the "upsides" you mention here also apply to SWT (for Java), PyQT (for Python), and wxPython (for Python).
It's not necessary to switch from a higher level language to C++ just to use a fast, cross-platform GUI toolkit that renders via native widgets.
Erlang.org: wow
Yeah and winamp pisses me off for not using the native widgets all the time. When I upgraded to XP minimized winamp windows would leave a little block under the start bar, this was fine as long as you didn't have autohide on, if you did it was kind of rediculous looking and it would not re-maximize from this state. Another problem is that a vbscript I have bound to one of the keys on my internet keyboard allows me to minimize and maximize any windows, except it doesn't work with winamp because the standard calls don't work! There are sucessfull non-native products out there including for many years winzip, however in general I would say that sticking to the native tools is a definite plus.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
http://doc.trolltech.com/3.1/qstyle.html
I'd say 1 (and perhaps 2). Remeber that it is possible to configure Qt to a windows look in a X Windows environment, so I'd go for 1. If you really need to know: read the source or ask trolltech (they are usually friendly and quick to reply).
There are about 130 relatively plausible configurations of screen size and fonts under Windows. There are very few toolkits that will work well with all of those, and that's on just one platform. I know of someone who tested Delphi and VB against all the combinations and found that they each worked well with only about 90%. Cross-platform that will handle all the variations on multiple machines and look good and make it possiblt to put a reasonable pantload of data on the screen regardless -- likely impossible.
FLTK looks pretty awful though. We have a bunch of custom apps here at work coded in C++/FLTK and they don't look like they fit in anywhere...they look as alien on my KDE desktop as they do on a Windows 2000 box. They've got some weirdo widgets in there too...there's that one with the little rolling wheel that you use to increase or decrease a value...what's the deal with that?
Actually, none of these things may actually be FLTK's fault...the guys who developed the apps haven't got an aesthetic bone in their bodies so maybe the shitty look of the apps is more due to them than the toolkit.
I don't know about Aqua, but under Windows Qt does not use the native widgets. It uses the GDI instead, in the same way that it uses Xlib under X11. Using these basic drawing tools, it creates its own look. The QButton class draws itself, and is the same identical file under all platforms. So it can't be using native widgets.
It gets them right simply by drawing them right. 'Nuff said. It's really not that hard when you look at it.
I've got a couple of applications written with Qt, and they look like native Win32/MFC apps under Windows. You can't tell the difference, except that they use slightly fewer CPU resources. Throw a Liquid, Keramik or Qinx theme at them under NIX, and they don't look like Windows anymore.
A Government Is a Body of People, Usually Notably Ungoverned
I would just like to point out my experience from using QT for the past two days. It was very nice and straightforward to learn. I am trying to port my old motif-based application to QT and so far I have made some real progress after a day of reading the documentation and tutorials. In the field of widget interaction, QT's signal and slots model really rocks compared to callbacks (GTK still has callbacks). No more trying to double check your callback's parameters to see if it matched the calling widget and get screwed in the process.
Creating custom widgets too is a pure pleasure - subclassing really is a gift!
...Just some of the nice things you get with QT not to mention you get a free excellent GUI desinger plus excellent documentation.
ABSOLUTELY RIGHT. (I'd mod instead of post, but I just used up my points last week!) The core of .NET plus the C# language being accepted as ECMA standards will be rendered useless if MS later uses patents force licensing fees or restrictions on developers. ASAIK nothing in the core or the standards themselves is patented, but things within other basic libraries are. Since none of the "higher" libraries are standardized, they can change at any moment. The forms for example can be implemented by Mono, but since it's not a standard MS can change their APIs at any moment and still claim "open standards compliance". Once everyone's dependant on the common non-standardized APIs implemented by MS and others, if they pull tricks like changing the APIs or enforcing patent licenses we'll again have segmentation and implementation reliance. MS will play that card if they see too much of a threat.
While the technology seems promising, we must be weary due to patents and corporate strategies. It's better to stick to non-corporate-backed open technologies in general. I personally like wxWindows for a native look-and-feel cross-platform object library. I'm fascinated, though, by the Mozilla platform as a way to serve GUIs from servers and to have apps centered around a rendering engine.
Developers: We can use your help.