HN Explorer

Ask HN: An acceptable cross-platform GUI toolkit?

28 points by moder ↗ HN
It's interesting but disappointing that there's no standout "winner" among desktop GUI toolkits. Among other things, devs want to write software that runs on their favorite GNU/Linux distribution, but that also runs nicely and is easily installed on MS Windows and Mac OS X. Here are the arguments I hear against some current popular toolkits:

* GTK+ -- Has lots of moving parts. Difficult to build/install on MS Windows. Some say it's too closely tied to X11. Doesn't look enough like MS Windows on MS Windows. The LGPL licensing is very successful though, as demonstrated by the fairly large developer community and by its use in Gnome.

* Qt -- Either GPL your software or pay the licensing fees. Also some don't like having to deal with C++ if you're required to ever look under the hood. Nice that it comes in one big piece though.

* Tk -- Some have referred to Tk as a vistigial GUI appendage from a bygone era. Also it depends upon Tk. This one would be a hard sell to get everyone to agree on.

* wxWidgets -- Complaints are that it looks too much like the MS Windows API, and also that it's too big (being a wrapper around lower-level GUI toolkits).

It would seem that we (the free software community) should just bite the bullet, list out the basic requirements for a successful GUI toolkit, and go ahead and create it. I'd dare say that the requirements might look like this:

* Written in C. C is fast, portable, and everyone knows it. Corollary: keep it simple (like Tk) and packaged in one piece (like Qt). Having a half dozen different pieces all bolted together (like GTK+) in the name of modularity only makes it harder to create easily-distributable cross-platform apps. 2nd corollary: be careful not to tie it too closely to X11.

* Keep it simple so it's easy to port to Windows and Mac OS X (Cocoa). Corollary: simple and easy to build too.

* LGPL licensed. Most camps can probably (at least grudgingly) come to agreement on this, and it's worked pretty well for GTK+. Works for free software and for commercial apps, and tends to build nice communities.

* Can easily be made to look like MS Windows on MS Windows, and Aqua on Mac OS X. I really don't care if it's themable or not, but for wide adoption, it had at least better be able to easily make itself look like MS Windows and Aqua.

* Easy to make bindings for Python, Ruby, Perl, etc. I really do not want to write GUI apps in C, but I don't want it so fancy that you have to do acrobatics to mate, say, Python, to it.

* Simple and easy to use (like Tk).

Anyone working on or know of that cross-platform GUI toolkit? Because that's the one I want to use, and I bet it's the one a lot of devs would also want to use.

56 comments

[ 4.1 ms ] story [ 157 ms ] thread
qhoxie
Shoes has been more and more impressive lately. I'm not sure about ports or equivalents in Python and Perl, but people are doing great things with it in Ruby.

http://github.com/why/shoes

pm
I give two thumbs up for Shoes - I'm learning Ruby just so I can use it. However, running through the list of GUI kits the poster has assessed, Shoes differs significantly in that it incorporates web-style widgets on the desktop. It is much more suited to graphical applications and games than native desktop software.

Two thumbs down for wxWidgets. I used the wxPython port to prototype a not-too-complex desktop application, and found it tediously cumbersome (not to mention ugly). I would've been better off coding it natively in Obj-C and then porting it down the track.

gaius
The current Tk (8.5 and above) looks a lot better, using native widgets where possible, and Starkit makes deployment of Tcl/Tk applications a breeze.

Those who forget history are doomed to reimplement it.

davidw
I think that Tcl and Tk have a terrible "marketing operation" and haven't done a very good job of getting the word out about things like this - it's a huge improvement.

This has some screenshots, which are a bit out of date, but show that things have improved:

http://tktable.sourceforge.net/tile/

moder
Looking at the Tile screenshots for Unix, I don't see any that are antialiased (like the rest of my desktop), though "Revitalized" doesn't look bad at all.

(Incidentally, Tile doesn't seem very active. It's last News page update is from 2006.)

I think you're right about the "marketing" for Tk. The three things that keep people away from Tk (IMO) are probably:

1. the notion that they'll have to install or use Tcl,

2. the extra work of having to install various plug-ins/theme-engines/whatever to get a more modern-looking GUI, and

3. the revulsion at seeing non-antialiased fonts in GUI widgets.

If someone were to come along and bundle up Tcl/Tk with Tile and make the whole thing dead-easy to install and start using, I think that would be a major step forward for Tk. (Hm. Looks like it may have been proposed to do that back in 2005: http://www.tcl.tk/cgi-bin/tct/tip/248 . What ever happened to that?)

moder
Wait. http://www.tcl.tk/software/tcltk/8.5.tml . Most recent release was ... last month.

Looking at that list of Tk highlights, I'm getting the impression that various screenshots and wiki docs on the net are a tad out of date. It would seem that Tile has already been included. Tk 8.5 is looking quite good.

est
is there a minimal, single dll version of Tk for Windows?
makecheck
I am most curious about GNUstep (gnustep.org). GNUstep is similar to the Window Maker window manager on Linux, like Cocoa uses Aqua on Mac OS X. From what I've seen, GNUstep and Cocoa are very similar (both Objective-C, both using the original NS* classes, etc.) and the project aims to remain compatible with Cocoa where possible. I've used both Window Maker and Aqua, and I like both GUI styles.

Apparently GNUstep is usable on Windows, but I've never tried it.

At least in theory, the same Cocoa-like source could be used for a GUI app on all 3 major platforms.

Objective-C isn't as simple as C, but it's pretty simple, and fully compatible with C. It's also been bound to every major scripting language I can think of.

nailer
'GTK...Doesn't look enough like MS Windows on MS Windows.'

GTK apps for the most part look exactly like other Windows apps [1], and have for the last threeish years. Some, however, still use GTK style File dialog boxes, rather than native Windows ones.

Alas I haven't written any GTK for Windows, so I'm not sure what determines the File dialogs.

[1] Per poster below, I mean Microsoft apps included with Windows XP or Vista

coryrc
wxWidgets is "big" because it has features. Considering it meets all your other criteria (aka features), in addition to ones you'll only find out you need halfway through a project, I would look closer at it. Use wxGlade and wxPython if you want easy, C++ if you demand compiled. Use dabo (http://www.dabodev.com) if you are interfacing with databases.
koraybalci
I have been using wxWidgets for about 5 years now with C++. At first, it was really difficult to do everything in code, hard to change GUI when you need to, very time consuming. But still it was the best option, our project was cross platform. It was also difficult to understand how to build and link.

However, once you get the basics it's quite fast and also have threads, networking, file streaming etc, so you don't need a zillion of libraries to do every little thing. Oh, and it has a great OpenGL support (see my projects at http://www.ccsoft.com.tr for screenshots)

With the help of wxFormBuilder (a free design tool), now design and modfications are very much faster.

Besides, it's been there for about 15 years. There is a decent documentation, a book, a large community to answer your questions.

My only plan is to do a project on wxPython and polish my python knowledge and see which (C++ or Python) suits me better.

tweiler
I am thinking of using wxWidgets as well for my current project, although it doesn't require much of a GUI. All the guts of my app are in cross-platform C++ (by cross-platform I mean Linux, Mac, and Windows). I have connected a small GUI to it in Windows using WTL, but could easily change it to wxWdigets so I have one GUI to maintain and not three.
simpleenigma
I ran into a project where I needed a cross platform GUI kit (needed Windows and Mac) and settled on wxWidgets after talking to a few developers. It's been great to work with, although some of the other libraries that are compatible with it don't work as well as the core.

The really wonderful part of the experience is that even after not programming in C++ for about 10+ years I was able to get things working pretty quickly and I'm productive with it. A lot of that is due to the wxWidgets documentation and it's well developed structure.

My only real problem is when I have to switch back and forth between Erlang and C++. Those days suck :-)

scumola
I've used wxWidgets for 7+ years now and loved it even in the early days when the GUI tools sucked and the OpenGL support was poor, but now it's very well polished and my choice for GUI development under linux. If my app needs to be ported to Windows, I just re-compile and it's all nice if I use the wxWidgets version of the network libs, etc ...
est
the thing is, GUI is often connected with some messaging system like D-bus or WM_XXX, and that's platform-dependent. And also API for C/C++ is so different. Some may relate to performance demanding 2D even 3D features. The expansion list goes on and on.

The true thing we need is a minimal & native implementation of cross-platform GUI kits.

tptacek
You forgot Swing+Java/Jython/JRuby/Groovy/Clojure.
gaius
How I wish I could forget Swing.
bdittmer
There are some amazing apps built with swing...JetBrains IDEA and jEdit being two.
gaius
Interesting to note that two "amazing" apps written with Java are to help Java programmers ...
icey
Why is that interesting? Emacs uses a lisp; does that mean anything about emacs or lisp? (Edit: I'm being serious, I guess I don't see why Java being used to write Java editors is a big deal.)
bdittmer
To characterize both exclusively as tools to help java programmers shows that you haven't investigated either very much.
moder
> How I wish I could forget Swing.

Could you explain why? Last time I used Java (years ago), Swing was supposedly replacing AWT. Swing seemed very large (certainly, judging by the page-count of all the Swing books on bookstore shelves), and required a lot of subclassing to use.

When I tried it out, it was slow, to be sure, but it was also relatively easy to use. The layout managers worked well for my simple apps. I also liked the "Metal" theme, though others complained that Metal was unreservedly ugly.

gaius
Like everything else Java, it just does everything in the most elaborate, baroque and top-heavy way it can. There are so many, so much better ways to build GUIs out there. That's what I meant in my comment about Java editors; you need an enormous amount of tool support to do anything useful in Java because of all the boilerplate you need. Tk on the other hand is an absolute pleasure to use, and I spend almost no time on my GUIs now, I can concentrate on my real code.
tptacek
Nobody likes writing Java, but enough people respect the JVM that we have Groovy, Scala, and Clojure. Why couldn't the same thing be true of Swing-the-API vs. Swing-the-underlying-UI-toolkit?
swombat
and AIR.
wmf
Too bad AIR gives up on native look and feel.
termie
Please god don't make yet another GUI toolkit. Pick one and start coding.
akie
If coding in Java is an option, I would highly recommend SWT (http://www.eclipse.org/swt/). It's the toolkit that was used to build Eclipse, and it has a very 'native' look & feel (click the link for examples).

Plus, Java itself is cross-platform. Might be just what you're looking for.

safetytrick
Java GUI's always seem just a little bit unresponsive, an irritating latency with every small move you make. This is my biggest complaint with eclipse and every other java app I've ever used.
narag
That should be obvious: cross-platform GUI toolkits are so hard that there isn't any that you like. It takes a good design or lots of people working on it full-time. So either you pay for Qt or deal with other problems. That's one reason that web programming has become so popular.

There seems to be another factor if you add OS-X to the required platforms: the way of GUI programming for Macs is conceptually different from Windows or Linux.

schtog
Yeah it has always bothered me that GUIs are so annoyingly hard to make. I used to use Python a lot and Tk wasn't exactly a dream to work with even if something very basic was easy to get up and going.

However now I use Swing+miglayout+CLojure and making GUIs is supereasy.

[deleted]
(comment deleted)
GiantCrayon
Within the last few years, I've inherited a number of projects written using several of the above choices. While I don't want to appear _too_ negative, IME, apps produced using cross-platform GUI kits look bad on all operating systems.

I'd like to offer a "none of the above", which is to code the underlying "engine" of your app in C++, then connect that engine up to an OS-native GUI.

Just my $0.02.

potatolicious
Absolutely agreed. Stop contributing to the horrid usability of each platform by mixing and matching UI paradigms in a vain effort to create something that "fits" all platforms.

Cross-platform UI toolkits are the devil for any serious app - each OS, whether Linux, OS X, or Windows, have their own UI needs and guidelines that should be respected.

It's high time that engineers started paying attention to making their software accessible and usable, instead of focusing all their attention on core "features" that nobody can figure out, or want to.

statictype
If you're really picky about the look-and-feel on each platform, just bite the bullet and write 3 front-ends.

If you want something that looks reasonably good on major platforms, go with Qt or wx.

There are a couple more options you have:

XULRunner: I like this option because of the flexibility you get in creating UIs using markup and styles. You can get XULRunner built with Python support so you don't have to resort to C++. And you get a reasonably powerful rendering engine to boot.

Adobe Air: Never used this so I can't say anything for sure but from what I've heard, its similar to XULRunner but uses WebKit and a lot of Flash. It is, however, proprietary.

And,

If you're going to do a new UI toolkit, great. Just make sure you know a) why wxWidgets didn't accomplish this for you b) How you plan on addressing those shortcomings.

I believe wxWidgets was supposed to address the issue you raised about giving the native look and feel on each platform independently. It uses GTK on Linux and Win32 on Windows. No idea about how it works on OS X but I assumed it would use Cocoa\Aqua\whatever. Is that not the case?

vorador
Yes, it is, wxWidgets is just a wrapper over the native libs.
ynniv
Really? No one has mentioned the most popular, polished, cross platform application that's also a complete development environment: Firefox.
moder
The rule I try to follow is to keep things as simple as you can. So, the levels of complexity for writing an app might look like this:

Level 1: command line program. Usable for yourself and others who know their way around the shell. Great for simple tools.

Level 2: Desktop GUI. More complicated, but necessary when you have non-technical users.

Level 3: Webapp with simple browser interface. When you need a GUI and need to allow access to many users all at once (possibly access to the same instance of the app). Drawbacks are that it's slow (much slower than a regular desktop GUI app) and relatively clunky. Also, you need a webserver to run it on, and the setup time that goes along with that. Also keyboard commands probably won't work and so there will be a lot of mousing around for the user.

Level 4: Webapp with some kind of Ajaxy or Javascripty client side. So, you need this even higher level of complexity when you have non-technical users who demand a prettier interface but the app also needs to be usable by lots of people on the net at once. Drawbacks are the same as with a regular webapp but also include a much more complex design, more maintenance, and more testing with different browsers.

The rule is, you don't go up the complexity ladder if you don't have to.

mcandre
YelloSoft http://yellosoft.us/

I complain about the very same thing. There hasn't been a lot of development effort for building anything cross-platform. Out of fifty LISP implementations I looked at, only a few were cross-compatible. Hardly any computer games are multiplatform. I build my own software and release it on Mac, Linux, and Windows whenever possible. It's been really easy starting with a common code base (C/C++/Java/whatever) and creating the GUI using native tools: Xcode, Visual Studio, Glade. The GUIs end up looking good, are easy to make (if a little more trouble to sync between the OSs), and I don't have to spend hours scouring the 'Net for information on GUIs across several operating systems. It's becoming alarmingly common for Google to return no search results about some computing topics and programming errors. If I can't Google it, I can't fix it.

One of my biggest problems has been incomplete programming language support. Why should I learn wxWidgets if wxRuby is half-done? The documentation for RubyCocoa is even less substantial. I can't begin coding unless I understand a minimum of how the various GUI objects interact. I finally understand all those dumb underscores in RubyCocoa methods. Objective C is odd, but consistent.

Something like a Swing but C based would be nice, but it's a lot of trouble to wrap native methods (menubars, system trays, pop-ups, etc.) and not that rewarding. It's easier to extend a codebase using native tools for the interface.

Proof of concept: IOS7Crypt http://yellosoft.us/index.php?id=55

This app has a ridiculous amount of ports in assorted languages and toolkits. I've done it with Perl, Python, Java, Lua, Ruby, C, C++, and Objective C; on Tkinter, wxWidgets, Gtk, Qt, Glade, Cocoa, Windows forms, Swing, and HTML/Rails. Ultimately, I just use the command line interface and simple Mac/Windows/Linux GUIs. The screenshots are Cocoa, because it naturally looks the best!

newLISP version coming soon.

moder
Have you tried Tk8.5? It looks like there have been some pretty substantial improvements since 8.4.
vorador
I'm quite surprised to see that nobody has mentioned fltk (http://fltk.org). It is light, easy to use, and it uses a modified gpl license that allows linking against non-free code. And it has native look and feel too...
moder
IIRC, FLTK had their 2.0 version in the works a long time ago ... and it just kept being in the works. They just never left their 1.x series. Was their redesign doomed to never replace 1.x?
rmk
I've worked with Qt. It's great -- C++ and cumbersome build procedure notwithstanding. The API is also nice. Further, it works on embedded platforms too (think cellphones).

There is a PyQt, but the last time I tried it, it wasn't as mature as I wanted it to be. Maybe you can give that a try.

chrido
use xul + xpcom

(powers firefox, songbird, miro, thunderbird, activestate commodo ....)

jimrandomh
Where GUI toolkits are concerned, simplicity and C are mutually exclusive, because C just isn't a good language for them.
blableblable
I have also run into this problem. I have tried at different moments in time Gtk, it's C++ bindings, wxWidgets, Java+AWT/Swing, Qt.

I couldn't agree more that all of them have major drawbacks. We need a good, simple to use, well-designed, fast cross-platform C library.

Do you care to start doing it? Other than doing your own, I think the most sensible choice is wxWidgets, which, from my point of view, only has one big problem: the API (i.e. code doesn't look pretty, bad C++ (no exceptions), and it can take a while to compile).

moder
"Do you care to start doing it?"

Unfortunately, I don't think I have the chops, nor the time right now. (But, fortunately, it may not even be necessary... see below.)

"Other than doing your own, I think the most sensible choice is wxWidgets, which, from my point of view, only has one big problem: the API"

That's a biggie. :) In fact, I'd go so far to say that if the API in unpalatable, then you should keep looking. Otherwise you'll end up just procrastinating every time you've got to deal with GUI code.

Thanks to posts in this thread (thanks Baltar!) I'm taking a much closer look at the most recent release of Tk (8.5). Given recent developments, it doesn't seem to be as "vestigial" as I'd thought. And the fact that it's implemented in Tcl instead of C may actually be a hidden benefit. And really, app developers never even need to be aware of the Tcl'ing going on under the covers. :)