The Right Tools for a Killer App
I’ve been thinking about what language, platform, and tools I would choose if I were writing a commercial desktop application. Here are my 7 requirements:
- The application should be cross-platform.
- UI should be rapidly developed with a tool.
- Layout should be done with managers and containers.
- The UI toolkit should adopt its look and behavior from the platform.
- Application logic should be written in a high-level, object-oriented language.
- Process-intensive tasks should be optimized later.
- Software licensing should be GPL-compatible.
Click through to read my explanation of the requirements and my conclusion on which language and tools I chose.
1. The application should be cross-platform.
Let’s not discriminate people based on their choice of OS. I happen to like developing and running on Linux, but the larger market is currently Windows. Let’s not forget MacOS and others either.
2. UI should be rapidly developed with a tool
We should be using a graphical tool to drag containers and components onto a form. Then the tool should generate the necessary files to create the UI in our application. If I need to make a change to the UI, I should be able to open my project in the tool and change it just as easily. UI is as much about form as function, so let’s work in that medium instead of wasting our time in code.
3. Layout should be done with managers and containers.
Really I am saying that we don’t want to use absolute positioning of components on the window. Screen sizes and language localization varies, and we want our screens to look nice on everybody’s display.
4. The UI toolkit should adopt its look and behavior from the platform.
There is a native look and feel on each platform that is consistent, and we want to fit in. Users expect to see familiar icons, dialogs, toolbars, and widgets that behave in normal ways.
5. Application logic should be written in a high-level, object-oriented language.
Two points here. High-level means we might even be using a scripting language instead of compiled. I shouldn’t have to worry about garbage collection or how types are represented in memory. Object-oriented means we will be thinking and designing for objects that will lead to tidy, modular code.
6. Process-intensive tasks should be optimized later.
Because our language is high-level, we may run into performance problems for heavy processing. The language should support making native calls to C/C++ routines where we can implement the heavy stuff. Optimization follows the 80/20 rule where 80% of the problem is found in 20% of the code. Load testing is usually conducted at the end of the cycle and code is rewritten for optimization then.
7. Software licensing should be GPL-compatible.
End users don’t care about licenses on the source code, but developers do, and we want to build a community around our software. If we want to be accepted in the Linux community, our license needs to be open-source and compatible with the GNU Public License. I would never buy a car with the hood welded shut, and I’m not asking my users to either.
So, given these requirements, where do we land? Java with SWT would be a good choice, except that Java itself is not open-source. With the progress made on the GNU Compiler for Java, this does seem a tempting option. But since Sun isn’t going to free Java any time soon …
My conclusion for language, toolkit, and builder are:
Python is a high-level, object-oriented scripting language that is often compared to Java. The core language and libraries are small, elegant, and extensible. The wxWidgets toolkit is a single API for writing GUI code that can be linked to a platform library to adopt its look and feel. It’s also lightweight enough that it works well on embedded platforms. wxGlade is a rapid GUI builder that generates Python/wxWidgets code or XML files. There are also full-blown IDEs for Python and wxWidgets, one of which is called BOA Constructor. (Get it?)
So, there you have it. There’s no reason to hold back developing that killer app now.
March 11th, 2004 at 12:56 pm
If your “killer app” happens to be a game, check out PyGame. It’s built on a cross-platform open-source game development toolkit called SDL (Simple DirectMedia Layer).
Also, you might want consider py2exe, which is a tool to convert python scripts into standalone windows programs.
March 11th, 2004 at 11:21 pm
Python: Nails #1, #5, #6 and #7
wxPython/wxGlade/BOA Constrictor: #2, #3, #4
Sounds like we’ve got a winner! Granted, wxPython on MacOSX isn’t solid yet, but Windows and Linux support is Gibraltar.
With Python tools such as Pysco (Optimizing Compiler), py2exe (Windows .exe-maker) and all of the other Python libraries (XML, SOAP/Web Services, DB-related, etc.), you’d think Python would be the first and overwhelming choice for Open Source development with your criteria.
That’s not even counting Twisted which does any and every kind of networking that you can imagine.
Unfortunately, Python doesn’t have an answer to Java’s Enterprise Java Beans … thankfully the Python guys are way smarter than that.
March 12th, 2004 at 12:32 pm
The closest thing I’ve seen to EJB’s in python is Zope Enterprise Objects. It’s built on the Zope Object Database (ZODB) architecture, but extends it to allow “multiple processes, machines, and locations to work together as one transactional object system”.
I’ll probably have to switch to ZEO someday before LunchMaster becomes too popular, hopefully before someone posts a link to it on Slashdot!
March 12th, 2004 at 5:46 pm
Thinking further on the subject of “Cross-Platform UIs” … I’m really thinking that there just is really no such thing. wxWindows/Qt/Swing/SWT … it MAY be possible to create a cross-platform UI with these toolkits, but at what cost? Is (D)HTML even a consideration? You can do some cool stuff with DHTML, but nothing that comes close to a pure client-side GUI.
The fact that so many OpenSource projects on SourceForge squander and die without every producing anything makes me wonder if it’s just better to pick a single UI platform and go for it. If it becomes overwhelmingly successful, use the code base to hit another platform. You have to also take into consideration that most of the above toolkits aren’t all at the same level on every platform (Windows, Linux & MacOSX).
It’s discouraging, but I just don’t see the above GUI toolkits delivering on their WORA promises without any stink.
Eric?
March 12th, 2004 at 10:15 pm
I want to develop a feature-rich desktop app, so I did not consider web development tools like DHTML.
Some of the toolkits use skins to emulate native look and feel, like Trolltech’s Qt and Mozilla’s XUL. In theory, you’d get consistent behavior across platforms since the only difference is skins. But the performance is slower, and the native behavior may not be emulated perfectly, so I didn’t consider these. (Each toolkit had other problems. Qt has bindings only for C++. Swing is not open-source. GTK+ is not stable on Windows or MacOS.)
The toolkits I did consider are thin layers on top of the operating system facilities, like SWT and wxWidgets. If a native component is unavailable, the toolkit will emulate it. I didn’t consider Java AWT because it uses a separate peer layer and has a limited set of components. One side-effect of wrapping native components is that it can expose pecularities in the platform. For example, programatically giving focus to a “radio” button may cause it to be selected on one platform but not others. Well-written applications can avoid these pitfalls, but you have to run and test them on every platform where they will be delivered.
Your strategy of “testing the waters” may be a good idea. You could write the app in wxPython, test it, package an installer, and release it for one platform. If it catches on, re-test (make any changes), re-package, and release for other platforms.