1. Does anyone know if developing with FireMonkey will be the only way to develop for OSX with XE2?

2. Does anyone know if you will need to compile on a Mac for OSX, or will XE2 cross compile?

I know this will all come out during the world tour, but I'm just trying to get some idea so I can start planning.

1. Yes, I think for now it will be the only way. But you can probably build a native UI for OSX by directly using the API, like you can also develop Win32 applications without using the VCL.
2. XE2 will only be available for Windows, but it will compile for other platforms.

<Mike Dixon> wrote in message news:383833@forums.embarcadero.com...

> 1. Does anyone know if developing with FireMonkey will be
> the only way to develop for OSX with XE2?

Yes.  VCL is intimately tied to Windows.  FireMonkey was introduced to break 
that link.

> 2. Does anyone know if you will need to compile on a
> Mac for OSX, or will XE2 cross compile?

It will cross-compile.  The IDE and compiler will remain Windows-only 
applications, but will produce executables that can run on the target 
platforms.

-- 
Remy Lebeau (TeamB)

On 2011-08-03 13:43:36, Remy Lebeau (TeamB) wrote:

> Yes.  VCL is intimately tied to Windows.  FireMonkey was introduced
> to break that link.

I'm worried about how close to "native" the FireMonkey controls are
going to look and behave.  Every cross platform widget set I've never
seen in use generally has warts that make it immediately obvious that
it's not using the drawing widgets built into the OS.  Some are visual,
some are behavior.

Also, are we going to be able to turn off FireMonkey's lickable shiny
styles and just have applications that look and act like native
applications?

>It will cross-compile. The IDE and compiler will remain Windows-only 
applications, but will produce executables that can run on the target 
platforms.<
Will be able to take existing application and recompile for the Mac?

Bob

Bob McKinnon wrote:

>>It will cross-compile. The IDE and compiler will remain
>>Windows-only
>applications, but will produce executables that can run on the target 
>platforms.<

>Will be able to take existing application and recompile for the Mac?
>
>Bob

Or convert (semi) automaticly a vcl dfm from vcl to mac...

On 2011-08-03 15:56:02, Marius . wrote:

> > Will be able to take existing application and recompile for the Mac?
> Or convert (semi) automaticly a vcl dfm from vcl to mac...

I'm going to go with "not a chance" on both counts.

This will almost certainly involve rebuilding your forms at the least.

On 2011-08-03 14:50:15 -0400, Anthony Frazier <afrazier AT victorptg 
DOT com> said:

> I'm worried about how close to "native" the FireMonkey controls are
> going to look and behave.  Every cross platform widget set I've never
> seen in use generally has warts that make it immediately obvious that
> it's not using the drawing widgets built into the OS.  Some are visual,
> some are behavior.

This will definitely be a concern on OSX.  Mac people are pretty picky 
about how apps look.  If it's visibly not native, there can be 
resistance.  It may not matter for business apps designed for a 
specific client's heterogeneous IT environment, but for mass market 
consumer apps, it will be a problem.

I have just one Java application on my Mac.  I hate using it, but have 
not been able to find a native replacement.

--
Kevin Powick

"Bob McKinnon" <stardate10@hotmail.com> wrote in message
<
> Will be able to take existing application and recompile for the Mac?
>
You won't be able to take an existing VCL app and recompile for the Mac 
because the VCL is very tied to the Win32 API.

You should be able to take a console app and recompile it, but obviously it 
will depend on what specific code you have written and whether it has a 
dependancy on the Win32 API.

From what I gather, if you want an app to target both Windows and Mac, then 
you will have to use the new FireMonkey support that will be introduced with 
XE2. And even then, you will have to be careful as to what units you 
include, as some parts of the RTL have Win32 dependancies.

Who knows, maybe they will include a migration tools to map VCL components 
to FireMonkey components. But I would still expect a fair amount of work 
will need to be done.

Mike

> {quote:title=Bob McKinnon wrote:}{quote}
> Will be able to take existing application and recompile for the Mac?
Depending on what you are doing in the app, maybe (almost never).

Simple things to consider (amongst others):
- file access is a little different ( "/" iso "\" )
- no drives
- menu is setup different (not only at the top of the screen, but also location of items)
- shortcut keys are different (using Function keys is limited)

Have a good look at some apps you know from windows that have been converted to the mac (or made for both platforms) a good example is ms office, they really did a good job in making it a mac app.


Bob

On 08/04/2011 00:43, Remy Lebeau (TeamB) wrote:

> Yes.  VCL is intimately tied to Windows.  FireMonkey was introduced to break
> that link.

Would it integrate with common operating system appearance? Is there any 
screenshot available of how FireMonkey based application would behave on 
MacOS? the screenshot on this article below i guess was targeted as 
Windows application.

http://www.andreanolanusse.com/en/a-little-bit-about-firemonkey-and-delphi-xe2

-Jaimy

Kevin,

>> I'm worried about how close to "native" the FireMonkey controls are
>> going to look and behave.  Every cross platform widget set I've never
>> seen in use generally has warts that make it immediately obvious that
>> it's not using the drawing widgets built into the OS.  Some are visual,
>> some are behavior.
> 
> This will definitely be a concern on OSX.  Mac people are pretty picky
> about how apps look.  If it's visibly not native, there can be
> resistance.  It may not matter for business apps designed for a
> specific client's heterogeneous IT environment, but for mass market
> consumer apps, it will be a problem.
> 
> I have just one Java application on my Mac.  I hate using it, but have
> not been able to find a native replacement.

and the Uncanny Valley makes this worse - the more something tries to 
look native (bit isn't quite) the more awkward it will feel. SO as bad 
as it may be, an app that looks like it was done in Adobe Air will 
usually be *more* acceptable than something that tries really hard to 
look native, but doesn't quite get there 100%.

marc

On 2011-08-05 06:15:56, marc hoffman wrote:

> and the Uncanny Valley makes this worse - the more something tries to 

I've never seen that phrase used in conjunction with UI toolkits, but
it's exactly correct.

> {quote:title=Jaimy Azle wrote:}{quote}
> Would it integrate with common operating system appearance? Is there any 
> screenshot available of how FireMonkey based application would behave on 
> MacOS? the screenshot on this article below i guess was targeted as 
> Windows application.
> 
> http://www.andreanolanusse.com/en/a-little-bit-about-firemonkey-and-delphi-xe2

Neither of those screenshots are specifically Windows applications.  They're the "Dark" and "iOS" styles.

I asked for more information about all this in that thread a couple of days ago, and it's worth reading all the comments.  If you look for the two questions "David M" (that's me) asks and then Andreano and Michael's answers, it's roughly that (a) some screenshots of native-look OSX and Windows will be posted soon, and (b) on OSX windows are Cocoa Windows, the main menu is a Cocoa menu, and controls are custom but render with (mimic?  This wasn't directly answered but was strongly implied) Cocoa styles inc
luding some Apple-only styles.  Everything's blitted using OpenGL.  This seems a decent way to do it IMO.

I suspect styles will be extensible anyway, ie you'll be able to write your own, and as someone who very much wants an exact Cocoa feel in my OSX apps I might actually look into writing my own native style if the built-in one isn't perfect.  (And I mean +perfect+.)  This is very speculative though - until I actually use a copy of it I have no idea if this would be useful or not.  If I do I'll probably open source it, no point in keeping it solely for me!

Cheers,

David