Hints of Cocoa

[LCMark]

For the last couple of weeks or so, I've been working a fair bit on re-porting the Mac engine to use Cocoa - the sum of my efforts so far can be found in my livecode repo as 'feature-cocoa'. I had hoped to get a little further along before Christmas, but as that is fast approaching I figured I might as well push what I've done so far as a point of interest as much as anything else.

Before anyone gets too excited, the branch does come with a hefty *this is no way near complete* warning (to use a colloquialism, it is currently 'as rough as a badger's ass'). Indeed I think it best to class it as 'exploratory' at the moment. That being said, I do hope it will go quite rapidly from exploratory to usable after the Christmas break.

So, the branch currently compiles, and launches. Windows open and render, and mouse events generally work (although co-ords are still a topsy-turvy in a couple of places). The menubar works to a certain degree, although accelerators/shortcuts are not yet implemented. The ask/answer dialogs certainly open, however, I've not actually touched that code yet so what happens after they open is not something I've explored. Drag-Drop does not work, I doubt the clipboard works and printing is very unlikely to work. Text input works to a certain degree (with a modicum of IME integration) although this is not complete and non-character key input definitely does not work. Modal dialogs, sheets and drawers do not work - they are all created as normal windows. It also requires 10.6 at the moment (the earliest version we will target when finished will be 10.5, however there are some Cocoa APIs we need to emulate in 10.5 as they were introduced in 10.6 and I've deferred this work for now).

It goes without saying that Cocoa is quite a different beast from Carbon/Classic (despite the fact Cocoa does appear to sit on top of Carbon!) and thus far the reworking has resulted in less (and simpler) code needed to replace what was there before which is nice. However, this is likely to come with a price which I'm not sure I will be able to avoid - it is very likely that Mac externals that use system APIs will need changes in a Cocoa engine. Essentially, it would seem that we will have to move the Mac desktop engine to a twin (co-operative) thread model in order to ensure a reasonable level of robustness - Cocoa places similar demands on its level of control over things as iOS does and various actions (such as resizing stacks, and preparing menus for display) have to be done in direct response to the OS message rather than being able to defer them until the engine is ready to action them (under Carbon/Classic, you had a good bit more control over when such things occurred - Cocoa likes to do it for itself in the way it wishes). Anyway, more information about this will appear in due course after I've exhausted any possible work-arounds for this. [ Moving all platforms to the twin-thread model is definitely something that is on the internal roadmap, I had just hoped we could avoid it for now! ].

[trevordevore]

Thanks for this Mark. I'm really looking forward to playing with this over the break and seeing how this progresses!

[[-hh]]

..........

[monte]

Cocotron is a tool chain and libraries allowing you to cross compile a cocoa app to windows. LiveCode has it's own per platform abstractions to use a native api where required. So Cocoa would be Mac only although it may enable a bit more code sharing with iOS than we have at present.

[trevordevore]

Mark - I played around with the Cocoa build over the break. It was nice to see windows without the resize handle and that could be resized from all sides. Will you be posting updates to the same github repo as it progresses?

[LCMark]

@trevordevore: Yes - as more work is done on the cocoa port I'll push the changes to that branch.

@-hh: As @monte says, the engine already uses native APIs on all the platforms we support so having a cocotron version at first sight doesn't seem to have much value. The other aspect here is that the Mac port is definitely Mac and not just Cocoa - there are various things the engine uses which are not part of Cocoa (because the domain of Cocoa doesn't cover them, or only covered them in recent versions of OS X), and thus are Mac-specific.

[trevordevore]

With the latest changes that Mark pushed I was able to run one of my apps in the feature-cocoa branch! Looks like you are making lots of progress!

[LCMark]

@trevordevore: I've done a fair bit more on this in the last few days...

• Basic (non-IME) text input now works
• Menu accelerators are displayed and work
• Blocking waits that poll for a condition change work
• the mouse / the mouseClick work
• Getting and setting the mouseLoc works
• mouseDrag is now sent appropriately
• Windows now layer slightly more correctly
• Cursor setting and hiding now works

I'm currently in the middle of sorting out drag-drop and pasteboards (and thus as a corollary the clipboard).

[trevordevore]

I've been watching and testing

[tellboy]

Hi runrevmark,

I am not a long time user of LiveCode but rather have tried it in the past but as a Mac development environment was disappointed with the emulated controls so at the time did not pursue it further.

Recently with LC going open source and one of the Kickstarter goals being a Cocoa port LC again grabbed my attention and I have secured a copy of the Community Edition to explore further.

I have noted that the Cocoa port now seems to be bubbling to the surface and I have tried to find out RunRev's intentions with regard to this port.

I have searched high and low for a statement from RunRev as to what this "Port" will consist of and without any success.

Hence my post here is to ask for details of what the port will consist of.

So, to ask specific but not exhaustive questions and in no particular order.

1. Will native Cocoa controls replace the LC emulated versions?

2. Will NSTableView be available as a LC Control?

3. I presume events will be those generated by Cocoa and not Carbon?

4. I assume as LC is having a new graphics engine that NSBezierPath will not be available?

5. Will images be generated using NSViews/NSImage or LC’s new graphics engine?

6. Will Fields be based on NSTextFields?

7. Will NSDatePicker be available?

8. Will NSLevelIndicator be available?

9. Will NSTimer be available?

10. Will NSToolbar be available?

11. I assume NSMenu/NSMenuItem will be the basis of menus?

12. Will NSWebView be available?

13. Will QTKit be available?

14. Will PDFView be available?

15. Will access to all the API’s of Cocoa when building externals be available?

Is there a timeframe for completing the port and what is it?

[LCMark]

@tellboy:

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:

• 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).

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.

[tellboy]

Thank you for your reply.

All the best

Terry

[Mag]

As a developer of applications for the Mac, I think that what it is really miss in current version of LC are:

1. Toolbars (each application for Mac has one) and
2. In-App-Purchase (the dominant model of distribution)

I don't know if thanks to the Cocoa porting these two gaps will be filled. I hope so.

[Kangaroo SW]

@runrevmark

> controls will still be emulated.....?

Hello Mark

Why is it that controls will be still emulated in the Cocoa version of LiveCode.
To have naturally controls was the main reason for me to put money into the
Kickstarter initiative.

I don't only want a 64 bit architecture under the hood (which we can not see), I want
to be able to produce Mac apps which look and behave like apps which have been
created with Xcode. I think this is not asked to much, LiveCode is a Programming
environment to produce apps for many platforms, also for OSX.
I was hoping with the Cocoa version we would get all the modern features
and also the modern look for e.g. controls.

Emulated controls from LiveCode, specially buttons do not look like real OSX buttons !

Reading your post makes me very, very sad, all my hopes are gone, I hope I am
wrong here and I misunderstand your post...

Please explain why this is not possible !

Regards
Rolf

[John]

@runrevmark:

Thanks for providing some insight into what is happening. I am sure everyone is hoping that apps produced in LiveCode will be indistinguishable from those produced in something like Xcode. The fear is that the emulated controls will miss some of the appearance and behaviors we have come to expect in native apps. I know that is a sore spot for apps currently produced in LiveCode. My particular concern goes to text fields. Having what has become normal behavior, such as spell checking, is missed by many users. Do you think the emulation will be good enough to convince all users that they are dealing with a native app?

Thanks,
John