There’s lots been going on at RunRev lately development-wise. Maintenance on the 6.6 cycle has been trundling along, 7.0 with its Unicode support is rapidly maturing and in between these two things sits the project that has been my main focus for the last few months – 6.7.
The main goal of 6.7 is to rework the Mac-specific parts of the engine to use the Cocoa framework rather than the (now deprecated, and aging!) Carbon / Classic frameworks. Not only will this allow LiveCode apps to be sandboxed (there are numerous bugs in Mac’s implementation of sandboxing for Carbon apps) and thus submitted to the Mac AppStore once again but it also means that things like revBrowser work much better as the browser control can be embedded directly in the stack window.
One of the most challenging parts of porting the engine to use Cocoa has been (as far as possible!) to retain identical functionality as before. Cocoa is a very high-level framework and as such likes to do things in a very specific way. Given that LiveCode is also a very high-level framework there is a certain amount of ‘creative coding’ required to bend Cocoa around to LiveCode’s way of thinking.
For example, Cocoa will not send continuous ‘windowMoved’ messages (unlike Carbon), you only get periodic updates when the user pauses the movement. This did cause a bit of consternation, but after some googling, some hair pulling and a nifty use of an auxiliary thread and window server interrogation, LiveCode can still enjoy appropriate moveStack messages (you can see the patch for that here https://github.com/runrev/livecode/pull/613).
All-in-all though, the transition to Cocoa has been relatively smooth – a cleaner, more well-defined separation between the platform-specific part of the engine and the rest is emerging and we’re approaching parity with the non-Cocoa feature set.
Anyway I’d better get back to my 6.7 bug fix list – we’re hoping to get 6.7-dp-3 ready soon which will hopefully be the last before we start the RC cycle!
11 comments
Join the conversationDevin Asay - April 23, 2014
Will the transition to Cocoa eventually lead to the use of true native controls on OS X, or will control look and feel continue to be emulated?
Jeffrey Piestrak - April 23, 2014
Jeffrey Piestrak liked this on Facebook.
doobox - April 23, 2014
RT @runrev: From Cocoa with Love: There’s lots been going on at RunRev lately development-wise. Maintenance on the 6.6… http://t.co/bNfXi…
Faber Muñoz Perez - April 23, 2014
Faber Muñoz Perez liked this on Facebook.
Theo Heselmans - April 23, 2014
Same question, but for iOS.
Or is this part of (future) themes (and if so, when)?
Dar - April 23, 2014
Thanks!
Edu_Techie - April 23, 2014
RT @runrev: From Cocoa with Love: There’s lots been going on at RunRev lately development-wise. Maintenance on the 6.6… http://t.co/bNfXi…
Paul Dupuis - April 24, 2014
Paul Dupuis liked this on Facebook.
Yoshiaki Amano - April 24, 2014
Yoshiaki Amano liked this on Facebook.
Rob - April 29, 2014
Hi Mark,
When you say “revBrowser work much better as the browser control can be embedded directly in the stack window” does that imply that other objects can be layered above it now?
Thanks,
Rob
Mark Waddingham - May 1, 2014
To answer all three questions at once (well, together anyway)…
Eventually I think we’d all like to see the ability to be able to use native platform controls in LiveCode – this would most likely happen by defining a slightly more specific and simpler set of controls which can be mapped and implemented using the native controls. Of course, if you are writing an app for just a single target platform then you’d probably want access to the full depth of the native controls – you could have that of course, but at the price of any sort of portability.
The main architectural issue to overcome is to allow LiveCode controls to interleave with Native controls – at the moment the LiveCode controls on a card sit behind all the native controls (whether this be revBrowser on Mac, or any of the mobileControl type controls on iOS/Android). Again, you pay a price for this, no platforms allow the range of compositing options for the controls which LiveCode does (in terms of ink and bitmap effects) but then, the types of app which need this kind of thing would probably be happy with such features only being available within (say) groups of LiveCode controls (such as a graphic editing application where the native controls would sit around a canvas.
At this point we have an idea for how to change the architecture of the engine to allow the interleaving but it’s a while away from any sort of implementation. After that point though you’d essentially be able to choose between using all native controls directly (i.e. for a single platform), abstracted native controls (less functionality but cross-platform), all LiveCode controls, or a mixture of the two with restrictions on how the controls composite together in the stack.