Objective of this Document
Chandler is developed in Python and uses wxPython/wxWidgets as its crossplatform UI framework.
The decision to use wxWidgets has been made early in the project and needs to be reevaluated against progress in competing frameworks.
The goal of this document is to continue observing advances in other frameworks as well as learn from what we had to go through in developing with wxWidgets for Chandler.
Preliminary Thoughts
wxWidgets
The use of wxWidgets on Chandler had us go through some pain: we had to develop an intermediate UI description layer (CPIA) and are spending 30-40% of our development energy fixing and extending wxWidgets directly, writting and debugging C++ code.
Although somewhat unavoidable, this is not ideal. Ideally, a framework should allow us to concentrate on writing Chandler, working within the limitation of the framework and only exceptionally having to extend it.
We should be spending minimal time tinkering with the framework itself. The fact we have to spend a sizeable portion of our effort on wxWidgets is a sign that something is amiss, whether we are not using the framework correctly, or trying to bend it to do things it was not designed to do, or simply because the framework is not adequate to our current needs.
The constraint we have is that we want to work on all platforms, develop mostly in Python and provide a high performance, high quality, consumer level product (see requirements). Being as "native" as possible seems like a good idea.
Going fully native on each platform is expensive. An idea of course is to develop a thin layer on top of the native platform UI frameworks that covers the widgets we need, abstract the event model and use it. This is pretty much what wxWidgets is all about and the main reason why we are using it.
One issue (for Chandler, as a 1.0 project) with wxWidgets is its legacy: wxWidgets started long time ago (12 years according to its website) and it tries to maintain compatibility with way more platforms that we really care for (eg, Win 95) and obscure C compilers. Some design choices might make little sense today, overall architectural tenets like Accessibility where not even on the radar screen of developers back then. Add to that an "engineering" or "enterprise" flavor to its look and feel and it's hard to code a consumer level application like Chandler.
So, wxWidgets has issues but its saving grace is that it's Open Source. In some ways, it's really up to us to raise up to the challenge and make the investment to make it better for us and the whole Open Source community. It certainly would be a good thing to have an Open Source alternative for crossplatform development that's not derived from a web based approach and is closer to the native OS core bone.
Focusing squarely on Calendaring for 0.6 will give us a real opportunity to test whether or not wxWidgets can live up to our expectations. If we can't get to the level of fit and polish we deem acceptable for Chandler in the 0.6 timeframe, that'll certainly be a sign that wxWidgets is simply not going to cut it for us in the long run.
Web App Frameworks
Applications have been moving to the web in various shapes: simple forms, scripted pages (DHTML), AJAX and RIA (Rich Internet Applications) using client side frameworks like Java or Flash. For a while, it seemed that browsers would expand to the point where they would host any application within their boundaries but the constraints of the browser frame and security/privacy worries are keeping this from happening.
Instead, another movement started that's trying to bring to the world of desktop applications development the flexibility, richness and speed of prototyping of web applications. A common architectural model (yet unnamed, here's our opportunity to coin some trendy acronym...) is emerging that is basically hinging on 4 key layers:
- a powerful graphic rendering engine: one that allows not only for traditional widgets but also free form vector graphics and animation.
- an abstract UI layout language: using XML to describe the semantic of the UI.
- easily editable visuals: separated from the semantic of the UI and allowing user defined skins, accessibility and internationalization.
- a dynamic scripting language: to bind everything to the core logic.
There are currently 3 incarnations of this general model:
- Macromedia Flex
- Microsoft Avalon for Longhorn
- Mozilla XUL
The following table summarize the elements of those 3 models:
| Name | Scripting | Skinning | Layout | Rendering | IDE | Comments |
|---|---|---|---|---|---|---|
| Windows LH | C#, .Net | CSS | XAML | Avalon | Sparkle | Longhorn timeframe... Aimed at Desktop, eating on WebApp RIA |
| Flex | ActionScript | Flash, CSS | MXML | Flash Player | Flash Pro | Moving to Mobile, dead for the desktop (Central) Not Open Source but Lazlo RIA is |
| XUL | JavaScript, XBL | CSS | XUL | Gecko, Cairo | (None) | Standard based, Open Source and Cross Platform Will (potentially) reach from desktop to Mobile |
On a much smaller scale, one could mention also Mac OS X Tiger Dashboard widgets that are also following a similar model (JavaScript, CSS, XHTML, WebKit), simply externalizing the web toolbox outside the frame of the browser.
We believe that, because of its expressivness, breath (from desktop to mobile) and flexibility, this model is going to become the de facto standard for developing and deploying desktop applications for business, office and communication. We also believe that Chandler fits that profile perfectly.
Links
- wxWidgets vs. the World
- Tiger (Mac OS X) Dashboard
- Evaluating Application Frameworks by David Surovell
Requirements for Chandler's Framework
We need to list what we want from a good framework for Chandler:
- Editability: must be easy for designer to tweak the UI (color, font, layout, position, alignement) without requiring coding.
- Responsivness: UI needs to be fast and fluid.
- Expressivness: allow for rich UI behaviors, potential for advanced UI concepts (space / time continuity for instance).
- Python: be usable from Python.
- Crossplatform: develop once, deploy everywhere. We do not want to maintain several code bases and want to release on all platforms simultaneously.
- Open Source: as much as possible, the framework must be available as Open Source.
- Standard: follow standards wherever it makes sense, don't use proprietary technologies.
wxWidgets
Pros
- Truly native widgets on all platforms
- Open Source
- Maintained by an active community
- Used by some major projects (AOL, Amaya)
Cons
- Legacy of platforms/compilers support hinders move to implement more modern UI/coding concepts
- Truly native also means always trailing behind the advances in each platform (see Mac Toolbar)
- Fixed "middle of the road look" (heavily Windows like) for most composite UI element (see ListCtrl)
- Any departure from widgets as coded in the framework requires extensive rewrite in C++ (see minical, sidebar, calendar)
Opinion
If it were not for our focus on cutting edge, consumer level look and feel, I'd be happy with wxWidgets. But since we need to do a lot of custom controls to cover our needs (so that we can live up to a comparison with Outlook or iCal), I feel uneasy with wxWidgets.
Links
XUL
A very detailed analysis of XUL vs CPIA has been written by Alec who has been involved in XUL development at Mozilla.
Pros
- Clear separation logic/view: XUL embeds the logic of the UI (nodes hierarchy) while CSS embeds its layout details.
- CSS: very well known, well traversed, well documented, easy to edit... It also will provide for platform specific tweaks.
- Use native widgets for almost all of its widgets
- Support arbitrary drawing and compositing through SVG
- Standard based and Open Source
- We have expert knowledge in the team
Cons
- Language: JavaScript. Need to use PyXPCOM if we want to use Python. The links on it are somewhat stale (latest version is 0.92, May 2001). Is that still actively developed? News : There's also the possibility to use Python directly instead of JavaScript. This is very new but we should see some version of it before the end of 2005.
- Limited widgets library: The library is rich and well implemented but some platform specific widgets are not and cannot be implemented.
- Needs a runtime XRE: XRE is apparently not widely distributed although, obviously used by Thunderbird. We would need some hand holding to package our own app with an XRE. Overhead? 5 to 10 MB of compiled code.
- Performance: Cairo is not in the XRE right now so lots of the fancy Cairo capabilities (rendering using the GPU) are not available to a XUL app... yet. This needs to be discussed with Mozilla folks. It's not really a con though (we don't really need Cairo right now) but if XUL was rendered using Cairo, this would definitely be a big pro!
Opinion
XUL has lots going for it. Its architecture is closer to the modern desktop/webapp frameworks out there (plus this one is Open Source...) and certainly has more momentum and less legacy than wxWidgets.
That XUL is using the Gecko engine exclusively and the substantial XRE is imposing a lot. On the other hand, the fact that it has an elegant answer for crossplatform headaches (like font specs and out of box usability) as well as a well understood, easy to code and (yes!) documented format makes me jealous (when compared to wxWidgets).
XUL is my favorite contender assuming we can make good use of PyXPCOM and continue to use Python.
Links
- XUL vs CPIA
- XUL HomePage
- XUL Planet (great XUL Documentation)
- XRE (XUL Runtime Environment)
- XULRunner
- PyXPCOM
- Python for XUL scripting
Macromedia Flex
Pros
- Support very advanced UI concepts (spatial continuity, animations)
- Very rich visual
- Distributed on virtually every machine of the planet
- Scale to Mobile devices
- Big corpus of designers
- There's an Open Source development platform (Lazlo)
- The format is public
Cons
- Base technology is very much proprietary and not open (despite OpenLazlo)
- Unclear how a Flash app could be made to host external plug-ins (aka parcels in Chandler's parlance)
- Unclear how it would work as a pure desktop solution (Central is dead)
Opinion
Lazlo could easily move to a XUL+Gecko model from its MXML+FlashPlayer root if they wish to though there's no evidence they are trying to do so...
The proprietary nature of the technology makes Flex a non starter for us.
Links
Adobe Source Library
ASL is a new set of Open Source components released by Adobe. It contains a variety of libraries that have been used by Adobe on several projects, most notably PhotoShop. The 2 of the most important components from a UI standpoint are:
- Adam: a modeling engine to describe relationship between values in the UI
- Eve: a declarative layout engine
ASL though is not a UI framework but rather sit on top of one. Eve is very much the equivalent of CPIA. Adam does not have a clear equivalent, everything that Adam does is coded in Python in Chandler.
Pros
- Abstract layout engine
- Track record of UI rich cross platform applications (PhotoShop, InDesign, ...)
Cons
- Not a complete framework
- 100% C++, no Python
- Very recent Open Source player, only used by Adobe so far
Opinion
The fundamental fact that ASL is not a complete framework but only a replacement for CPIA is a clear non starter. Also, though we already made ourselves a specialty of SWIG wrapping C++ libraries, I don't see us taking over a PyASL project.
Links
Qt and PyQt
Pros
- Very complete widgets set
- Industry grade, used by several high profile products (Skype, PhotoShop Element, Opera...)
- Used by KDE so it is the native framework on some Linux distros...
- Qt Designer, a visual tool to create Qt UI's (a la Interface Builder)
Cons
- Dual Licensing (GPL / QPL): OK for us but issue for anyone who would like to derive a commercial product from Chandler
- 2 layers to deal with (Qt and PyQt), both owned and licensed by separate entities
- No support whatsoever for non paying customers except for user's groups and mailing lists
Opinion
From a strict technical aspect, Qt and PyQt have lots of clear advantages: well established, widely used, solid and proven. Numerous commercial consumer grade applications have been developed with Qt and Chandler looks like something easily within the grab of Qt. There is also lots of tools, books and support available (for commercial versions).
The licensing policy could clearly put us at odds with the Open Source community. TrollTech changed the terms recently though that Open Source non-profit (like us) can use the product free of charge on any platform. The license will however be an issue for anyone wanting to contribute to Chandler with, potentially, some ideas about building a commercial product. The fact that you need to acquire licenses (per dev!) prior to start developing is imposing a lot on 3rd party developers who might just want to play around with Chandler without any clear plan at first.
Additionally, PyQT is not provided by TrollTech but by Riverbank, adding another layer. Technically, this does not create a problem but the licensing scheme of PyQT is similar to (but independent from) Qt and must be added to the one of Qt. For anyone looking for a license of Chandler, they'd have to go through those 2 entities.
There's really nothing wrong technically with Qt (reviews of Qt 4 and Qt Designer 4 have been pretty good). It's just that for a group in our position, starting with all those licensing trinkets is asking for problems down the road with the community.
Links
PySWT
SWT (Standard Widget Toolkit) is the new cross platform Java toolkit for GUI development. Taking AWT lessons into account, SWT does not try to impose a specific Java GUI flavor but rather implements the native OS widgets within the Java environment. SWT has been endorsed by the Eclipse consortium (actually it was used to develop Eclipse).
Taking cue from our own PyLucene, an independent developer wrote a Python wrapper for SWT.
Pros
- SWT is rock solid and very well supported and documented
- Native widgets on all platforms
Cons
- Performance: the 3 levels of indirection (Python -> Java -> C) is likely to introduce some lag
- PySWT itself is very immature
- All programming, no intermediate layout/skinning layer accessible to non programmers
Opinion
It's really early to form a judgement on PySWT. Clearly, SWT is a solid contender but having to potentially fix bugs in 3 languages is worrisome.
Links
PyObjC
Since PyObjC is Mac only, the idea here would be to use it for Mac development while continuing with wxWidgets on Windows and Linux. This makes some sense since most of our issues with wxWidgets are on the Mac side of things.
The picture is somewhat more nuanced than "Mac/ non Mac" though and Bill Bumgarner has been kind enough to comment that paragraph send me the following information:
- PyObjC supported GnuStep off and on throughout its development. The support is still there, but needs some help.
- Generally, you only need to write Objective-C when interpreted Python isn't fast enough. Subclassing of views, etc, is fully supported.
- There is no requirement to use NIB files. Everything in Cocoa's UI can be built programmatically. Renaissance demonstrates an automatic GUI layout tool that uses XML to describe UIs.
Pros
- Easy to prototype and develop on Mac (using InterfaceBuilder and Nib files though Nib files are not required as pointed out by Bill)
- 100% Cocoa native
- High satisfaction for Mac users
Cons
- Mac specific
- May require development of Objective-C objects for special widgets
Opinion
Unless we really exhausted all the other possibilities of finding a fine crossplatform framework, being Mac only is a non-starter for Chandler. That it would double our work on the UI side is annoying but we could argue that we're already spending quite a bit of out time to fix Mac specific bugs. The real issue though is that it will also make the work of external contributors more difficult, forcing them to develop their ware twice (although we can imagine that parcels using basic CPIA and AE stuff can work crossplatform). Eventually, this would create 2 branches of Chandler's UI (one for Mac, one for Windows/Linux or, alternatively, one for OpenStep, one for non OpenStep platforms) and also double the documentation work...
Links
Comparison Matrix
| Framework | Editability | Responsivness | Expressivness | Python | X Platform | Open Source | Founded or maintained by |
Standard based | Scale to Devices (handheld, mobile) |
|---|---|---|---|---|---|---|---|---|---|
| wxWidgets | Poor (Fair through CPIA) |
Good (native) |
Poor | Yes (wxPython) |
Yes | 1993 | Julian Smart | No | Yes |
| XUL | Good | Fair | Fair | Yes (PyXPCOM) |
Yes | 2001 | Mozilla | Yes | Yes |
| Flex | Fair (Complex if fancy Flash) |
Good | Excellent | No | Yes | No | Macromedia | No | Yes |
| ASL | Good | Good | Good | No | Yes | 2005 | Adobe | No | No |
| Qt PyQt |
Excellent (Qt Designer) |
Good | Fair | Yes (PyQt) |
Yes | Yes but (dual license) |
TrollTech Riverbank |
No | No |
| pySWT | Poor | Good | Fair | Yes | Yes | 2005 | Zillin | Yes (Java SWT) |
Yes |
| pyObjC | Excellent (InterfaceBuilder) |
Excellent (native) |
Good | Yes | No (Mac only) |
2002 (MIT license) |
Bill Bumgarner | No | No |