On 2016-07-01 11:49, Terence Heaford wrote:
I think I understand, a native field for iOS (plus other mobile
platforms) is a stretch goal.
Well, actually, the 'stretch goal' (like all of stretches for Infinite
LiveCode) are fully documented examples how to 'do that kind of thing'
with Infinite LiveCode - of course, you also get a well-written, fully
functional feature too.
I will have to roll my own in LCB (when available for this) or wait
for LiveCode to require to do it via a stretch goal?
I'm minded of a well-known proverb:
"Give a man a fish and you feed him for a day; teach a man to fish
and you feed him for a lifetime"
Which isn't me trying to patronising or glib, but is a succinct way to
express our approach with LCB. The logic being that the more that can be
done without touching C++ at all, the more people will be able to make
LiveCode 'do more'.
LiveCode Builder is not LiveCode Script, but it definitely sits in the
same family. It is more strict, and has richer typing - which is
precisely what you need when you want to write robust components which
might need to hook in foreign APIs. Furthermore, as LCB evolves we'll
add more ways you can extend LiveCode Script in more natural ways
syntax-wise.
Our main focus right now (beyond continuing improvements to LiveCode 8
as a whole) is getting Infinite LiveCode finished not only so that it
opens up using Builder to a much wider audience, but also so the core
dev team can use Builder to implement engine functionality. Not only
should help speed up the pace of development for OS-related features,
but also mean that the code for them is in a much more accessible form
for contribution from third-parties.
The latter point here is particularly pertinent to the Infinite LiveCode
campaign - the stretch goals are not 'just feature additions' they will
be documented examples of how to use LiveCode Builder to implement those
kinds of features.
To give an example, Monte recently posted this enhancement request:
http://quality.livecode.com/show_bug.cgi?id=17874
Right now, this feature *could* be added as an external - the
information about the 'focused screen' on both Mac and Windows is fully
available without any state from the engine. However, writing an
external (particularly a cross-platform one) takes quite a lot of time
as you have to setup the projects, write the glue code, write the
functionality and then compile and test the external.
In contrast, this ability can actually be written in LCB *right now*
although it does require more technical understanding of how the OS APIs
work on the specific platforms, and knowledge of lower-level language
formalisms than is appropriate for the goals of the language. But then,
that is the goal of Infinite LiveCode: to make it as simple as we can
possibly make it to call foreign APIs.
The following took me about 20 mins end to end to write, and use in the
IDE via the extension builder:
//////////
library com.livecode.examples.focused_screen
use com.livecode.foreign
type ObjcId is Pointer
type ObjcSel is Pointer
type ObjcClass is ObjcId
----------
foreign handler _objc_getClass(in pName as ZStringUTF8) returns ObjcId
binds to "libobjc.dylib>objc_getClass"
foreign handler _sel_registerName(in pName as ZStringUTF8) returns
ObjcSel binds to "libobjc.dylib>sel_registerName"
foreign handler _objc_msgSend_id_v(in pSelf as ObjcId, in pSel as
ObjcSel) returns ObjcId binds to "libobjc.dylib>objc_msgSend"
foreign handler _objc_msgSend_int_id(in pSelf as ObjcId, in pSel as
ObjcSel, in pArg as ObjcId) returns UIntSize binds to
"libobjc.dylib>objc_msgSend"
----------
type NSArray is ObjcId
type NSScreen is ObjcId
handler NSScreenScreens() returns NSArray
return _objc_msgSend_id_v(_objc_getClass("NSScreen"),
_sel_registerName("screens"))
end handler
handler NSScreenMainScreen() returns NSScreen
return _objc_msgSend_id_v(_objc_getClass("NSScreen"),
_sel_registerName("mainScreen"))
end handler
handler NSArrayIndexOfObject(in pArray as NSArray, in pObject as ObjcId)
returns Integer
return _objc_msgSend_int_id(pArray,
_sel_registerName("indexOfObject:"), pObject)
end handler
handler mac_focusedScreen() returns Integer
return NSArrayIndexOfObject(NSScreenScreens(), NSScreenMainScreen())
+ 1
end handler
----------
public handler focusedScreen() returns Integer
return mac_focusedScreen()
end handler
end library
//////////
I probably wouldn't have even got as far as setting up the Xcode project
and the structure you need for C++ projects in that time - let alone
write the C++ code, compile it, make it load into the IDE and test it.
Then, if I wanted to add Windows, I'd have to setup a different project,
split up the code so that it conditionally compiled based on platform
and use two machines (VMs) to compile the external using different C++
IDEs. Adding Windows support in LCB, however, would be a case of adding
the code to the same file and checking the platform to see which
implementation to use (mac_focusedScreen() or win_focusedScreen()).
Furthermore, I can do that on one machine, and just use a windows
machine/VM to test that it works in the LiveCode IDE via the extension
builder. (Also, critically I did to know how to program in C++ nor how
to use C++ IDEs to do the above!).
So, anyway, I cannot answer you question on 'how long you might have to
wait' for 'native controls' for Mac - all I can say is that with
LiveCode Builder and Infinite LiveCode, you should have to wait a great
deal less time than you would have done without them.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
