[DUG] Delphi Update

[Jolyon Smith]

@David

I don't have specific technical issues with FireMonkey as such, just a
general feeling that it's too niche in an already niche area.

When I am developing code for OS X I am going to run into problems that I
need to solve and areas of the Cocoa framework that I need to learn about.
 The bast majority of samples and other sources of assistance out there
will be assuming "native" Cocoa development, and access to native
facilities in the framework.  There will be precious few such sources of
assistance that can be directly applied to FireMonkey code that aren't
written specifically with FireMonkey in mind.

Things like "Synchronise" in multi-threaded code for example.

FireMonkey incorporates the same complicated and potentially fragile
Synchronise mechanism that the VCL is hobbled by, but both Windows and OS X
have native mechanisms for ensuring that code is performed on the main
application thread.  FireMonkey doesn't use either of those mechanisms on
Windows or OS X.

On Windows, I have my own "native" Synchronise implementation (create a
form in the main thread and send it messages to be processed simply as part
of the message queue - much simpler, more lightweight and more reliable
than the VCL "Synchronise"mechanism).

On OS X the equivalent would be even more simple:  just invoke
"performSelectorOnMainThread", but as far as I have been able to tell,
there is quite simply no way to get at or utilise this mechanism from
Delphi.


To an extent this is a separate question from whether or not a generic,
non-platform specific GUI layer was the preferable/more correct choice
rather than creating a visual controls framework specific for each
platform, but equally a non-platform bound approach intrinsically favours
that generic solution since platform binding in the GUI Controls typically
necessitates a much closer affinity to the underlying platform.  In the
case of the likes of OS X that means the Cocoa runtime.

Compare and contrast the two approaches to OS X support undertaken in FPC

First, a runtime "bridge" between the FPC runtime and the underlying
platform runtime:

http://wiki.freepascal.org/PasCocoa#The_information_on_this_page_is_legacy_and_only_available_for_historical_purposes._Please_see_FPC_PasCocoa_for_current_information
.

This first approach will be very familiar to anyone who has done any OS X
coding in Delphi, with or without FireMonkey.

Now look at what replaced that approach:

http://wiki.freepascal.org/FPC_PasCocoa

i.e. Language extensions that bring the platform runtime and concepts right
into the language, in exactly the same way that the "message" and
"automated" keywords do/did so successfully on Windows (and in fact, in FPC
they managed to re-purpose that "message" keyword itself!).


Android ... ?

>From the little that I have experimented with Android so far, I simply
cannot see how they can extend the FireMonkey and platform bridge approach
to Android at all successfully, never mind emitting the write code from the
compiler back end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20111115/6143bbb3/attachment-0001.html