An easy way to summarise the good things about FMX in XE3 is to say it is much better than FMX in XE2; an easy way to summarise the bad things is to say it couldn’t have been any worse. Put another way, the promised regular XE2 updates for FMX turned out to be (a) less then regular, particularly after the first couple and (b) disappointingly slight; even so, browsing the source suggests a big reason for this was that the XE2 code was forked early on, with anyone competent devoting their time on the fork rather than the original.
Speaking in more specific terms, here’s some good things I’ve found about FMX in XE3:
- The default Windows Vista/7 styling is pretty good, indeed good enough in my view. It’s at the level of custom drawn VCL controls (e.g. TSpeedButton) that try to look and behave ‘native’.
- The awful walking-up-the-list thing I blogged about a few months ago has been largely fixed.
- Actions are in.
- Less a big deal than actions (at least for me), but anchors and a subset of the VCL’s touch and gesture support are in too.
- TTabControl (equivalent to TPageControl in the VCL) actually works at design time. This is important if you are as tab-dependant like me…
- It is possible to target OS X without a ‘main form’ concept being in effect, which is crucial to implement the basics of the Mac ‘document model’ (what I sometimes call myself ‘Mac-style MDI’).
- The inherent flexibility of designing a UI using FMX compared to the VCL is still there.
- The refactoring done for XE3 was largely for the better.
Nonetheless, even on its own terms, ‘FM2’ really needed a few more months. The bad things I’ve found include the following:
- The menu code (crucial on OS X especially given the Mac menu bar) remains atrocious, being essentially the same as in XE2 –
- Change a menu item’s state, and the whole menu bar is rebuilt (or would be – bugs and oversights mean nothing happens half the time).
- TMainMenu is tied to a particular form, which doesn’t make sense on OS X.
- Far more code than is actually necessary to do it right is used. I am inclined to say the person who wrote it is incompetent, though whoever authorised its inclusion and then failed to prioritise its fixing is just as bad.
- Dancing text on Windows remains. This is a showstopper. What more can be said?
- Too many properties and methods can return nil instead of raising an exception. A prime example of this is the Children property of TFmxObject when the object has no children. In that particular case, the cause is the internal FChildren list being nil until the first child is added, then freed and nil’ed when the final child is removed. This coding style is used elsewhere too, and I can only understand it as a ‘cargo cult’ practice picked up from reading the VCL source. In 2012 this only complicates the code unnecessarily however – truly, just create the list in the parent object’s constructor, and free it in the parent object’s destructor.
- Still on the Children property, this directly exposes the internal list object. This is an error, because it allows client code to call SomeControl.Children.Add(NewChild) and therefore bypass the (virtual) AddObject method that remains the ‘proper’ way to add a child. Same with Delete/Remove and RemoveChild. (Before any says ‘but that’s just one property’ – TFmxObject is, as its name implies, a core class in the framework. Write it sloppily, and doubt arises about the quality of the framework generally.)
- While the OS X side (well, most of it – see the next point) doesn’t enforce a ‘main form’ concept, the Windows side does. This is nothing to do with ‘native Windows behaviour’, but an ancient VCL-ism.
- The small set of standard actions provided are unusable on OS X because they require a ‘main form’ to exist. They also have odd inefficiencies built into them.
- The action code generally is over-fussy in my view, erroneously copying complications from the VCL code. I’m intending to blog about this separately.
- Talking about actions, if you assign an action from a data module to a control, the IDE will sliently lose the association at a later point, just like in the VCL. Urgh!
- I’m not sure about aspects of the default OS X styles. This isn’t necessarily EMBT’s fault – e.g., the ‘native’ equivalent of TTabControl is probably NSTabView, however NSTabView (a) puts has its ‘tabs’ centred not left-aligned and (b) isn’t actually used much by ‘native’ OS X applications. As it stands, the default OS X style for TTabControl takes its colours from NSTabView, but just looks weird because the sizing and positioning is different. Imitating the tab control styling in Safari or Firefox might be a better idea.
- Efficient string interop on OS X appears to have been sacrificed in favour of cross compiling the FMX source using the upcoming ‘next generation compiler’ for iOS. To be clear, in your own code efficient string interop is still possible (both Delphi and Cocoa use UTF-16 internally) – it’s just that the FMX source deliberately uses clunky UTF-16 -> UTF-8 -> UTF-16 roundtrips via a ‘marshaller’.
My thoughts overall? If XE3 marked the first release of FMX, I would be very positive, notwithstanding the fact my list of ‘bad things’ is longer than the list of ‘good things’. In the case of the menu and action issues, for example, it is possible to work around them with a combination of interposer classes and custom IFMXxxxService implementations (for details, see this unit of mine). However, the happenings of a year ago are not just ‘water under the bridge’, and moreover, the fact FMX hasn’t been dogfooded even for the Platform Assistant installer (Java is still used instead!) doesn’t inspire confidence. The worry, quite simply, is that what remains to be fixed beyond straightforward bugs will now never be fixed.