New Delphi for OS X and iPhone

[qdos]

Last time i was here i posted a link that a new Delphi was comming with support for OS X.
I was called everything from "troll" to "liar".

How about now then?

http://delphimax.wordpress.com/2011/08/04/delphi-64bit-os-x-and-iphone-native/

Told you so

[mica]

with FPC for iOS
(but i think the Firemonkey (VG/DXScene) part is great.It´s a pity that DXScene is now lost for FPC/Lazarus)

[qdos]

Yup, fpc for iOS. I actually wrote a proposal for that roughly 9 months ago.
But OS X is good - and it was what i wrote about earlier here around xmas.
Not everyone would lie about something like this.

[JD]

This is welcome news because it means Object Pascal will generate even more interest in the developer community. Embarcadero's reentry into the cross-platform market shows how important the market will be in the years to come. I believe Lazarus/FreePascal will have a role to play in that market.

However, if I understand what Embarcadero is trying to do, this means

a) VCL will be used for Win32/Win64 development
b) Firemonkey will be used for Mac/Linux development

So it might be necessary to maintain two different code bases for cross platform development in Delphi ????

In the long run, won't that lead to two competing groups: the VCL group vs the FireMonkey group?

Personally, I prefer the Lazarus/FreePascal strategy - "Write Once, Compile Anywhere". 

[nicke85]

Next time qdos if you have topic like this please post in other category..this one is for third party elements..
Thank you..

[BigChimp]

However, if I understand what Embarcadero is trying to do, this means

a) VCL will be used for Win32/Win64 development
b) Firemonkey will be used for Mac/Linux development

So it might be necessary to maintain two different code bases for cross platform development in Delphi ????

In the long run, won't that lead to two competing groups: the VCL group vs the FireMonkey group?

I suspect it will be different: new applications on all platforms written using FireMonkey to keep up with flashy new GUIs. Old apps will use VCL...

[JD]

From the Lazarus Support website
http://www.lazarussupport.com/lazarus/weblog/delphi-uses-free-pascal-for-ipad-support

Delphi uses Free Pascal for their iPad support
August 6, 2011

Finally there's some more news about the new Delphi version, which will be called Delphi XE2. As expected, there is no VCL support for OS/X. All existing applications have to be re-written using the new Firemonkey library. So Lazarus will remain the only VCL-compatible option to develop for OS/X.

But what really was a surprise, is to see that Embarcadero also supports Firemonkey on the iPad. But that means they need to have an ARM-compiler. This mystery was solved by a comment from Michael Swindel. Embarcadero will uses the Free Pascal compiler for it's iPad support.

Patches are welcome
This is very good news. It does show that even Embarcadero consider Free Pascal to be a mature, stable compiler. Above that due to Free Pascal's gpl-license they are not allowed to alter the compiler without publishing the source-code. So maybe we will see some Free Pascal patches send in by Embarcadero employees. They are really welcome!

So FireMonkey will replace VCL? All old apps will need to be rewritten? Thank God I discovered Lazarus.

Michael Swindel's comment: http://delphimax.wordpress.com/2011/08/04/delphi-64bit-os-x-and-iphone-native/#comment-749

@Jon: Thanks and very happy to be “told so” This is the just the first step with FireMonkey, we exciting plans for FM beyond XE2. Re FPC, we will be coming out with a Delphi ARM compiler at some point, but we’re appreciative that FPC is available today for ARM/iOS and we were able to leverage to get FireMonkey to iOS.

I'm also looking forward to seeing Embacadero contribute patches to the FPC compiler source code. 

[avra]

Last time i was here...

I am really sorry to hear that you made such a long pause...

[BigChimp]

So FireMonkey will replace VCL? All old apps will need to be rewritten? Thank God I discovered Lazarus.

Not if you read the information out there. VCL still works. Even for Win64. Just not for IOS/OSX...

[MSwindell]

So FireMonkey will replace VCL? All old apps will need to be rewritten? Thank God I discovered Lazarus.

Old VCL apps can stay VCL. We're moving VCL fwd as well in parallel. It's getting Styles - a skinning/themeing system, LiveBindings - a new data binding system, full 64bit support (yes, I know finally and FPC has had for a long time), Datasnap is getting mobile client connectors for native mobile dev tools like xcode, eclipse, and visual studio - for iOS, Blackberry, Android, and Windows Phone... and bunches of more stuff. VCL is for Windows applications only. Firemonkey is for rich vector/3d applications and supports Windows, Mac, and iOS today and more on the way. It's a different application focus than VCL. Where as VCL is designed completely around the Windows APIs and OS, Firemonkey is designed around rich GPU based HD (vector) and 3D UIs and is available for multiple platforms.

forward to seeing Embacadero contribute patches to the FPC compiler source code. 

Would be happy to consider if we find/fix anything of value to FPC.

[MSwindell]

with FPC for iOS
(but i think the Firemonkey (VG/DXScene) part is great.It´s a pity that DXScene is now lost for FPC/Lazarus)

Not necessarily. While it's not planned today, FPC/Lazarus support for FM beyond iOS isn't off the table either. It's not a "rule" that we couldn't or wouldn't support other dev environments like Lazarus/FPC. One thing to keep in mind is that FM isn't DX/VGScene - it has many of the DX/VG ideas, but it's really a new framework/platform. It's much more comprehensive (ie DX/VG ran on top of VCL or FCL where as FM is a complete platform unto itself) and complete as an application platform. It is a re-invention of the DX/VG concepts and is really a "next-generation" of the DX/VGScene tech and concepts from a component/UI perspective. For us it really comes down to time/sched. We have a LOT on our plate over the next few years. I would consider some type of FM support or product for Lazarus/FPC if we could fit our time/sched. Right now it's not something in the sched/Roadmap. But I would certainly not have a problem with FM being used in Laz/FPC if we were able to provide it and support it. For now, our roadmap is FM in Delphi and C++Builder. But we'll keep in touch and let you know if this changes.

[MSwindell]

However, if I understand what Embarcadero is trying to do, this means

a) VCL will be used for Win32/Win64 development
b) Firemonkey will be used for Mac/Linux development

So it might be necessary to maintain two different code bases for cross platform development in Delphi ????

Close, but not exactly.

a) VCL will be used for Windows-only development and traditional Win UIs
b) Firemonkey will be used for rich vector/3d UI applications for Win/Mac/Phones/Tablets/Kiosks, Linux and others to come.

You can do traditional Win UIs in FM, but if that is all you are doing and do not require other platforms then VCL will be fine for a long time. We are continuing to evolve and enhance VCL for Windows development,and have no plans to slow or stop. But certainly FM is where many next-gen UX things are happening. Some really exciting in the pipeline for FM.

[mica]

Not necessarily. While it's not planned today, FPC/Lazarus support for FM beyond iOS isn't off the table either.

The message well I hear, my faith alone is weak

[avra]

@MSwindell:
FireMonkey - why such a name? It reminds me on some browser plugin. I would never relate it to next gen UI...

[felipemdc]

wow, this is historic, people from Embarcadero in our forum =D

Some things which I'd like to suggest, which would be excellent if Embarcadero did =D At least I would be very happy:

1> Say that you use "Object Pascal" not the "Delphi Language"

2> Implement language features taking into account if FPC has already implemented it. What is powerful about C is that you can more or less easily write code which can go in any compiler. Now in Object Pascal there are only 2 major compilers, so even if we lack official standards, which would be the ideal, one can very easily take a snap to see what the other did to make sure we are going in a more compatible direction, as opposed to incompatible. For example in the cases of PtrInt vs IntPtr, generics, etc.

let me know what you think about the suggestions