NakeyMonkey – Native OS controls for FireMonkey – Interview with Jason Southwell

Jason Southwell of Arcana @ Sivv makers of the ApeSuite for FireMonkey and EliteSuite for IntraWeb plus several other interesting projects has started a KickStarter project called NakeyMonkey to fund the development of a suite of FireMonkey controls that wrap the native Windows and OSX controls.

KickStarter is a well established crowd sourcing website, that is funding projects by appealing to the public to pledge donations towards the project. The project organiser sets a funding goal, in this case $20 000, and if they receive enough pledges to reach their goal, the donors credit cards are charged the amount they pledged and the project becomes funded. Depending on the amount they donate, donors receive a copy of the end-result or other benefits.

If you’re a FireMonkey developer or planning to be one I encourage you to consider pledging a donation to Jason’s NakeyMonkey KickStarter project. Being able to use native OS controls in a FireMonkey application will be a very useful addition to your arsenal. Remember your credit card will not be charged unless Jason reaches his $20 000 goal which he has less than 2 weeks left to achieve.

I interviewed Jason via email over the past few days about his NakeyMonkey project and crowd sourcing. Here is part 1 of that interview.

In a sentence can you tell us what is NakeyMonkey?

NakeyMonkey enables the use of native OS controls in the Firemonkey platform and does so cross-platform while maintaining a common component interface for your application.

“Nakey” isn’t a slang term we hear in Australia, can you explain the meaning behind the name “NakeyMonkey”?

Nakey means naked. It’s a term we use with our 2 year old daughter. When I was trying to figure out what to call a framework that stripped all of the styles away from Firemonkey and let it run free with the OS, Nakey seemed like an appropriate term.

Why do you see a need for NakeyMonkey?

We have been building Firemonkey components now as part of the Apesuite product for about 10 months. We have some really cool components that we’ve invested a lot of time into. It’s been a great learning experience for us. We’ve also hit some limitations delivering our customers the components that they really want.

Firemonkey is a great idea. It has a ton of promise. But the general approach it takes is a bit problematic for anything more than a simple derivative control. Firemonkey controls are pretty much 100% written from the ground up in Delphi. All calls to the native OS are abstracted, hidden and meant to be forgotten. This means that if your component needs to deviate too much from the standard Firemonkey created behavior, you must write it all yourself, from the ground up. This could include everything from caret position, text wrapping and rendering, window scrolling and completely painting the component.

So for example, if you are writing a TRichEdit, not only do you have to write a parser to parse rich text strings into something that can be represented on the screen, but you have to write the code that draws the text to the screen, in the right font, color and position. And then of course you can’t forget other standard Rich Text features like lists, tables, embedded images, etc. You have to handle all of this yourself, parsing, measuring, wrapping, drawing, scrolling, editing, etc.

And remember that Firemonkey is cross platform. This means that you must take care that your RichEdit looks like a native control on each of the platforms you hope to support. This means building styles and/or custom draw routines, one for each platform.

With the VCL, Borland never had to worry about all of this because they just wrote a wrapper around the Windows API Rich Edit control. So why didn’t Embarcadero do the same thing with Firemonkey? Because Firemonkey also needs to compile for OS X and the Windows API Rich Edit control doesn’t exist there. OS X does have a comparable (though not interface compatible) control called the NSTextView that does support Rich Text. And that’s where NakeyMonkey comes in.

NakeyMonkey will include a TNMXRichEdit control which will use the Windows API Rich Edit Control when compiled for Windows and the NSTextView when compiled for OS X. (It’s a very similar approach to what GUI frameworks like wxWidgets uses.) This TNMXRichEdit control can be used on the Firemonkey form along side any other Firemonkey control and work fine with its other cool features like animations and filters.

This approach reminds me of the Kylix CLX library that also wrapped native Windows and Linux controls inside a VCL like component library. With hindsight the CLX library has come to be regarded as a bit of a square peg, round hole type solution. Why do you think NakeyMonkey will succeed where CLX failed?

Actually, part of the problem with CLX is that it specifically did not do that.  Rater than communicating natively on each operating system with the API, CLX wrapped the third party qt library dll.

The qt dll was a flattened version of a C++ library. Every time qt was fixed or updated, a new dll had to be generated, often needing interface updates to conform to the qt changes.  This vastly increased the difficulty in getting out updates to the CLX library and made it quite dependent on the release cycle of this third party library.  In addition CLX apps required this rather large dll to be distributed with your applications.
When I considered how to approach NakeyMonkey I thought about doing something similar to CLX but around the wxWidgets library, which is technically much more native than qt in implementation and feels more natural in use.  But the conclusion that I came to is that most of the limitations and irritations that came with CLX would persist if I took this approach.

You mention support for Windows and OSX on your NakeyMonkey KickStarter project page. What about iOS?

We intend to support all Firemonkey platforms in the future, but the release promise for the Kickstarter project is limited to Windows and OS X.  To be honest, the iOS support in XE2 is a bit limiting due to the dependence on FPC.  Embarcadero is reportedly working on a native compiler for iOS in a future release that supports all of the delphi compiler features.  iOS support in NakeyMonkey will probably follow that.