Re: externalPackages
Trevor DeVore wrote: If the externals property is pointing to the property external file on disk, you can make sure the destroyWindow property of the stack is set to true, close the stack, and then open it again. This will attempt to reload the external. That's a helpful tip and I appreciate it, but it also reminds me why I sorely dislike using externals in LiveCode. Coming from a SuperCard background, I'm accustomed to a simpler world where we just import the external file and never have to think about it again - from that moment on it's as good as a library, with its handlers always available whenever the stack is running. The whole loading thang with LC is, IMNSHO, rather FUBAR when compared to any other xTalk. Of all the things that excite me about the Open Language initiative, it's the hope that I can write most of the things I used to use externals for in code that's far simpler and robust to initialize. ;) -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: externalPackages
Hi Richard, Since you come from a SuperCard background could you answer a question for me? I am a registered owner of SuperCard 4.6 and SuperEdit 4.6. The Xtend section allows you to export externals. I contacted SuperCard Support and they said I could use the SuperCard externals in other programs that use externals as long as I abide by the EULA. That is not a problem. I exported a external and tried to use it in Revolution and could not get it to work. The next thing I was going to try is to make a empty external for LiveCode naming it the same as the external I want to use and from SuperCard install it into the resource by changing the type from .bundle to .txt and then change the type back to .bundle. I have done that without making the empty external so I have not actually tried it yet. Is that the proper way to install a SuperCard external in Rev or is it not possible at all to use them in Rev? thanks, John Balgenorth On Aug 13, 2014, at 11:43 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Trevor DeVore wrote: If the externals property is pointing to the property external file on disk, you can make sure the destroyWindow property of the stack is set to true, close the stack, and then open it again. This will attempt to reload the external. That's a helpful tip and I appreciate it, but it also reminds me why I sorely dislike using externals in LiveCode. Coming from a SuperCard background, I'm accustomed to a simpler world where we just import the external file and never have to think about it again - from that moment on it's as good as a library, with its handlers always available whenever the stack is running. The whole loading thang with LC is, IMNSHO, rather FUBAR when compared to any other xTalk. Of all the things that excite me about the Open Language initiative, it's the hope that I can write most of the things I used to use externals for in code that's far simpler and robust to initialize. ;) -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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
Re: externalPackages
JB wrote: Since you come from a SuperCard background could you answer a question for me? I am a registered owner of SuperCard 4.6 and SuperEdit 4.6. The Xtend section allows you to export externals. I contacted SuperCard Support and they said I could use the SuperCard externals in other programs that use externals as long as I abide by the EULA. That is not a problem. I exported a external and tried to use it in Revolution and could not get it to work. The next thing I was going to try is to make a empty external for LiveCode naming it the same as the external I want to use and from SuperCard install it into the resource by changing the type from .bundle to .txt and then change the type back to .bundle. I have done that without making the empty external so I have not actually tried it yet. Is that the proper way to install a SuperCard external in Rev or is it not possible at all to use them in Rev? I'm very familiar with SC externals indeed: I started Fourth World in 1994 primarily as a vendor of SuperCard add-ons, with a catalog of externals written by myself and many others, including one of the current co-owners of SC, Mark Lucas. Even back in those days, not all externals could be used across the various apps that supported the HyperCard externals interface. The SuperCard Internals Toolbox, for example, included many APIs not found in HyperCard, so many of the best SC externals couldn't run in HC (or OMO, or Microphone, or any of the other apps that supported the original HC externals interface). The migration from 68x to PPC compounded the compatibility issue, as has the move from PPC to Intel. Today, even SC itself can only run a subset of all the externals ever written for it; I don't think anything I'd ever published can be run with SC today. With LC, the externals API is very different, so even if you had an Intel-compatible external and only needed to run it on Mac, it would still need to be recompiled to use the LiveCode externals APIs. Fortunately, at least for the work I do, aside from the database externals included with LC I rarely use any at all. Most of the things I'd written externals for in SC are included in LiveCode itself. Which externals from Xtend do you need? I'll bet there are LiveCode equivalents for most of them, or easily written using LiveCode itself. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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
Re: externalPackages
Thanks for the info. I don’t really need any of them I was just trying to use them if it was possible. Your information shows it is not possible and therefore I won’t waste my time on it. I am surprised that as long as LiveCode has been around there are not more externals available. If you have developed externals for LiveCode why not sell them like was done for HyperCard? That would be better than the Standard Library at least for your pocket book and might encourage others to earn a few dollars too. It would be kind of like fast food marketing. Usually when you find one fast food place others are in the general area and might even be across the street or next door. They have found that having fast food places by each other does not take business away from the first fast food place to be located there and instead it actually increases the business for all fast food places in the area. Just a thought since I have not seen anyone marketing externals for LiveCode. John Balgenorth On Aug 13, 2014, at 1:02 PM, Richard Gaskin ambassa...@fourthworld.com wrote: JB wrote: Since you come from a SuperCard background could you answer a question for me? I am a registered owner of SuperCard 4.6 and SuperEdit 4.6. The Xtend section allows you to export externals. I contacted SuperCard Support and they said I could use the SuperCard externals in other programs that use externals as long as I abide by the EULA. That is not a problem. I exported a external and tried to use it in Revolution and could not get it to work. The next thing I was going to try is to make a empty external for LiveCode naming it the same as the external I want to use and from SuperCard install it into the resource by changing the type from .bundle to .txt and then change the type back to .bundle. I have done that without making the empty external so I have not actually tried it yet. Is that the proper way to install a SuperCard external in Rev or is it not possible at all to use them in Rev? I'm very familiar with SC externals indeed: I started Fourth World in 1994 primarily as a vendor of SuperCard add-ons, with a catalog of externals written by myself and many others, including one of the current co-owners of SC, Mark Lucas. Even back in those days, not all externals could be used across the various apps that supported the HyperCard externals interface. The SuperCard Internals Toolbox, for example, included many APIs not found in HyperCard, so many of the best SC externals couldn't run in HC (or OMO, or Microphone, or any of the other apps that supported the original HC externals interface). The migration from 68x to PPC compounded the compatibility issue, as has the move from PPC to Intel. Today, even SC itself can only run a subset of all the externals ever written for it; I don't think anything I'd ever published can be run with SC today. With LC, the externals API is very different, so even if you had an Intel-compatible external and only needed to run it on Mac, it would still need to be recompiled to use the LiveCode externals APIs. Fortunately, at least for the work I do, aside from the database externals included with LC I rarely use any at all. Most of the things I'd written externals for in SC are included in LiveCode itself. Which externals from Xtend do you need? I'll bet there are LiveCode equivalents for most of them, or easily written using LiveCode itself. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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 ___ 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
Re: externalPackages
JB wrote: I am surprised that as long as LiveCode has been around there are not more externals available. If you have developed externals for LiveCode why not sell them like was done for HyperCard? I don't need 'em. As I wrote earlier: ...aside from the database externals included with LC I rarely use any at all. Most of the things I'd written externals for in SC are included in LiveCode itself. For example, here's a list of externals I used to sell in a collection for SuperCard called scX, with their built-in LiveCode equivalents: - AskColor LiveCode: answer color - CalendarField LiveCode: we have no one-liner for making an ASCII calendar layout, but it can be obtained in a one-line call to the shell on OS X and Linux, and with LC's weekdayNames and other features takes only a few minutes to write - but who needs an ASCII calendar? I originally wrote that because I needed one for an app and doing it in script was slow - that's very rarely a problem in LC. - Camera LiveCode: export snapshot - ClipToPICTRes LiveCode: LC supports many resource fork operations, but since that fork is marked for deprecation there's little point in using them, and being Mac-specific they offer nothing for the other 90% of the computing world. - CmdPeriod LiveCode: commandKeyDown - DragThisWindow LiveCode: mouseMove - DrawIcon LiveCode: see note on resource fork above. - GetFolder LiveCode: answer folder (much more flexible in LC) - GetIndString LiveCode: see note on resource fork above. - GetVersion LiveCode: see note on resource fork above, thought it's worth noting that I now store version info in custom properties, which can be used for the sorts of things we used to use the old Mac res fork for, but are much more flexible, more robust, and available on all platforms. - GrowThisWindow LiveCode: mouseMove - InjectPPAT LiveCode: backgroundPattern property - IntersectRect LiveCode: within - LineMatch LiveCode: lineOffset - ListFonts LiveCode: the fontnames - ListRes LiveCode: getResources - MonitorRects LiveCode: the working screenRects - MoveFile LiveCode: rename file - NewFolder LiveCode: create folder - PixelColor LiveCode: screenMouseLoc with mouseColor - PopList LiveCode: popup - RestartMac LiveCode: one-line call to shell - SetColorCursor LiveCode: all cursors can be color - ShowProgress LiveCode: built-in progress object - ShutDownMac LiveCode: one-line call to shell - SnapDragon LiveCode: built-in grid property - xFileType LiveCode: the detailed files - xPrefs LiveCode: specialFolderPath Even the externals others wrote that I published for SC are easily done in native LiveCode, from arrays to lists to statistical functions, text-to-speech, and much more - easier to work with right in the scripting language, and unlike externals can be used on multiple platforms. Just a thought since I have not seen anyone marketing externals for LiveCode. Check out the LiveCode Market Place: https://livecode.com/store/marketplace/ There are several dozen add-on packages there, and many more throughout the community. It's just that with LiveCode's very broad capabilities, relatively few add-ons are externals per so, with many add-ons being libraries, custom controls, and other forms. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: externalPackages
I see your point. Changing the subject a little bit you mentioned LiveCode is going to improve things so you can actually do more external type code from within LiveCode. Are they going to be using Apples new programming language Swift at all? John Balgenorth On Aug 13, 2014, at 2:10 PM, Richard Gaskin ambassa...@fourthworld.com wrote: JB wrote: I am surprised that as long as LiveCode has been around there are not more externals available. If you have developed externals for LiveCode why not sell them like was done for HyperCard? I don't need 'em. As I wrote earlier: ...aside from the database externals included with LC I rarely use any at all. Most of the things I'd written externals for in SC are included in LiveCode itself. For example, here's a list of externals I used to sell in a collection for SuperCard called scX, with their built-in LiveCode equivalents: - AskColor LiveCode: answer color - CalendarField LiveCode: we have no one-liner for making an ASCII calendar layout, but it can be obtained in a one-line call to the shell on OS X and Linux, and with LC's weekdayNames and other features takes only a few minutes to write - but who needs an ASCII calendar? I originally wrote that because I needed one for an app and doing it in script was slow - that's very rarely a problem in LC. - Camera LiveCode: export snapshot - ClipToPICTRes LiveCode: LC supports many resource fork operations, but since that fork is marked for deprecation there's little point in using them, and being Mac-specific they offer nothing for the other 90% of the computing world. - CmdPeriod LiveCode: commandKeyDown - DragThisWindow LiveCode: mouseMove - DrawIcon LiveCode: see note on resource fork above. - GetFolder LiveCode: answer folder (much more flexible in LC) - GetIndString LiveCode: see note on resource fork above. - GetVersion LiveCode: see note on resource fork above, thought it's worth noting that I now store version info in custom properties, which can be used for the sorts of things we used to use the old Mac res fork for, but are much more flexible, more robust, and available on all platforms. - GrowThisWindow LiveCode: mouseMove - InjectPPAT LiveCode: backgroundPattern property - IntersectRect LiveCode: within - LineMatch LiveCode: lineOffset - ListFonts LiveCode: the fontnames - ListRes LiveCode: getResources - MonitorRects LiveCode: the working screenRects - MoveFile LiveCode: rename file - NewFolder LiveCode: create folder - PixelColor LiveCode: screenMouseLoc with mouseColor - PopList LiveCode: popup - RestartMac LiveCode: one-line call to shell - SetColorCursor LiveCode: all cursors can be color - ShowProgress LiveCode: built-in progress object - ShutDownMac LiveCode: one-line call to shell - SnapDragon LiveCode: built-in grid property - xFileType LiveCode: the detailed files - xPrefs LiveCode: specialFolderPath Even the externals others wrote that I published for SC are easily done in native LiveCode, from arrays to lists to statistical functions, text-to-speech, and much more - easier to work with right in the scripting language, and unlike externals can be used on multiple platforms. Just a thought since I have not seen anyone marketing externals for LiveCode. Check out the LiveCode Market Place: https://livecode.com/store/marketplace/ There are several dozen add-on packages there, and many more throughout the community. It's just that with LiveCode's very broad capabilities, relatively few add-ons are externals per so, with many add-ons being libraries, custom controls, and other forms. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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
Re: externalPackages
JB wrote: Changing the subject a little bit you mentioned LiveCode is going to improve things so you can actually do more external type code from within LiveCode. Are they going to be using Apples new programming language Swift at all? I don't think so. Swift is a very interesting language (made by the same super-genius who made the ground-breaking LLVM), but as far as I can tell Apple intends to make it available only for use on their own platforms. So for an omni-platform tool like LiveCode, Swift is a non-starter. Instead, the new language for widgets in LiveCode will be...LiveCode! :) New extensions to the LiveCode language are in development to allow us to not only make custom controls that behave more like built-in controls, but also directly talk to the OS APIs - see this video from Kevin with a sneak preview of what they're working on: http://livecode.com/blog/2014/07/08/the-next-generation-widgets-themes/ -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: externalPackages
Richard is wrong. The goal is to be able to use any language, including anything that is available for the separate OS-es. However, there'll be a meta-LC like language, that is not quite LC, but similar-ish, which will allow to write externals too. The Idea is that it's similar enough for more people to delve in and do Externals then with the current undocumented, not available on all platforms, never-really-cared-for mess. Delivery date is somewhen. On 14 Aug 2014, at 00:25, Richard Gaskin ambassa...@fourthworld.com wrote: JB wrote: Changing the subject a little bit you mentioned LiveCode is going to improve things so you can actually do more external type code from within LiveCode. Are they going to be using Apples new programming language Swift at all? I don't think so. Swift is a very interesting language (made by the same super-genius who made the ground-breaking LLVM), but as far as I can tell Apple intends to make it available only for use on their own platforms. So for an omni-platform tool like LiveCode, Swift is a non-starter. Instead, the new language for widgets in LiveCode will be...LiveCode! :) New extensions to the LiveCode language are in development to allow us to not only make custom controls that behave more like built-in controls, but also directly talk to the OS APIs - see this video from Kevin with a sneak preview of what they're working on: http://livecode.com/blog/2014/07/08/the-next-generation-widgets-themes/ -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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
Re: externalPackages
Björnke von Gierke wrote: Richard is wrong. The goal is to be able to use any language, including anything that is available for the separate OS-es. Well, it certainly wouldn't be the first time I was wrong. But given that the engine is currently written in C++ and much of the code is platform-independent, can you tell us more about this real goal and how it fits in with the development of a multi-platform toolkit like LiveCode? It may be that some time down the road, perhaps not all that long from now, Apple quietly changes their SDK license to *require* Swift. After all, the readers of this list know all too well they've tried that sort of thing before. At that point developers like RunRev would have no choice but to rewrite their Cocoa calls in whatever language Apple demands. But I'm not too worried: last time Apple tried to pull something like that the results were so disastrous that they completely backpedaled within a few months. While they never apologized for the damage they caused, nor even publicly acknowledged that it was never in their interests to have attempted it, Steve's gone, his vendetta with Adobe played out, and Tim Cook is a much more cool-headed leader. I doubt we'll see those sorts of shenanigans again; I like to think Cook understands the impact it has on the company's reputation in terms of being a reliable partner, esp. at a time of declining market share. However, there'll be a meta-LC like language, that is not quite LC, but similar-ish, which will allow to write externals too. The Idea is that it's similar enough for more people to delve in and do Externals It's early days and my understanding is that the syntax shown in that video is only experimental. But I share your view that it could be more LC-like - all we have to do is take a good look at ToolBook, which has supported optional data types and OS calls for decades. Everything I might have written an external for in any other xTalk I wrote directly in ToolBook, all the way down to the Win APIs, with the same clean syntax throughout. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: externalPackages
On 14 Aug 2014, at 01:12, Richard Gaskin ambassa...@fourthworld.com wrote: Richard is wrong. The goal is to be able to use any language, including anything that is available for the separate OS-es. Well, it certainly wouldn't be the first time I was wrong. But given that the engine is currently written in C++ and much of the code is platform-independent, can you tell us more about this real goal and how it fits in with the development of a multi-platform toolkit like LiveCode? You said there'll only be the new LC-like language to do externals. Instead there'll be most available languages, due to the way the new approach is different then the current one. One of the possible languages, and of course the one that ppl need to use a bit for wrapping the interfaces, will be the additional, new LC-like language. That is only concerning the new external interface. ___ 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
Re: externalPackages
Björnke von Gierke wrote: On 14 Aug 2014, at 01:12, Richard Gaskin wrote: Richard is wrong. The goal is to be able to use any language, including anything that is available for the separate OS-es. Well, it certainly wouldn't be the first time I was wrong. But given that the engine is currently written in C++ and much of the code is platform-independent, can you tell us more about this real goal and how it fits in with the development of a multi-platform toolkit like LiveCode? You said there'll only be the new LC-like language to do externals. Chalk it up perhaps to my bad writing; what I tried to suggest was that externals as we know them today would for the most part no longer be needed at all. An external is a object code file written in another language that was compiled with that language's compiler. Currently this is the only way to directly interface LiveCode with OS APIs, which is why we put up with the cumbersome requirements for dealing with them. What I suggested was that many of the things we used to write externals for would in many cases not need to be externals at all, using a new variant of LiveCode as shown in Kevin's video. So yes, to the degree that there's still a place for externals when Open Language is in our hands, they can continue to be written in any language where LC's externals API can be used. But it would seem from the video that such cases would be very few, perhaps specialized routines requiring optimal CPU performance (where compiled C will be hard to beat), but not for things merely needing to talk to OS APIs. Instead there'll be most available languages, due to the way the new approach is different then the current one. One of the possible languages, and of course the one that ppl need to use a bit for wrapping the interfaces, will be the additional, new LC-like language. That is only concerning the new external interface. I think we may be on the same track more than it seemed at first. I have no knowledge of the future plans for externals. I rarely use them now, and never write any new ones, so I've had almost no interest in them at all. But direct OS API access from within LiveCode - for me, that opens up a lot of interesting possibilities, the sort of thing I used to very much enjoy back when I could afford to do single-platform stuff in ToolBook. Being able to deliver code I can manage as gracefully as a LiveCode library without the strange finicky requirements of externals initialization or needing to leave LiveCode to go run some otherwise-completely-unrelated compiler will be quite exciting. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: externalPackages
I just watched the widget video and it sounds really great. The video like all of their videos was well done too. It sounds like Kevin wants more people developing externals and that is good. Balgenorth On Aug 13, 2014, at 3:25 PM, Richard Gaskin ambassa...@fourthworld.com wrote: JB wrote: Changing the subject a little bit you mentioned LiveCode is going to improve things so you can actually do more external type code from within LiveCode. Are they going to be using Apples new programming language Swift at all? I don't think so. Swift is a very interesting language (made by the same super-genius who made the ground-breaking LLVM), but as far as I can tell Apple intends to make it available only for use on their own platforms. So for an omni-platform tool like LiveCode, Swift is a non-starter. Instead, the new language for widgets in LiveCode will be...LiveCode! :) New extensions to the LiveCode language are in development to allow us to not only make custom controls that behave more like built-in controls, but also directly talk to the OS APIs - see this video from Kevin with a sneak preview of what they're working on: http://livecode.com/blog/2014/07/08/the-next-generation-widgets-themes/ -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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
Re: externalPackages
This will be a fantastic improvement. John Balgenorth On Aug 13, 2014, at 3:46 PM, Björnke von Gierke b...@mac.com wrote: Richard is wrong. The goal is to be able to use any language, including anything that is available for the separate OS-es. However, there'll be a meta-LC like language, that is not quite LC, but similar-ish, which will allow to write externals too. The Idea is that it's similar enough for more people to delve in and do Externals then with the current undocumented, not available on all platforms, never-really-cared-for mess. Delivery date is somewhen. On 14 Aug 2014, at 00:25, Richard Gaskin ambassa...@fourthworld.com wrote: JB wrote: Changing the subject a little bit you mentioned LiveCode is going to improve things so you can actually do more external type code from within LiveCode. Are they going to be using Apples new programming language Swift at all? I don't think so. Swift is a very interesting language (made by the same super-genius who made the ground-breaking LLVM), but as far as I can tell Apple intends to make it available only for use on their own platforms. So for an omni-platform tool like LiveCode, Swift is a non-starter. Instead, the new language for widgets in LiveCode will be...LiveCode! :) New extensions to the LiveCode language are in development to allow us to not only make custom controls that behave more like built-in controls, but also directly talk to the OS APIs - see this video from Kevin with a sneak preview of what they're working on: http://livecode.com/blog/2014/07/08/the-next-generation-widgets-themes/ -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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 ___ 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 ___ 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
Re: externalPackages
On Sun, Aug 10, 2014 at 11:06 PM, JB sund...@pacifier.com wrote: I created a button and put the following script into it. on mouseUp put the externalPackages of stack rnahelloTest into fld id 1004 end mouseUp What happens is it sets my field to empty. I was thinking that since I have installed the external properly and the stack is able to use it properly it would list my external. The externalPackages will be empty if the external failed to load. The externals property reports the path to the external file on disk. The externalPackages will report the names of the externals that were successfully loaded. If the externals property is pointing to the property external file on disk, you can make sure the destroyWindow property of the stack is set to true, close the stack, and then open it again. This will attempt to reload the external. -- Trevor DeVore ScreenSteps www.screensteps.com-www.clarify-it.com ___ 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
