tutorial-pros-and-cons

Phoenix::Tutorial - Pros and Cons

phoenix is not a GUI toolkit by itself, it is a meta-toolkit. That is to say, it is a wrapper around many other toolkits. This comes with many very important advantages and disadvantages. You should evaluate your needs and choose what works best for you.

Executive summary: phoenix is a light-weight API meant to be used for writing small to mid-sized cross-platform applications. Highly specialized and complex applications would not be served well by phoenix.

Advantages

phoenix is tiny: if you wish to deploy binaries on Windows, sometimes size is important. If you have a 20KB utility application, you may not want to have to include 8-20MB of run-time DLLs for a cross-platform toolkit. phoenix can be statically linked into an executable for a cost of ~50KB.

phoenix is minimal: no extraneous features are added. This means that porting phoenix to a new platform is very quick and easy. It would take an experienced developer at most a week to target a new toolkit. This gives your application an additional level of portability.

phoenix is extensible: when you find that certain functionality (eg a specialized widget) is required, phoenix can easily be extended, and this need only be done for the toolkit targets you wish to utilize. Auto-resizing layout managers in particular only need to be written a single time, and can be used on all targets. Of course, some decent layout managers are included as well.

phoenix is simple: phoenix takes the best design paradigms from every toolkit to provide of of the easiest to learn and use APIs.

phoenix is consistent: if you take the approach of writing your GUI for each platform you support, the inconsistencies are maddening. From Windows menubars that do not allow you to hide menu items, to GTK+ list boxes that require a Mensa-level IQ to comprehend, to Qt signals and slots requiring a separate pre-processor. From Windows having no auto-resizing layouts, to GTK+ using a box packing model, to Qt using a horizontal/vertical partitioning layout. From miserable frame geometry information provided by GTK+ and inconsistent geometry handling in Qt. From OS X forcing you to learn an entirely new programming language. Inconsistencies are the programmer's bane. phoenix takes care of all of these details by forcing every platform to use the same API, with the same functionality everywhere.

phoenix is native: other toolkits will talk about using native widgets and mimicking others to look like a native application, but phoenix literally is native as it is simply a lightweight wrapper around the native APIs.

Disadvantages

phoenix is limited: by only including necessary components and functionality, you may be forced to compromise on design, or in some cases, you may need to add missing functionality yourself. Many limitations are based on the fact that multiple toolkits are targeted: this design approach forces a least-common denominator approach to features. For instance, Qt has a nice table view widget, but Windows and GTK+ do not. Thus, phoenix does not offer this type of widget.

phoenix cannot yet target Cocoa: due to phoenix utilizing C++0x, and Apple not supporting GCC 4.3 or newer in any way over the GPLv3, we are forced to wait until C++0x support is completed in LLVM. phoenix can still target OS X via the Qt target, but this negates the size and native widget advantages.

phoenix is still in early development: although much of the harm here is mitigated by being able to statically link with any given phoenix-snapshot; if you want to keep up with the latest phoenix releases, the API may change in subtle ways between point releases. This is only a temporary thing: I want to make sure the API is well tested and designed before setting it in stone with backward-compatible stable releases.

Nothing can make an application look native on both OS X and any other platform: Apple has too many customizations, such as their single-menubar approach, dock interaction, applications not closing when you click the close buttons, and so on and so forth. There's simply no toolkit in the world that can offer a truly integrated experience on both OS X and any other OS in existence. That's not to say you can't get close, of course. But given the unreasonable expectations of most Apple users, in the best case you may be forced to design a separate UI just for OS X.

Draws

Some things can be considered both advantages and disadvantages.

phoenix is modern: C++0x was only recently approved as a standard, and as a result, compiler support for it is very limited. However, C++0x offers very compelling functionality that greatly aids in UI development, such as lambda expressions. When compared to Qt's signals and slots (which require a separate pre-processor), the advantages are very compelling.

Simplicity vs Portability: listed in both the advantages and disadvantages section for elaboration; this is a balancing act and there is no way to eat your cake and have it, too.

Portability vs OS X Integration: like above, there's no way to both have a single, portable development target and look perfectly native on every OS at the same time. As with any toolkit, minor customizations can be made to mitigate many of the most glaring deficiencies.

Native Integration vs Consistency: although ideally we want every platform to act exactly the same, sometimes things must be slightly different to match native platform expectations. For instance, on some platforms, only the return key will activate a listbox entry. Whereas on others, the spacebar can also be used to activate the entry. I have forced consistency whenever it would not be too jarring, but there are limits to this. As with any cross-platform development work, you will want to test on every targeted platform.