The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Cross-platform GUI dilemma

To my horror, I just learned that Borland C++ Builder only supports GUI projects in Windows.  this leaves me with a hell of a dilemma that I could use some serious advice on.

  The problem: As I've said in other threads, I have a low-level back-end thing that is written in C. I have a command-line shell for it that I wrote as a debugging tool. It's working pretty well and I would like to wrap it in a GUI so I can demo it no nontechnical people. I would like to support Windows, Linux, and Mac if possible. Here are the choices I've found, and all present dilemmas:

  (1) Troll Tech QT--nice but $3800 for a single-developer license for 3 platforms, right now honestly out of reach as I'm developing on a shoestring.

  (2) WxWidgets--nice cross-platform library but no tools exist except for a 3rd-party graphical windows builder of unknown quality, which is not integrated with any IDE. Deployment would be easy though because everything would be  in C/C++ & can be compiled into a monolithic chunk.

  (3) Java--a bit of a mess since the back-end stuff needs JNI, and deployment will also be a mess since Sun has a nasty tendency to change the Java runtime in non-backward-compatible ways. The app would no longer be monolithic. On the up-side, JBuilder is a good IDE. I hate Java, but I *am* familiar with it.

  (4) WxPython--If I'm going to get into deployment nightmares and native interfaces, maybe it's time to take the Python plunge. It will cost a lot of pain up front but the experience gained with the powerful C/Python combination may be worth the hassle in the long run.

  (5) Forget about the cross-platform functionality for now and just bang out a demo for Windows only, using Borland C++ Builder. This would be fast because that's what I know, but will end up being throw-away code in the long run.

  I'd be grateful for any & all input, including others' experiences with any of the solutions outlined above.
John Foxx
Monday, April 11, 2005
Might consider zoolib, too.
Aaron F Stanton Send private email
Monday, April 11, 2005
add a web-based UI?

For suitable values of simplicity...
Monday, April 11, 2005
Generate a front-end GUI using REALBasic.  The 'Pro' version can cross-compile from Windows to run on Mac or Linux, or the 'Pro' version for Mac can cross compile to run on Windows or Linux.

It uses the native widget set on Windows and Mac, and uses the GTK widget set on Linux.

And son of a gun -- now through Friday they STILL have their special on the 'Standard' version for VB6 programmers -- $99 version is FREE until Friday.  -- link to free offer. -- link to full-price versions.  Pro is $399.

Ignore the 'subscription' service -- that's for companies that want predictable yearly upgrade costs.  They don't upgrade on a yearly or regular basis.
Monday, April 11, 2005
If you're at demo stage, cross-platform is probably not yet a requirement (most paying customers will probably have Windows anyway) : my idea is that you should use what you know best now (unless time-to-market is not an issue).
As a side-note, have you checked that your low-level tool will be easily portable across platforms ?
Monday, April 11, 2005
Gtk? You can use Glade to create the GUI fast.
Maciej Kolodziej Send private email
Monday, April 11, 2005
Pakter sez: If you're at demo stage, cross-platform is probably not yet a requirement

You are correct, sir. I just don't like to write more throw-away code than necessary :-)

Pakter also sez: As a side-note, have you checked that your low-level tool will be easily portable across platforms?

Yup. Porting to embedded platforms is the eventual goal, so I've been careful to avoid using any OS services, dynamic memory allocation, or machine-specific assumptions. Why I'm doing what I'm doing would take a really long time to explain & wouldn't help the forum much, but trust me.

BTW, I may have spoken too soon about C++ Builder. These features are indeed missing from the free download version, but I think they are present in the commercial version. C++ B. X is also based on WxWidgets, but doesn't cross-compile for Mac...I wonder why?

Oh yeah--have downloaded the RealBasic demo & it's cool. That may just be the ticket, we'll see.
John Foxx
Monday, April 11, 2005
Why do you think that Qt is too expensive? I've got a lot of experience with it (and without it, trying to emulate it) and I can say that it's worth every penny. If you think you probably won't make 3800$ in profit then maybe you should rethink your business plan.
Simon Perreault Send private email
Monday, April 11, 2005
I am using wxPython right now. While I can't say how it will work out in the long term, right now I am very glad I used it instead of C++. Python is an excellent language; it's both easy and powerful, and the extensive standard library makes it a snap to write code. I can't speak for wxPython on non-Windows platforms, but on Windows, it's indistinguishable from a native app to my eyes (with some minimal tweaking). It integrates with Python quite well.

I tried out one or two visual GUI builders with wxPython, but they were poor, so I just wrote it by hand. It wasn't difficult once I got a feel for sizers, and the amount of repeated code is fairly low.

Deployment needn't be painful; py2exe allows you to make a stand-alone distributable if that's what's desired. There's also an example floating around using py2exe with InnoSetup to produce an executable installer for Windows; I tried it and it worked fine. With compression, the installer came out to about 5mb.

In my case, I need to get at the Windows API. This isn't a problem. I use GetHandle to get the HWND for the window, then use functions from the win32 extensions for Python with it. I also have some API code that can't be written in Python, so I wrote it in C++ and used Pyrex to wrap it in an extension class (I needed to tweak Pyrex a little to have it compile as C++).

As for performance, Python is indeed slow, but as with the other issues, this was an easily solvable problem. I have a performance-critical section, so I experimented with a few different approaches: Psyco, Pyrex, and C wrapped in Pyrex. Pyrex and C tied for fastest, so I chose Pyrex to eliminate the need for a wrapper.

Given that you expressed a dislike of dynamic typing your Lisp thread, you might not become a Python fan. That said, I don't recall making a non-trival type error even once since starting to use dynamically-typed languages. That suggests to me that using a statically-typed language (even one that avoids annoying C-style static typing) buys only a minimal amount of safety. Since you're only making a demo, I doubt that safety is worth the significant mental overhead.
Monday, April 11, 2005
I designed my application in wxWidgets C++.  I currently only use it in Windows.

One option is to use wx in a single platform, then when it is time to port, the process will be easy.

Also note that to make a really nice GUI experience, you will need to get into the API code.  Most of it is there, but I often find I have to tweak it to get rid of the rough edges.
Randall Fox Send private email
Monday, April 11, 2005
You could look into Runtime Revolution ( ). Connect your code as an external to a full-featured fall-off-a-log easy-to-make interface, and build identical apps for Mac, Unix, and Windows.

It may not have the cojones of C or Python or even Java but it can do the job. Really.
tereza Snyder Send private email
Tuesday, April 12, 2005
"I have a low-level back-end thing that is written in C. I have a command-line shell for it that I wrote as a debugging tool. It's working pretty well and I would like to wrap it in a GUI so I can demo it no nontechnical people"

If you're happy just with Windows, try (disclaimer - I wrote it). You can build a GUI that works on any Windows version then use Exec() to run your C EXEs. The Exec command allows modal / nonmodal execution, and run-wait or run-continue options. It should only take a few minutes to build a basic GUI that execs some programs.
Bill Rayer Send private email
Tuesday, April 12, 2005
Ori Berger Send private email
Tuesday, April 12, 2005
Are YOU doing the demos or are you wanting to let users download the demos?

If YOU are doing the demos, it might be cheaper to just have a laptop running Windows. You just lug the laptop with you.
Mr. Analogy (uISV owner} Send private email
Tuesday, April 12, 2005
I'll second the bizarre comment that actually making dialogs in code with wxwidgets isn't too hard, nor time-consuming. That's not true at first (your will to live WILL be tested!), but once you've got to grips with it it does have certain advantages.

It really comes into its for generating dialogs based on lists and so on that you already have. With a minimal amount of work, you can have your program's GUI expand as you add extra options and extra "stuff", without having to muck about with the dialog designer. If many of your dialogs have to follow things that are specified in the code, this is a real boon, because now they can do this entirely automatically. (I've been doing the equivalent in Win32 a bit lately, using the VC dialog designer, and whilst laying out the initial dialogs was easier keeping them in sync with the code is a real pain -- and all I need is checkboxes corresponding to a struct of bools...)

Resizable dialogs are also very easy. Once you've laid it out at one size, it's usually resizable straight away, as you've had to specify the right information just to get it working in the first place. Another big plus point in my book.

I must admit, though, I've never done this for a very large GUI-heaving program, so your mileage may vary. And the project I used it for (medium sized, a few dialogs) was a part-time one, so the initial time spent staring at all the controls stuffed into the top left corner (etc., etc. :) didn't bother me. But it has worked rather well, all told. I'm not convinced there's any great time advantage overall, compared to doing the same in any of the "easier" tools I've used, but adding new GUI features is much easier to do quickly and correctly, because the dialogs build themselves kind of declaratively based on the code.
Tuesday, April 12, 2005
I should add, to sum up, that this is very much one of those "it takes all sorts" kind of things -- I'm hesitant to recommend wxwidgets unreservedly due to its lack of a dialog designer, but it's my personal experience that this is less of an issue than it might appear. The "build dialogs in code" approach has a number of definite advantages, but it's not clear these are always enough to outweigh the obvious disadvantages.
Tuesday, April 12, 2005
BTW, with so many new people struggling with wxWidgets, how come no book or good online documentation is available? Is Julian still doing this part-time? Considering ehe number of apps using this as their widget set, I'd think some foundation hired him full time.
Tuesday, April 12, 2005
Bite the bullet on QT!
Sassy Send private email
Tuesday, April 12, 2005
To all--thanks for turning me on to all this great stuff I would never have heard of! To Simon: it's not that I don't think there will be $3800 in profits, it's that it may take a long time before we see any profits, and the more $4000 SW packages you buy, the sooner your expenses catch up to you.

  I checked out the REALbasic demo--it crosscompiles from one platform & produces a monolithic output, which is an advantage. It seems so--I dunno--backward to use Visual Basic, but this is a good tool.

  I also installed WxPython and Boa Constructor on Windows and Linux. The Windows install is trivial, the Linux install is a nightmare. Python is of course a far more advanced language than VB, and Boa has a graphic dialog editor. On the downside, porting it to other OSes probably won't be trivial in practice. The number of dependencies is staggering, and you will have to get a machine & working development environment for each platform you intend to support just to make sure you can really install the whole mess on users' computers. There are multiple versions of Python, WxPython, WxWidgets, and in Linux, the GTK libraries + other system libs, and these must all be in synch. (I still don't have Boa working in Linux).

  REALbasic probably has a better bang/buck ratio just because it's a cohesive package, but I'm going to continue playing with both & see how it goes.

  To be honest, I'm looking for an excuse to go with Python just because it's so much cooler, but it's hard to justify if the goal is to get from point A to point B.

  These are my results, your mileage may vary.
John Foxx
Tuesday, April 12, 2005
geez, this all sounds so complex.

wx this and Gtk that and , holy cow

You guys discourage development - I must say, it makes me glad to have my Visual Studio - and now I know why I stick to Windows development  lol
Tuesday, April 12, 2005
I use wxWidgets all the time and I love it.

Can't understand everyones issues - I dived right in and was productive in just a matter of minutes.
i like i
Wednesday, April 13, 2005
To I Don't Know: I agree with you...until Microsoft yanks the rug out from under you, which they will do periodically. They've been ruining my life in this manner since 1995.

  To i: I have decided to forge ahead with wxPython & got a "hello world" app without too much trouble. The first speed bump I hit was attempting to install Python 2.4 and wxPython 2.5 so I could run Boa Constructor... Don't bother, Wingware Pro only costs $175 and it's MUCH better (plus, the 2.5.x branch of wx is an unstable development version).  (Note: the Boa web site says it will work with wx 2.4, but when you actually run it, it pops a msg box saying it needs 2.5).

  Another BIG mistake I made was assuming I could delete Python 2.2 after installing 2.4 (this is Linux). *BIG* mistake. Don't ever delete *ANYTHING* in the system directories without using RPM. Turns out there were other packages all over the place depending on the 3rd-party add-ins to Python 2.2  I spent the better part of a day restoring what I'd deleted from the packages on the Fedora install disks.

  Here's some useful RPM esoterica that I learned, though:

rpm -Va to generate a missing-files report (takes a while)
rpm -qf to find out what package a file came from
rpm -ivh --replacepkgs package.rpm to force re-installation of a package that RPM thinks is already installed because you manually deleted something

rpm --rebuilddb rebuilds the RPM database (dunno what it does but it gives you that warm fuzzy feeling inside)

  Another note: py2exe (for Windows) wraps everything your app needs into a single .exe (python interpreter, wx libraries, and all) greatly easing the pain of deployment. I don't know whether there's an analog in Linux but I'm not concerned about that right now.
John Foxx
Wednesday, April 13, 2005
The last time I dealt with Qt you could get a fully functional version of the toolkit for free, provided you were not developing for profit. So maybe you could get the free version of Qt, develop in that up to the point where you want to release something and then buy the professional edition. If that doesn't work, buy Qt for one platform now, and add other platform versions when you need them
David Clayworth
Wednesday, April 20, 2005

I can't speak for the other languages, but I can tell you that Java as a standalone tool doesn't need to be as monolithic an issue as you first described. For example, our company, uses Java as the language for our desktop application. What we do is use an installer that installs a local runtime engine in your application directory, so you have full control of the runtime version. This will avoid your issue with Java runtime engines.

Also, most people think that Java apps run slow and look ugly, but this is not necessarily true. If you were to look at our application from the screen only, you could not tell whether or not it was written in Java, VB, .Net, etc. Most often the issue is with poor UI design and implementation, mostly from inexperience gui development. Remember most Java developers work and are familiar with server environments. Although this is not at all a bad thing, what it means is that server developments skills do not necessarily translate to gui skills, or vice versa. Therefore, if you take the time to understand the gui concepts in Java, you can build some nice looking applications with cross platform capabilities that will be very responsive.

Although our current application, LandlordMax, is only supported on Windows, it could be ported to other platforms. The reason we haven't yet is mostly because we have not had the time to properly test it on other platforms (linux, mac os, etc.). Although the language promotes write once run anywhere, what we found is that when we ran it in other platforms, for example linux, there were small little gui differences. We didn't see anything major, but lots of little tweaks we would want to resolve before launching and supporting a commercial version. As a quick example, our splash screen on linux flickers, not just the progress bar, but the whole splash screen (even though its not big, we believe that it gives a really bad first impression, which is bad). This is most likely a small coding issue, but combined as a whole with all the other small fixes and based on our expected ROI, this has forced us to hold off releasing on other platforms for the time being. However, I imagine that if you intend on supporting multiple platforms, this would probably be your easiest path.

Stephane Send private email
Tuesday, April 26, 2005
You can use Tcl/Tk, then wrap it into a Starkit or with Freewrap for a standalone executable. Tcl/Tk is *great* for wrapping a command-line app in a GUI.

Info is available at
EKB Send private email
Wednesday, April 27, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz