FireMonkey does not mimic native controls perfectly, especially on OSX. This is simply because all its controls are implemented fully in FireMonkey, and so all behaviour has to be coded - and it is very unlikely to ever get an implementation that is indistinguishable from the platform-native controls. Platform-native is important.
But, what if there was a library of native FireMonkey controls, using Cocoa on OSX and the WinAPI - like the VCL - on Windows?
Jason Southwell has started a project on KickStarter to implement native controls for FireMonkey, under the name 'NakeyMonkey'. He has a goal of $20,000, but with seven days to go only $7,642 has been pledged.
This project is just what FireMonkey and cross-platform Delphi and C++ Builder needs. I'm posting since I think it needs more exposure, and more backers - I am worried it may not reach its goal. I read about it a few days ago and thought, 'ah, it'll get funded, I don't need to do anything' - but maybe I do. So:
If you can, please consider backing it too.
Remember, you'll only actually pay if the project reaches the funding goal - if it misses, no-one loses money.
Jason has also added prizes / credits if you pledge more than a certain amount, too, such as getting beta builds, getting a license of the product and a year's support, or two year's support, phone calls with the developers, etc, as extra incentives for funding specific amounts.
On another note: one person has pledged $1500. Whoever that is, you're a generous guy / gal!
Already backed this project!) $105 is not too much IMHO)
ReplyDeleteNon need for this project, Embarcadero is going to do the same....
ReplyDeleteIt looks like the license is valid only for one year.
ReplyDeleteAnd Firemonkey itself isn't the silver bullet for cross development, since nobody talks about linux compiler, android and WinRT for Firemonkey.
So it doesn't look like a very good deal.
Remove the e-mail priority support, make the license be eternal for source code updating, and maybe make it cheaper for people on China, Russia and Brazil (it is where Delphi is still very used, anyway) for this license without priority support. Maybe for USD 50,00 you will find 400 developers to pledge the project.
Then after launch you may rise the price, so this first 400 developers will have the feeling of a good deal. And new customers will pay the price for not believing from start.
Recently DavidI publically stated that Embarcadero itself plans to add native control support to firemonkey. So I think that given that, NakeyMonkey should give Embarcadero 6 months and see what they come up with, rather than attempt to do it externally.
ReplyDeleteW
I just saw that (link for other people: http://www.deltics.co.nz/blog/?p=943 )
DeleteI'm not sure it quite counts as a 'public announcement' - as far as I can tell, it is just a comment on a blog with no other formal announcement anywhere. It will be interesting to hear what form it takes when it's announced.
It does leave this project in limbo somewhat. I hope they provide an update soon.
I think trying to wrap this inside FireMonkey misses the point entirely.
ReplyDeleteFireMonkey isn't what makes Delphi code cross-platform. it's merely a cross-platform UI framework built on top of the already cross-platform language. We already have a way of using native controls on Windows - the VCL.
All we need in addition to what we already have is a way of using native controls on OS X/iOS.
The same concern applies equally to whatever Embarcadero are planning to do/doing with FireMonkey as well.
What they SHOULD be doing is working with Apple to enable them to develop a Delphi Compiler plug-in for Xcode. You only have to look at what the FPC community have managed to achieve, presumably with little/no help from Apple. I am sure that with the resources of a company like Embarcadero behind it, much more could be achieved and Apple might even open Xcode up a little more to make it achievable.
Then again, they may not, but in that case Embarcadero then should set about creating their own OS X IDE for doing OS X development.
I think you're right: we do already have native Windows controls and a separate family of OSX controls would be great. I think they're going for a 'one library, multiple underlying APIs' architecture though, so that you can create one form and use it on multiple OSes. I'm not convinced this is the best approach, although it seems one that will cut down on initial coding work. Instead I think a framework that (a) encouraged separating UI and other code and (b) at the same time made hooking up UI to code very easy, would encourage people to create multiple versions of their UI and hook it up to their backend.
DeleteI disagree about making a plugin for Xcode. The reason is that the Delphi IDE, integrated form designer etc is one of the main selling points / features of Delphi. If you take that away, you just have the language. What value is there in that? You might as well just use FPC.
On the other hand, a Delphi IDE on OSX would be fantastic. Xcode uses a very different style to Delphi, one which I don't especially like sometimes, and I think Delphi on OSX (especially with C++ support, so RAD Studio) might be a lot of fun to use.