The parlous state of Rounded Rectangular buttons - Found word(s) list error in the Text body

[Terence Heaford]

I don’t believe so, controls will still be emulated.

Read this.

http://forums.runrev.com/viewtopic.php?f=66&t=18504

Here is a reply to some questions I raised. The reply is from runrevmark.

All the best

Terry


"Hopefully I can answer your questions...

The 'port to Cocoa' is the transition of the engine from the old Carbon/Classic APIs to the Cocoa API. Graphics will still be done using our cross-platform graphics library and abstractions, and controls will still be emulated - the code we are replacing is the interface between the high-level control set the engine already has, and the platform-specific aspects such as window management and event handling.

The main goal of the Cocoa port is three-fold:
[list=]
[*]To enable embedding of NSView's in LiveCode's windows (this is something you cannot do in the Carbon version - which is why revBrowser is an 'ugly hack' on Mac at the moment).
[*]To enable submission of LiveCode apps to the Mac AppStore (there are certain elements of sandboxing which do not work if you try and use Carbon due to bugs in the OS - in particular file dialogs and menus).
[*]To enable a 64-bit version of the engine (most Carbon APIs are unavailable in 64-bit).
[/list]

The first goal will be to get to (1) - i.e. we have an engine that works exactly as before, but uses Cocoa versions of windows, file dialogs, menus and event handling. At this point, it will be easy enough for externals to do what revBrowser now does in this version - embed an NSView inside a LiveCode window and have things work as expected. i.e. In the first instance, it should be more than feasible for externals to leverage native Cocoa controls.

There is a little more work to do to get to (2) although the majority is covered by (1). As Apple now seem to be rejecting any apps using the QuickTime or QTKit frameworks in the Mac AppStore we need to add a version of the player which uses AVKit on 10.7+ and above. The internals of the player have already been abstracted as part of (1), this shouldn't be too hard to do. It should be noted that the QuickTime usage will be factored out in such a way that Mac AppStore submission should work fine at point (1) - as long as you don't use QuickTime related features (player, sound recording, QT effects).

Finally, getting to (3) will require rewriting some other parts of the Mac specific part of the engine to fully eliminate Carbon/Classic calls. There are still a couple of areas which work fine in a mixed Carbon/Cocoa app - in particular, AppleScript and AppleEvent related code - so they remain untouched at present.

In terms of timescale - phase (1) is the priority as this is the majority of the work needed. We're hoping to have a DP of a version with this work completed coming out quite soon. I'm hoping we'll also get a port to AVKit in that DP cycle too - although it depends on how many issues crop up with the change from Carbon to Cocoa in people's app. Getting to (3) will probably take a while beyond an initial Cocoa release depending on resources and how long it takes to get the initial version of the Cocoa port to stability."



On 1 May 2014, at 19:55, Bob Sneidar <bobsneidar at iotecdigital.com> wrote:

> Isn’t Native Controls what version 7 is going to give us?
> 
> Bob
> 
> On Apr 29, 2014, at 16:02 , Mark Wieder <mwieder at ahsoftware.net<mailto:mwieder at ahsoftware.net>> wrote:
> 
> ...and I'll third it. I'd love to have native controls for whatever
> platform, but I'm not holding my breath for that. I just usually end
> up using images for buttons. No, they don't scale, but they look a
> whole lot better than those flat rounded things.
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode