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.

Can wxWindows be beautiful on the Mac?

I am about to start a piece of Desktop software that has to run on the Mac and Windows.  I want it to look beautiful on both, but especially on the Mac (it's where I develop and frankly, I think Mac users care about this more).  I require native widgets.  Think iTunes or iPhoto for GUI feature-set (not functionality) -- it's a home-use productivity app.  I drool over what Delicious Library ( http://www.delicious-monster.com ) looks like -- that's what I'm going for when I say "beautiful".

I am considering (1) wxWindows (2) a portable C++ non-gui core and Cocoa for Mac and VB for Windows GUI's on top of that.

From a development standpoint, I want to just use wxWindows.  My hesitation is that all of the screenshots I have seen don't meet my standard (which I think is the general Mac standard).  Can wxWindows apps be beautiful?  Is wxWindows ready for prime-time on the Mac? 

If so, can you point me to a piece of commercial software made with wxWindows that I can look at that you think is an example?  How come every screenshot I see has a white resize thumb on the bottom right of the window?  If you use wxWindows for the Mac for commercial software, I'd love to hear experiences.
Lou Franco Send private email
Wednesday, August 24, 2005
 
 
I can't speak for the Mac but I can tell of my experience on Windows.

wxWidgets is just C++ written on top of the native C APIs for the platform.  If wxWidgets isn't getting you what you want, you can always directly call native C APIs or hack the wxWidgets source code.  If you want your app to be beautiful, you'll have to do both these things.

Is it worth it?  Probably.  I'd rather alter or program around wxWidgets than write my own cross-platform framework.  I'd also rather do C++ to C than do Java to JNI to C when I need to work around something.  All these other methods work, of course, but they'll depend heavily on you and your team.

Is the plain stuff coming out of wxWidgets ugly?  Yes.  Is it fixable?  Yes.  Is it difficult to fix?  Usually not but you'll need to be an expert Windows/Mac/GTK developer to do it.

The only other caveat is that wxWidgets has a few more bugs than other frameworks so allot 10-15% of your time to fixing things that, in other frameworks, probably work right out of the box.
Daniel Howard Send private email
Wednesday, August 24, 2005
 
 
I like trolltech.com's Qt widget set.  Note that 4.0.x is pretty new and a little rough around the edges.  It's available for a fee for commercial closed-source development, or under the GPL for GPL'ed development.
Chris in Edmonton Send private email
Wednesday, August 24, 2005
 
 
I assume you considered and rejected RealBasic, right?

It's a nice little language and compiles to display nearly the same on Win and Mac,'thouh I've only played with the win side of things.
Mr. Analogy {uISV} Send private email
Wednesday, August 24, 2005
 
 
I have asked quite several programming communities in the Mac space and they are uniform in their opinion that RealBasic is not suitable for cross-platform development, let alone Macintosh development. They weren't Cocoa/objective-c bigots. It's not that they don't use RealBasic--they do--many have been with RealBasic since the beginning. However they seem adament in their position that you should do it with Carbon/Cocoa + objective c.

Now the question is are you aiming for a business app to be used by 500 users or a Google Talk killer that answers to the whims and dislikes of 5 million users. If it's the former don't write RealBasic off, because it's your only real alternative to the following main stream choices:

1) C++ plus a platform-neutral system resource api for the business logic attached to native UI (Carbon/Cocoa on Mac, MFC/WTL on Windows, Qt/Gtk on Linux)

2) Java plus Swing or SWT (but perhaps with WinForms+C# thrown in if you really care too much for your Windows users to threaten them with Java+SWT)

3) C++ plus a platform-neutral system resource api + Qt

4) (This one is thrown in just for shits and giggles) Mono + GTK / Mono + Cocoa/Carbon mapping / WinForms for C#/VB.NET

(in order of preference; qualifying by flexibility, readiness and maturity; eligible players like Python and Perl have been left out if they don't generate obfuscated executables)

For crazy nutty people like me, we aim way too high. So Choice 1 and Choice 2 (with WinForm thrown in) are the only acceptable tactical routes to take. They also are the hardest to master (Choice 1 is impossible without hiring skills in those UI Library specialities), but you get the happiest customers and your programmers are relatively productive--at least in the case of Choice 2.
Li-fan Chen Send private email
Wednesday, August 24, 2005
 
 
You simply aren't going to get an iTunes or Delicious Library from wxWidgets. Period. wx doesn't even support OS X-style toolbars. And I doubt you can give your XRC the brushed metal look. Etc.

You must use Cocoa if you want a high-end Mac appearance. Nothing else comes close.

(I use wxPython, but I don't have the illusion that my apps are "real" Mac apps: they look ported and that's the best I can do given my particular constraints.)
Nate Silva Send private email
Wednesday, August 24, 2005
 
 
It's a home user app for non-technical users.  Nowhere near as many users as GoogleTalk or Delicious Library, but hopefully in the multi-1000's. 

I played with RealBasic and it wasn't good enough.  Anything too hard to deploy is rejected as well, and unfortunately, I can't afford Qt right now.

I could just make an MFC app and forget the Mac for now, but my main machine is a Mac and I really want to use it.  Also, this software has some established competitors on Windows, but none on Mac, so it might be a good way to get started.

I'm going to try to make a beautiful screen in wxWindows (that doesn't have to do anything) -- brushed metal, etc.  If not, I just go with Cocoa and probably VB.

Java is out -- Apple discontinued Cocoa support, so unless SWT can keep up with Mac UI, there is no good Java support of the future.  Also, deployment hassles.  I prefer an executable I can control.
Louis Franco Send private email
Wednesday, August 24, 2005
 
 
Apple discontinued Cocoa support? Geez! I can't keep up anymore. And they say that Microsoft is constantly changing their minds. Wasn't it less than six months ago that someone was posting out here about how Cocoa was going to give ISV's a huge advantage when developing for the Mac?

I admit that I don't follow the Mac in terms of development languages. Oh well. I'm going to have to try a little harder to stay in the loop.
matt
Wednesday, August 24, 2005
 
 
Apple has discontinued support for Cocoa applications *written in Java*, using the Java-to-ObjC language bridge. They continue to support (and are actively encouraging) Cocoa as the preferred application development environment for Mac OS.
Mark Bessey Send private email
Wednesday, August 24, 2005
 
 
Qt should get you what you want. It runs native on all platforms. Its GPL for all platforms, if you did like. The per developer license has come down. Just around $1800. And the Qt API will beat the pants off anything else.
IntentionallyLeftBlank
Wednesday, August 24, 2005
 
 
Or spend that $1800 hiring a Java nerd for a month to create this? --> http://sillysoft.net/lux/

Lux is one of the success stories. They were working with the Cocoa-Java bridge, found it unsatisfactory--and ended up going back to Swing.

I gave the windows version of Lux a try, not the prettiest thing, but as a game it isn't too bad. For the best effect you should probably do C# on the Windows side. Who knows? Maybe it's easier to fit two programming worlds (.Net 1.1/WinForms + Java 1.4/Swing) between the ears of in a single mortal than to fit 10 years of MFC between the ears of a programming god.
Li-fan Chen Send private email
Thursday, August 25, 2005
 
 
Here's another way to spend the USD$1800.

Buy Photoshop CS2. <- Pretty software == More sales

Buy serious hosting at a good place for a year. <-- Free hosting doesn't inspire confidence.

Buy an Mini. Buy some ram for it. <-- Test mac software.

Buy a copy of VMWare Workstation 5 <-- so you can test the crap out of your software.

Buy obfuscators for .Net and Java. <-- so some kid won't get the complete blue plan to how you spent the last three month.

Buy some books. <-- You need that right?

Buy a big box from a homeless guy to live in for the next two month. <-- Or basement. But cut yourself from the world!

You'll still have some cash left to pay off the cops so they'll leave you alone. <-- In case sh**. People generally don't like independent thinking self-starters.
Li-fan Chen Send private email
Thursday, August 25, 2005
 
 
I feel like hijacking the topic away from wxWidgets here, but here's a few notes on Java on Mac:

http://conferences.oreillynet.com/presentations/macosx03/adamson_java.pdf
http://www.tombridge.com/rta/2003/10/session_notes_w.html

Some harsh words for even considering Java *wink*:

http://www.pbs.org/cringely/pulpit/pulpit20011108.html

If you think doing Java is suicidal, then meet another high-jump expert:

http://www.macworld.com/news/2005/06/29/thinkfree/index.php
http://www.amazon.com/exec/obidos/ASIN/B0000690D0/002-6375127-9568006

So it's not just for Risk-clones.
Li-fan Chen Send private email
Thursday, August 25, 2005
 
 
Here's some work with Qt/C++ with Flash as the main GUI provider.

http://www.trolltech.com/success/photon.html
Li-fan Chen Send private email
Thursday, August 25, 2005
 
 
How about a portable Python core and then an Objective-C Mac GUI (using PyObjC) and on Windows a .NET GUI (using IronPython)?
Jon B Send private email
Thursday, August 25, 2005
 
 
Deployment ease is the main reason I'm staying away from python/.Net/Java -- I like a native executable.

Also, on Apple, the support for universal binaries means that I'm ready to go on the Intel Macs immediately -- if I start relying on other run-times, I have to wait until they release -- trying to minimize dependencies.

Right now, I depend on just wxWindows and sqlite -- I have the source for both and built them myself, so I'm not too worried -- I can statically link them both into my app.  I can make a simple app bundle on Mac that looks just like any other app.

I prefer the most native options available with access to the native calls if I need them.  That's why wxWindows is so appealing.  It has enough hooks that it makes me think I can get what I want.
Lou Franco Send private email
Thursday, August 25, 2005
 
 
wxWidgets and QT are your best choices.  Since QT is out due to price, wxWidgets is the primary alternative to rolling your own.

It is best to think of wxWidgets as a foundation, rather than a framework.  With a framework, you expect to work within its well-defined boundaries.  With a foundation, you just treat the code as a starting point where nothing is sacred.

Creating a very GUI window is a good test: you'll see how easy/hard it is to fix up wxWidgets core code and what kind of access you'll have to your OS specific APIs.  Give it a little time: the wxWidgets core code is simple but a little gunky.

Please e-mail me if you want to chat about wxWidgets.
Daniel Howard Send private email
Thursday, August 25, 2005
 
 
Alternative thought: separate out the application logic and the user interface, then create beautiful OS-specific interfaces to code that's easily portable.

Check out http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf for a how-to on writing testable dialog boxes. It takes the majority of the functionality and puts it in a reusable component, and leaves the GUI as a thin layer. It's intended for testing, but it's good for portability as well.

(Not that wxWidgets is bad or anything, just that even if you use that you ought to do this anyway, to save yourself some grief later on.)

Another thought with wxWidgets - you're free to enhance either the Windows or MacOS ports as desired and starting from scratch would take a lot longer. You can create a wxWidget style wrapper around any OS GUI component if it's not there already, so you're not limited to only using what's already in the wxWidgets library, but if you do that then you need to write that code for all OS's you plan to support.

Thursday, August 25, 2005
 
 
My first experiments are very fruitful.  You can definitely get brushed metal with wxWindows -- it's easier if you build the lib to target osx, but you don't even need to do that if you want it to work on both os9 and osx, you can do that too.

I've been reading the src code because the docs aren't adequate, but not horrible.

It's < 10 lines of real code to put up a window with a status bar and splitter with two scroll panes.  As long as I can get a select list to look like Finder or iPhoto, I'll be pretty happy.

Not sure why so many of the screenshots out there are so clunky -- the fonts are right by default -- if the Sizers implement the Human Interface guidelines for distance between controls, I'm going to be a pretty happy camper.

Thanks for the Humble Dialog ref -- I'd seen that before but forgot about it.

Only problem so far is that I can't give focus to window when running in the debugger -- also haven't figured out how to step into wx code yet.
Louis Franco Send private email
Thursday, August 25, 2005
 
 
If you use wxWidgets on the mac, just remember that it pays to use the latest version. It is in my opinion that wxWidgets is an ideal solution, but be aware that due to the use of native widgets whenever possible can yield... Interesting unexpected behaviour, so make sure that you test on each platform.

wxWidgets does look quite good on the mac, though :)
Arafangion
Tuesday, August 30, 2005
 
 
The key requirement for commercial development with toolkits like Wx is commercial support and a solid core team. Wx does not lack that, so I don't see a problem getting something fixed or improved. The main disadvantage is that it's hard to tell how much a fix or feature add would cost. I would advice you to look up some of the core teams and ask them whether they have service agreements you can use to determine the sort of cost that maybe associated with using such a toolkit. Bruce Peren's series of books on developing with Qt and WxWidgets will help you illuminate whether one is better than the other.

I don't think it's wise to let the cost of the Qt licensing prohibit your choice in picking Qt--especially if you can arrange to have them offer you a discount because you are a microISV--but this is up to Trolltech.

The bigger cost in the end is always developer productivity--the more productive your developers are, the better. If you think Java and C# will hinder deployment somehow, making your customers unhappy, then obviously you are looking for C++ solutions. The question is how difficult is it to deploy and upgrade internationalized installations of Wx and Qt with copy-protection and online payment of your choice in place. How hard is it to do database-backed forms development with sqlite embedded with either toolkit? How hard is it to do web services? How hard is it to incorporate commercial widgets from platform-dependent containers? How hard is it to install a Flash Projec? No one online has really answer these critical questions.
Li-fan Chen Send private email
Wednesday, August 31, 2005
 
 
s/Flash Projec/Flash Projector/
Li-fan Chen Send private email
Wednesday, August 31, 2005
 
 
Most reservations obout Qt's pricing would be silly if everyone is guaranteed to make thousands from their games/doodats/shiny objects. But if you read Eric Sink's experience with Winnable Solitaire you'll either decide that Wx is better or to just trade time doing shareware for time doing consultant ware (where you find a decent client to squeeze money from). And I really wonder if Wx is better than Qt when it comes to doing consultant-ware. Is it good at XML? At db access? At Web services? Do they really care about truly usable form widgets? Documentation? Or compatibility with ActiveX components?

On the other hand, Qt's pricing hinders development in other ways, if you wanted to give your customers a chance to modify your game (like Lux offers customers a chance to create their own map and AI) or create a small cottage industry of people writing extensions for your application (say allow your users to create wizards for QCad), you'll need to offer an API or some sort of scripting language front-end. With Qt, your budding community of boutique extension writers may have to license the same Qt components to make commercial plug-ins (provided the module interface requires/recommends they make use of Qt to make the modules, which is not unreasonable assumption to make if you want UI consistency) at several grands a pop. Ofcourse a way around it is to allow extensions to link to an alternative library to Wxwidgets but that may or may not compromise on the look of things.
Li-fan Chen Send private email
Wednesday, August 31, 2005
 
 
Li-fan Chen Send private email
Wednesday, August 31, 2005
 
 
I have just had a quick conversation* with a select number of core team of wxWidgets working on the Gtk, Windows, and Mac ports--they have a system of meeting trouble tickets on a priority basis to help commercial users handle any bugs or feature-adds.

* It would not be appropriate to quote prices here as the price will vary depending on the extend of support you'll requirement.
Li-fan Chen Send private email
Thursday, September 01, 2005
 
 
s/requirement/require/
Li-fan Chen Send private email
Thursday, September 01, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz