As anyone trying to persist with FMX will know, XE2 update 4 is out. By accounts, some people have had installation issues, though personally, this update went smoother (and possibly quicker) than the other three. A glutton for punishment though, I then upgraded my iMac from Snow Leopard to Lion. Took ages to download, and while the installation itself was apparently quick, it was less quick in reality due to a sustained bout of reindexing (or something like that – OS X didn’t tell me what it was doing) afterwards. This meant the computer was essentially inoperable for a long period afterwards – anything more substantive than TextEdit was taking 5 minutes to load.
Having now upgraded, Lion is definitely in the ‘meh’ category for me: it adds the ability to resize a window with the mouse from something other than the bottom right hand corner (at last!), but the new features otherwise I either have no interest in or have actually disabled (e.g. wacky scrollwheel behaviour). Furthermore, the visuals to my eyes have gone a but messy. In particular, what’s up with the font sizes? The font in the left hand pane of Finder is now oversized by default, yet the font in the TextEdit toolbar is tiny – Snow Leopard, in contrast, was generally nice and consistent. Another aesthetic change I don’t understand is the button styling, although it means I must take back the criticism I’ve previously made about FMX’s attempt at ‘native’ styling for TButton – since the default styling doesn’t change between OS X versions, it looked ugly and out of place on Snow Leopard, yet is quite a good attempt for Lion… and better looking than the ‘real thing’ to my eyes!
As for ape itself, FMX has acquired printer support for OS X, which is good, but also font visuals for Windows/GDI+ that make you go cross eyed, which is bad (since the FMX form designer seems to use GDI+ even if you are running Windows 7, you can’t avoid this problem). Then again, FMX controls already looked crap on my year-old Windows 7 laptop, so it’s not like something wonderful has been made bad.
The nature of the OS X printing support is also slightly disappointing in that they’ve gone with using the Carbon API rather than figuring out how to apply the Cocoa/NSView-based printing interface. Admitedly, this was somewhat forced by the decision back last spring/summer to hurriedly copy and paste from the VCL sources in order to support printing on Windows, since the Carbon API is quite a nice fit for TPrinter where the Cocoa printing API patently isn’t. Ideally, there wouldn’t have been any rushed copy-and-pasting from the VCL sources in the first place though! Other than that, fundamental issues in FMX remain – the more I look into the sources, the more I am appalled quite frankly. If you want a horror story, have a look at the menu code…
And yet! While waiting for update 4, I investigated how to support the native OS X MDI style in a cross compiling FMX application. Notwithstanding the fact the lack of TAction support makes the cross targeting part harder and more error prone than otherwise, and there’s always a basic FMX bug or dubiously short-termist design decision lurking ready to bite, I’ve managed to get quite far:
Until I started this exercise, I didn’t realise that the document icon in the title bar of a Cocoa window is right-clickable:
While you can’t see it, files can also be dragged onto the Dock icon, and on Lion, the ‘recent files’ list on the Dock icon’s popup menu shows as expected. Also as you would expect in a Mac application, it is possible to have no document windows open but the application itself still running with its menu bar. This is contrary to the VCL-inspired assumptions of FMX, which works on the basis of a ‘main’ form, however those assumptions are not too hard to work around – you just need a dummy ‘main’ form that is never shown on screen.
Targeting Windows the same application looks like this – since Windows-native MDI has been de facto deprecated by MS since the late 1990s, if not earlier, I’ve used an SDI style there (i.e., like Notepad or WordPad):
There’s still a few things to tie up, but I’ll release the code at some point. While the program itself is only a FMX rewrite of a small demo application for my image metadata reading/writing code, I’m writing the cross-platform document management stuff as its own mini-framework – the form units themselves contain no IFDEFs at present because of that. I’ve also written a few other things for it, e.g. versions of ShowMessage and MessageDlg that map to the native message boxes (the FMX ones look crap), and an FMX TClipboard with a similar interface to the VCL version but works on OS X too. If anyone’s interested, I may end up putting these things into their own project on Google Code or something like that – back in September I wrote a TCustomIniFile implementation that maps to the OS X ‘Preferences’ API, making for a rough analogue to TRegistryIniFile on Windows, so that could go in with them too.