Thursday, June 12, 2008

Why not wxWidgets or Qt

I have had a number of people ask me about why I have chosen to not use a cross-platform GUI toolkit like wxWidgets.  There are several reasons for this and so I wanted to explain my reasoning.  There are a bunch of very good choices for GUI toolkits.  I spent a good amount of time evaluating a selection of them: GTK+, Qt, wxWidgets, Fox, and others.  I decided that I wanted to try something a bit different for two primary reasons.

As I see it, there are four primary GUI components that all contribute to the Wildcat user experience:
  1. Primary rendering window
  2. Toolbars
  3. Menus (both context and primary)
  4. Dialog windows
The primary render window is pretty straightforward to implement and get right.  I have it mostly up and running on Mac and Windows, and GTK+ for Linux should not be difficult.  The primary render window won't change much over time.  It renders using OpenGL.  It's a window.

Toolbars are a more complex issue.  What is a toolbar?  A toolbar looks really different on Mac vs. Windows.  Toolbars need to be very flexible and change constantly depending on the tasks the users is executing.  They need to be dynamic and configurable.  I have a first shot at the Mac version, and hope to incorporate the Windows ribbon interface down the road.

Menus are similar to toolbars.  They change a lot, very dynamic.  But I don't feel they are as complex as toolbars since they tend to not be user configurable.  I have not done much with them yet on either Mac or Windows.  In time...

Lastly, dialog windows.  For CAD applications the dialog windows seem to define a lot of the user experience, but they are slowly giving way to a better mouse interaction models.  I want traditional dialog boxes, but not in a traditional way.  I want them to be much more customizable.  Read on to see where I am going with this.

So, back to the two primary reason I have decided not to go with a cross-platform toolkit.  Here we go...

Reason 1: Cross-platform does not mean platform specific

As I mentioned above toolbars on Mac are a very different concept than toolbars on Windows.  On Windows they are strips of icons that typically dock to a portion of a window.  The OS X interface is moving towards a "pallet" concept.  The toolbars are placed together into a separate tabbed window that sits to the side of the primary window.  Can you imagine the Windows ribbon on a Mac.  Not going to happen.

For another example look at multi-document interface applications like MS Word.  If you open a bunch of Word docs on Windows you get one window with many child windows within it.  On Mac you get multiple windows.  Same concept, very different approach.

My feeling is that as users approach an application for the first time they tend to have all of the memes of the OS in mind and are expecting a similar experience.  That is what makes a Mac a Mac.  This philosophy is much stronger on Mac than Windows.  MS has taken a hands-off approach and you tend to see a wider range of look-and-feel on Windows.

When I looked at the cross-platform toolkits they all seemed to make your application look the same regardless of what OS it ran on.  In my opinion it should be the other way, your app should look like the OS it is running on.  While this may increase developer effort, I feel that it will pay for itself with a better user experience.


Reason 2: I want traditional dialog window, but not in a traditional way

In the intro to this post I spoke about dialog window being fundamental to the CAD user experience.  If Wildcat doesn't use a cross-platform toolkit doesn't that mean every dialog window will have to be re-coded for each platform?  The traditional answer would be yes.  I think that I may have a way around this...

I have embedded the open source WebKit HTML rendering engine into Wildcat.  All Wildcat dialog windows are actually simple platform windows with a web browser pointing to a local file.  Here are the advantages to this approach:
  • Cross-platform solution - WebKit runs on Mac, Win32, and has a GTK+ port
  • High-performance JavaScript engine for free - now we have a scripting engine for Wildcat operations too
  • Change the CSS, change the look-and-feel - this makes it possible to easily "skin" Wildcat to provide a new or different look
  • HTML is really easy to program - Who hasn't created a web page?
  • Dynamic generation - why not generate HTML on the fly?  Crazy idea, I know.
OK you say...interesting approach.  How do you tie the dialog window actions to the core app and visa-verse?  WebKit has JavaScript hooks for all pages it renders.  I created similar hooks in Wildcat that allow data and events to be passed back and forth.

There are slight performance implications to this approach, but they are really minor and the user should never even know what is happening.  It should make it very easy to expand and change Wildcat.  There may still be hurdles I have not foreseen, but as of now it seems to be working quite well.

I have only implemented this for the Mac.  If you are using a Mac when you first start Wildact you are asked what type of document you want to work on.  That window is just a web browser pointing to docTypeSelector.html.  Give it a try.  Kind of fun.

Let me know what you think.
Cheers,
   Graham

5 comments:

Stefan Boeykens said...

Interesting approach. While I follow your reasoning, I believe that Qt (the only toolkit I have used) goes a long way to make sure a Mac applications looks and behaves as a Mac application and the same goes for a Windows application.

Mac programs (esp. the Apple ones) are more and more using a single window with docked palettes approach (e.g. iTunes, Mail, Keynote) and more and more, the floating palettes are disappearing (e.g. Photoshop).

But the more direct manipulation and information you place in the main OpenGL window, the less it matters. And choosing HTML-based dialogs might be a valid approach.

Would you think that it's possible to enable different GUI toolkits in Wildcat? E.g. decoupling the wildcat system from a particular GUI and provide example implementations but allow developers to embed the system in their Toolkit of choice?

(BTW, Qt4.4 now includes Webkit)

Dan Heeks said...

Stefan, Qt isn't as free as wxWidgets, is it? wxWidgets is LGPL, but the only free version of Qt is GPL, so Graham would have to make his Wildcat software GPL too.
wxWidgets has wxHtmlWindow for doing web stuff.

Stefan Boeykens said...

Qt is free for the development of GPL software. If you have a commercial license, you can develop anything with it.

I'm not saying that Qt is the only solution. I'm suggesting that it would be interesting to have choice: a generic wildcat framework and one or more GUI connections, such as Qt or wxWidgets (which has a more liberal licensing scheme).

Anonymous said...

"visa-verse" is a new credit card? :-)

Anonymous said...

Are you aware that Webkit is based on KDE which of course is a Qt based app? Seems like you are dissing some of these GUI toolkits without understanding their capabilities.