I’ve just added a set of FMX demos in the SVN trunk for my image metadata reading/writing library, CCR Exif. These are ports of the existing VCL demos (minus the resaving tester). In alphabetical order, they number the following:
- ExifList displays the Exif tags from an image, Exif being the metadata format most cameras use.
- ExifTimeShifter shifts the Exif date/times for one or more images by a specified number of minutes.
- IPTCEditor edits the IPTC data held in an image. IPTC is the metadata format Photoshop used back in the 1990s, and makes for a slightly lower-tech alternative to Exif.
- JpegDump displays information from a JPEG file’s header, providing a lower-level view of its metadata tags than the other demos.
- Screenshooter takes a screenshot, applies a few tags, and saves to a new JPEG file.
- XMPBrowser displays XMP metadata in a tree view, XMP being a newer, XML-based metadata format.
While the FMX demos (which require XE3 by the way) mostly hew to the line set by their VCL forebears, I began with a blank slate in each case. This I did because I wanted certain UI details to follow the target platform (i.e., Windows or OS X), and in so doing, see what FMX did to help, or at least, see how far it wouldn’t get in the way.
Screenshooter and ExifTimeShift
The simplest demo to port was Screenshooter, since the FMX version has almost exactly the same UI for both platforms. The only difference is the fact the Mac version has the regular Mac menu bar; however, the menu items on it are just the standard ones that FMX in XE3 set up for you automatically:
Similar between platforms too is ExifTimeShift:
In this case there are some subtle differences though:
- I hide a few toolbar buttons on OS X because toolbars on a Mac just tend to have less items than their Windows equivalents.
- The Preferences/Options dialog is non-modal on OS X, with no explicit OK/Cancel buttons and changes applied immediately. (I leave aside whether this makes for a better UI – in fact, I think I prefer the Windows model myself – but that is the contemporary Apple style.)
- On both platforms, double clicking a listed file displays the image. On Windows the image window gets its own taskbar button; on OS X it is full screen-enabled – you can see this in the screenshot with the double arrow icon on the title bar – and listed under the application’s Window menu. While I had to implement these things manually, it wasn’t hard, though I’d admit the Windows part requires more work (the FMX developers are unfortunately obsessed with a Win 3.x/VCL-style ‘main form’ concept that isn’t technically native even on Windows).
- The file date/time preference is saved to the Registry on Windows and the application’s preferences file on OS X. Since I didn’t want to introduce dependencies, the latter is done by direct API calls, though in practice I would use my own Mac Preferences API wrapper I blogged about previously.
ExifList, IPTCEditor and XMPBrowser
The main platform difference between the remaining demos is much more ‘in your face’: whereas on Windows the applications are SDI, on OS X they follow the basics of the Mac document model. As such, if you run ExifList, IPTCEdit or XMPBrowser on OS X without passing the application a file first, it opens with no window showing. This follows what Preview does:
Further, whereas the same instance of the Mac version can have multiple images open, each with their own window (and enumerable using the system-standard Cmd+` shortcut), you need to open the Windows version several times to have it load several images at the same time:
Implementation
Each demo is essentially single source, and structured around my preferred VCL UI model. In this, the document form’s OnClick code is all centralised into action lists located on a data module separate from the form itself, with any necessary communication between the actions and the form being performed via interface types. A unit shared between all the demos (CCR.FMX.Demos.pas) then contains all the platform-specific UI-related code, and manages the differences between the different document models (no form is auto-created in the traditional Delphi fashion, and the document form class itself is looked up using RTTI). Alas, but that unit also implements certain crucial bug fixes for FMX itself, though at least the new IFMXxxxService system (see my previous-but-one post) made that bareable. I’ll probably blog about it in more detail later.
