Discussion:
Where is the declarative border color setting in the property
Niggemann, Bernd via use-livecode
2018-11-09 11:13:21 UTC
Permalink
Keith,

depending on your settings in Preferences -> General -> "Description of option" or "Name of Livecode Property" border color will show up in Properties Inspector in tab "Colors" as

"Border/grid Color" or "borderColor"

Kind regards
Bernd
Date: Fri, 09 Nov 2018 09:02:18 +0000
From: Keith Clarke
Folks,
Am I missing something - has border color been removed from the Property Inspector?s ?colors? tab or has one always had to code this?
Thanks,
Keith
Keith Clarke via use-livecode
2018-11-09 11:26:48 UTC
Permalink
Thanks Bernd. That’s exactly what I was expecting, but see neither - 'Border fill' is the only Border color property I see in the list?!?

Could I have accidentally set something to hide this?
Best,
Keith
Post by Niggemann, Bernd via use-livecode
Keith,
depending on your settings in Preferences -> General -> "Description of option" or "Name of Livecode Property" border color will show up in Properties Inspector in tab "Colors" as
"Border/grid Color" or "borderColor"
Kind regards
Bernd
Date: Fri, 09 Nov 2018 09:02:18 +0000
From: Keith Clarke
Folks,
Am I missing something - has border color been removed from the Property Inspector?s ?colors? tab or has one always had to code this?
Thanks,
Keith
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Niggemann, Bernd via use-livecode
2018-11-09 11:41:25 UTC
Permalink
Keith,

I see "Border fill" when the preference setting is "Description of option" for a field. For an image I see "Border/grid Color" with the same setting.

Since I always have "Name of Livecode Property" set in Preferences I never noticed the difference.

Anyhow the tooltip shows the alternative option

Kind regards

Bernd


Thanks Bernd. That’s exactly what I was expecting, but see neither - 'Border
fill' is the only Border color property I see in the list?!?

Could I have accidentally set something to hide this?
Best,
Keith


Am 09.11.2018 um 12:13 schrieb berndnig <***@uni-wh.de<mailto:***@uni-wh.de>>:

Keith,

depending on your settings in Preferences -> General -> "Description of option" or "Name of Livecode Property" border color will show up in Properties Inspector in tab "Colors" as

"Border/grid Color" or "borderColor"

Kind regards
Bernd


Date: Fri, 09 Nov 2018 09:02:18 +0000
From: Keith Clarke

Folks,
Am I missing something - has border color been removed from the Property Inspector?s ?colors? tab or has one always had to code this?
Thanks,
Keith
Keith Clarke via use-livecode
2018-11-09 11:56:39 UTC
Permalink
D’Oh - of course, in LC the basic 'border fill' = CSS ‘border: color' (as shown in the clearly 'not-quite-idiot-proof' tool-tip!). Thanks!

Sorry to waste your time - I’m jumping between LC, Javascript and CSS and my Babel Fish has clearly fallen asleep or out…


…boy am I glad the weekend is fast-approaching! :-)
Best,
Keith
Post by Niggemann, Bernd via use-livecode
Keith,
I see "Border fill" when the preference setting is "Description of option" for a field. For an image I see "Border/grid Color" with the same setting.
Since I always have "Name of Livecode Property" set in Preferences I never noticed the difference.
Anyhow the tooltip shows the alternative option
Kind regards
Bernd
Thanks Bernd. That’s exactly what I was expecting, but see neither - 'Border
fill' is the only Border color property I see in the list?!?
Could I have accidentally set something to hide this?
Best,
Keith
Keith,
depending on your settings in Preferences -> General -> "Description of option" or "Name of Livecode Property" border color will show up in Properties Inspector in tab "Colors" as
"Border/grid Color" or "borderColor"
Kind regards
Bernd
Date: Fri, 09 Nov 2018 09:02:18 +0000
From: Keith Clarke
Folks,
Am I missing something - has border color been removed from the Property Inspector?s ?colors? tab or has one always had to code this?
Thanks,
Keith
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Bob Sneidar via use-livecode
2018-11-09 15:55:23 UTC
Permalink
I love that movie. That face when the Babel Fish goes in is priceless.

Bob S
Post by Keith Clarke via use-livecode
D’Oh - of course, in LC the basic 'border fill' = CSS ‘border: color' (as shown in the clearly 'not-quite-idiot-proof' tool-tip!). Thanks!
Sorry to waste your time - I’m jumping between LC, Javascript and CSS and my Babel Fish has clearly fallen asleep or out… http://youtu.be/YWqHkYtREAE
…boy am I glad the weekend is fast-approaching! :-)
Best,
Keith
Rick Harrison via use-livecode
2018-11-09 16:13:08 UTC
Permalink
Dear LiveCoders,

I am using LiveCode Indy 9.0.1, Xcode 9.3, and macOS 10.13.6 High Sierra.

I have an old LC 32 bit iOS app that was removed from the App Store
because it was 32 bit. I was so mad at Apple for screwing me on
it that I stayed away from it for quite a while.

Recently I decided that I would try to update it as a macOS app.
After doing my conversion it was time to get back into creating
profiles etc.

I created a brand new profile for it and added the name mac as a suffix.

I tried to use the OSXPackageMaker by Pi Digital, but it doesn’t find the
new profile I just created.

When I looked in Xcode 9.3 it told me that my brand new profile was Deprecated!

After looking all over the internet the suggestion is to let Xcode automatically manage everything.

Yet our LiveCode environment seems to encourage a manual process.

I have looked at:

http://lessons.livecode.com/m/4071/l/876834-signing-and-uploading-apps-to-the-mac-app-store
https://www.raywenderlich.com/120-how-to-submit-an-app-to-apple-from-no-account-to-app-store-part-1
Mac AppStore Checklist.txt

Everything is one hot mess now! I don’t know how we can possibly expect anyone new to LiveCode
is going to find their way successfully through the jungle that has been created without adequate
up-to-date step by step instructions with images. This somehow needs to become a part of the LC
review and update cycle.

Anyway, should I let Xcode automatically manage my profiles?

Other suggestions?

Whatever happened to the good old days when one could just create a standalone, zip it, and
upload it to some distribution website? Boy do I ever miss the good old days!

Thanks in advance!

Rick
kee nethery via use-livecode
2018-11-09 19:43:38 UTC
Permalink
Did you try this checklist? If you did and it didn’t work, please let me know so I can fix it.

Kee Nethery

http://lessons.livecode.com/m/4071/l/876834-signing-and-uploading-apps-to-the-mac-app-store
Rick Harrison via use-livecode
2018-11-09 20:17:11 UTC
Permalink
Hi Kee,

If you had read far enough down on my original message you
would have seen that I have looked at that lesson.

One of the important things it says is:
To upload to the App Store you need an Apple Developer
account and corresponding developer certificates. This article
does not cover that process.

(I think we should include that important step if possible.)

I will attempt to work through it one more time anyway,
and get back to you after I’m sure I have wasted enough
time and energy.

Thanks,

Rick
Post by kee nethery via use-livecode
Did you try this checklist? If you did and it didn’t work, please let me know so I can fix it.
Kee Nethery
http://lessons.livecode.com/m/4071/l/876834-signing-and-uploading-apps-to-the-mac-app-store
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
kee nethery via use-livecode
2018-11-09 20:44:46 UTC
Permalink
The URL to start the enrollment process to be an Apple Developer is
https://developer.apple.com/programs/enroll/

Will add that to the lesson, thanks
Kee
Post by Rick Harrison via use-livecode
Hi Kee,
If you had read far enough down on my original message you
would have seen that I have looked at that lesson.
To upload to the App Store you need an Apple Developer
account and corresponding developer certificates. This article
does not cover that process.
(I think we should include that important step if possible.)
I will attempt to work through it one more time anyway,
and get back to you after I’m sure I have wasted enough
time and energy.
Thanks,
Rick
Post by kee nethery via use-livecode
Did you try this checklist? If you did and it didn’t work, please let me know so I can fix it.
Kee Nethery
http://lessons.livecode.com/m/4071/l/876834-signing-and-uploading-apps-to-the-mac-app-store
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Rick Harrison via use-livecode
2018-11-09 22:27:36 UTC
Permalink
Hi Kee,

Thanks for that. Although I’ve been down that
lane for sometime now. Why Apple keeps
making things worse and worse instead of
the other way around I don’t know.

In principle, I believe that no LiveCoder should
ever have to be subjected to using the Terminal.
Ideally we should have a stack that pulls everything
together for our LiveCode users so they don’t have
to even touch it.

I will let you know what I find out if anything.

Rick
Post by kee nethery via use-livecode
The URL to start the enrollment process to be an Apple Developer is
https://developer.apple.com/programs/enroll/
Will add that to the lesson, thanks
Kee
Post by Rick Harrison via use-livecode
Hi Kee,
If you had read far enough down on my original message you
would have seen that I have looked at that lesson.
To upload to the App Store you need an Apple Developer
account and corresponding developer certificates. This article
does not cover that process.
(I think we should include that important step if possible.)
I will attempt to work through it one more time anyway,
and get back to you after I’m sure I have wasted enough
time and energy.
Thanks,
Rick
Post by kee nethery via use-livecode
Did you try this checklist? If you did and it didn’t work, please let me know so I can fix it.
Kee Nethery
http://lessons.livecode.com/m/4071/l/876834-signing-and-uploading-apps-to-the-mac-app-store
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Bob Sneidar via use-livecode
2018-11-09 22:49:12 UTC
Permalink
It's funny you should say that. Long ago when the first Apple MacIntoshes came out, I fell in love with the GUI simply because I could use a computer without having to type in commands. For years, I would not even work with a PC, because all their was to work with was DOS, and even when Windows came out, it was really DOS pretending to be a GUI.

Later, when I went from being a hobbyist to doing real IT for a living, I was soooo exasperated with PCs because reformatting a hard drive was an evening's work, especially if the manufacturer wasn't real clear about how many sectors, blocks, etc in the sticker on the drive! But I always had Macs to look to, where I could say, "See? NO COMMAND LINE! THAT's how to do computing nowadays!"

Now, even with all the advances Microsoft has made in their OS, some things can *only* be done from a command line, and I think this is just laziness on the part of developers. Apple seems to have fallen in to this developer malaise, where it's easier to just write some terminal code and tell people, "Just type this command..."

People cannot remember commands, especially not terminal commands, with all the arguments and caveats and different ways to put it all together. Apple used to be, "The computer for the rest of us." Now it's just another computer.

Bob S
Post by Rick Harrison via use-livecode
Hi Kee,
Thanks for that. Although I’ve been down that
lane for sometime now. Why Apple keeps
making things worse and worse instead of
the other way around I don’t know.
In principle, I believe that no LiveCoder should
ever have to be subjected to using the Terminal.
Ideally we should have a stack that pulls everything
together for our LiveCode users so they don’t have
to even touch it.
I will let you know what I find out if anything.
Rick
Andre Alves Garzia via use-livecode
2018-11-10 11:01:03 UTC
Permalink
Bob,

I am hijacking this thread to express some personal opinions about the
terminal, it is not related to the topic of the original message but a
different perspective on the subject you brought up on your reply.

When I first for my mac (A G3 running Mac OS 8.x) and started developing
for it, my first thought was: "Where is the terminal?!", the lack of
terminal was one of the main reason I struggled with development in the
mac for some time because, IMHO there is a beauty to terminal tools that
is no longer available to the current incarnation of macOS (but was
present in earlier versions, more about it later).

The main advantage for terminal tools is composability, which is at the
heart of the UNIX philosophy and remember (the current) "macOS is UNIX".
Having little tools that compose with one another to execute whatever
workflow you need. You generate certificates with one tool, you sign
binaries with another, you pipe the result of one command into the other
and with some clever scripting you automate your whole flow. The power
of UNIX is this toolbox of little tools and the scripting that goes on
top of them to compose them into pieces more powerful and featureful
than each individual component. Thats why in the terminal you can use a
single line to post something to a web API server, get a response,
decode it, parse its JSON reply, reason about it and extract data, just
by piping from "curl" to "jq" to "awk" or "grep" or "wc" or whatever you
need.

GUI tools don't compose. You need to ship new tools to add more features
or you need to update the current ones. Doing web stuff on classic MacOS
was tricky as I couldn't rely on my usual toolset of little UNIX gizmos
(I learned about MPW and other stuff later).

The solution to make GUI tools composable is AppleScript of course, and
I know many who are reading this email thought about that when reading
the second paragraph. With AppleScript we could have all the convenience
of GUI, the kind of easy and amazing UX that Bob was talking about, and
yet be composable thus making each GUI tool more capable than its
features alone. And for a while, this was fantastic but AppleScript is
no longer in favor at Apple and most Third-Party developers seem to have
forgotten it. Each power-user oriented app that allows scripting appears
to be shipping a different solution, so the dream of AppleScript is
lost, it was also never cross-platform, but the little rusty UNIX
toolkit still works, almost 60 years later, and it is
cross-platform-ish. So the Terminal allows Apple and others to reuse
good tools from GNU, *BSD and others and build the workflow they need.

Little terminal tools are the only way to automation these days, all the
other solutions require more buy-in from 3rd party developers or
reinventing the wheel. Thats why it pays of to learn just a bit of
terminal stuff, so that you too can build those little composable
things, so that you too can benefit from 60 years of little tools that
do the job.

Still, I miss AppleScript, and Frontier, and DreamCard, and MacOS Classic...

Om om

andre

PS: I am no longer a Apple user, so if by any chance AppleScript is
back, I am not aware of it, sorry.
Post by Bob Sneidar via use-livecode
It's funny you should say that. Long ago when the first Apple MacIntoshes came out, I fell in love with the GUI simply because I could use a computer without having to type in commands. For years, I would not even work with a PC, because all their was to work with was DOS, and even when Windows came out, it was really DOS pretending to be a GUI.
Later, when I went from being a hobbyist to doing real IT for a living, I was soooo exasperated with PCs because reformatting a hard drive was an evening's work, especially if the manufacturer wasn't real clear about how many sectors, blocks, etc in the sticker on the drive! But I always had Macs to look to, where I could say, "See? NO COMMAND LINE! THAT's how to do computing nowadays!"
Now, even with all the advances Microsoft has made in their OS, some things can *only* be done from a command line, and I think this is just laziness on the part of developers. Apple seems to have fallen in to this developer malaise, where it's easier to just write some terminal code and tell people, "Just type this command..."
People cannot remember commands, especially not terminal commands, with all the arguments and caveats and different ways to put it all together. Apple used to be, "The computer for the rest of us." Now it's just another computer.
Bob S
Post by Rick Harrison via use-livecode
Hi Kee,
Thanks for that. Although I’ve been down that
lane for sometime now. Why Apple keeps
making things worse and worse instead of
the other way around I don’t know.
In principle, I believe that no LiveCoder should
ever have to be subjected to using the Terminal.
Ideally we should have a stack that pulls everything
together for our LiveCode users so they don’t have
to even touch it.
I will let you know what I find out if anything.
Rick
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Pi Digital via use-livecode
2018-11-10 12:18:35 UTC
Permalink
Hi

Just to follow on from Andre, you can of course also run terminal scripts from LC. That’s exactly what I did in the aforementioned OSX Package Maker (soon to be reissued as the iOS/macOS Package Maker). You ‘could’ make a GUI for every terminal command available including every nuance and parameter. Indeed, Apple could do this for ‘every’ Unix/Terminal command. But can you imagine the complaints that would come with it with regards bloat ware.

But in addition to this is the thought that terminal stuff, much like LC stuff, can combine multiple commands and functions together into one line of script. Can you imagine if LC was entirely GUI based. Of course not as it would make it somewhat impractical. Not to say that it is impossible as is demonstrated by the Unreal Engine coding environment (which is pretty cool actually, albeit a bit cumbersome).

Take, also the simplicity of copy/paste that would not be possible in a gui. All apple have to do is give an example of a line of script where we replace out the various parameters to suit our circumstance. I say Bravo to Apple for making this still available and a common standard for ‘us’ (bearing in mind this kind of stuff is aimed at coders/developers who are used to it as opposed to the ‘grannies and grandpas’ who barely use a mouse let alone the keyboard).

Sorry I was unable to sort out the Package maker before this. As some of you are aware I went through a pretty severe emotional hiccup midway through this year. Kee (whom I let down the most) managed to pick up a lot of the slack producing the guide for us all.

No doubt Apple will continue to make changes to the way things are done. But that is the nature of Soft wares. They are not rigid and inflexible. It is a good thing. As much as it is a pain, there’s nearly always a resultant gain. Go with it, adapt, and evolve. That’s progress!

All the best to you all.

Sean Cole
Pi Digital
Bob,
I am hijacking this thread to express some personal opinions about the terminal, it is not related to the topic of the original message but a different perspective on the subject you brought up on your reply.
When I first for my mac (A G3 running Mac OS 8.x) and started developing for it, my first thought was: "Where is the terminal?!", the lack of terminal was one of the main reason I struggled with development in the mac for some time because, IMHO there is a beauty to terminal tools that is no longer available to the current incarnation of macOS (but was present in earlier versions, more about it later).
The main advantage for terminal tools is composability, which is at the heart of the UNIX philosophy and remember (the current) "macOS is UNIX". Having little tools that compose with one another to execute whatever workflow you need. You generate certificates with one tool, you sign binaries with another, you pipe the result of one command into the other and with some clever scripting you automate your whole flow. The power of UNIX is this toolbox of little tools and the scripting that goes on top of them to compose them into pieces more powerful and featureful than each individual component. Thats why in the terminal you can use a single line to post something to a web API server, get a response, decode it, parse its JSON reply, reason about it and extract data, just by piping from "curl" to "jq" to "awk" or "grep" or "wc" or whatever you need.
GUI tools don't compose. You need to ship new tools to add more features or you need to update the current ones. Doing web stuff on classic MacOS was tricky as I couldn't rely on my usual toolset of little UNIX gizmos (I learned about MPW and other stuff later).
The solution to make GUI tools composable is AppleScript of course, and I know many who are reading this email thought about that when reading the second paragraph. With AppleScript we could have all the convenience of GUI, the kind of easy and amazing UX that Bob was talking about, and yet be composable thus making each GUI tool more capable than its features alone. And for a while, this was fantastic but AppleScript is no longer in favor at Apple and most Third-Party developers seem to have forgotten it. Each power-user oriented app that allows scripting appears to be shipping a different solution, so the dream of AppleScript is lost, it was also never cross-platform, but the little rusty UNIX toolkit still works, almost 60 years later, and it is cross-platform-ish. So the Terminal allows Apple and others to reuse good tools from GNU, *BSD and others and build the workflow they need.
Little terminal tools are the only way to automation these days, all the other solutions require more buy-in from 3rd party developers or reinventing the wheel. Thats why it pays of to learn just a bit of terminal stuff, so that you too can build those little composable things, so that you too can benefit from 60 years of little tools that do the job.
Still, I miss AppleScript, and Frontier, and DreamCard, and MacOS Classic...
Om om
andre
PS: I am no longer a Apple user, so if by any chance AppleScript is back, I am not aware of it, sorry.
Post by Bob Sneidar via use-livecode
It's funny you should say that. Long ago when the first Apple MacIntoshes came out, I fell in love with the GUI simply because I could use a computer without having to type in commands. For years, I would not even work with a PC, because all their was to work with was DOS, and even when Windows came out, it was really DOS pretending to be a GUI.
Later, when I went from being a hobbyist to doing real IT for a living, I was soooo exasperated with PCs because reformatting a hard drive was an evening's work, especially if the manufacturer wasn't real clear about how many sectors, blocks, etc in the sticker on the drive! But I always had Macs to look to, where I could say, "See? NO COMMAND LINE! THAT's how to do computing nowadays!"
Now, even with all the advances Microsoft has made in their OS, some things can *only* be done from a command line, and I think this is just laziness on the part of developers. Apple seems to have fallen in to this developer malaise, where it's easier to just write some terminal code and tell people, "Just type this command..."
People cannot remember commands, especially not terminal commands, with all the arguments and caveats and different ways to put it all together. Apple used to be, "The computer for the rest of us." Now it's just another computer.
Bob S
Post by Rick Harrison via use-livecode
Hi Kee,
Thanks for that. Although I’ve been down that
lane for sometime now. Why Apple keeps
making things worse and worse instead of
the other way around I don’t know.
In principle, I believe that no LiveCoder should
ever have to be subjected to using the Terminal.
Ideally we should have a stack that pulls everything
together for our LiveCode users so they don’t have
to even touch it.
I will let you know what I find out if anything.
Rick
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
JJS via use-livecode
2018-11-10 11:28:57 UTC
Permalink
In the release notes of LC is a line that states: LC is actually a
command line tool.
Post by Pi Digital via use-livecode
Hi
Just to follow on from Andre, you can of course also run terminal scripts from LC. That’s exactly what I did in the aforementioned OSX Package Maker (soon to be reissued as the iOS/macOS Package Maker). You ‘could’ make a GUI for every terminal command available including every nuance and parameter. Indeed, Apple could do this for ‘every’ Unix/Terminal command. But can you imagine the complaints that would come with it with regards bloat ware.
But in addition to this is the thought that terminal stuff, much like LC stuff, can combine multiple commands and functions together into one line of script. Can you imagine if LC was entirely GUI based. Of course not as it would make it somewhat impractical. Not to say that it is impossible as is demonstrated by the Unreal Engine coding environment (which is pretty cool actually, albeit a bit cumbersome).
Take, also the simplicity of copy/paste that would not be possible in a gui. All apple have to do is give an example of a line of script where we replace out the various parameters to suit our circumstance. I say Bravo to Apple for making this still available and a common standard for ‘us’ (bearing in mind this kind of stuff is aimed at coders/developers who are used to it as opposed to the ‘grannies and grandpas’ who barely use a mouse let alone the keyboard).
Sorry I was unable to sort out the Package maker before this. As some of you are aware I went through a pretty severe emotional hiccup midway through this year. Kee (whom I let down the most) managed to pick up a lot of the slack producing the guide for us all.
No doubt Apple will continue to make changes to the way things are done. But that is the nature of Soft wares. They are not rigid and inflexible. It is a good thing. As much as it is a pain, there’s nearly always a resultant gain. Go with it, adapt, and evolve. That’s progress!
All the best to you all.
Sean Cole
Pi Digital
Bob,
I am hijacking this thread to express some personal opinions about the terminal, it is not related to the topic of the original message but a different perspective on the subject you brought up on your reply.
When I first for my mac (A G3 running Mac OS 8.x) and started developing for it, my first thought was: "Where is the terminal?!", the lack of terminal was one of the main reason I struggled with development in the mac for some time because, IMHO there is a beauty to terminal tools that is no longer available to the current incarnation of macOS (but was present in earlier versions, more about it later).
The main advantage for terminal tools is composability, which is at the heart of the UNIX philosophy and remember (the current) "macOS is UNIX". Having little tools that compose with one another to execute whatever workflow you need. You generate certificates with one tool, you sign binaries with another, you pipe the result of one command into the other and with some clever scripting you automate your whole flow. The power of UNIX is this toolbox of little tools and the scripting that goes on top of them to compose them into pieces more powerful and featureful than each individual component. Thats why in the terminal you can use a single line to post something to a web API server, get a response, decode it, parse its JSON reply, reason about it and extract data, just by piping from "curl" to "jq" to "awk" or "grep" or "wc" or whatever you need.
GUI tools don't compose. You need to ship new tools to add more features or you need to update the current ones. Doing web stuff on classic MacOS was tricky as I couldn't rely on my usual toolset of little UNIX gizmos (I learned about MPW and other stuff later).
The solution to make GUI tools composable is AppleScript of course, and I know many who are reading this email thought about that when reading the second paragraph. With AppleScript we could have all the convenience of GUI, the kind of easy and amazing UX that Bob was talking about, and yet be composable thus making each GUI tool more capable than its features alone. And for a while, this was fantastic but AppleScript is no longer in favor at Apple and most Third-Party developers seem to have forgotten it. Each power-user oriented app that allows scripting appears to be shipping a different solution, so the dream of AppleScript is lost, it was also never cross-platform, but the little rusty UNIX toolkit still works, almost 60 years later, and it is cross-platform-ish. So the Terminal allows Apple and others to reuse good tools from GNU, *BSD and others and build the workflow they need.
Little terminal tools are the only way to automation these days, all the other solutions require more buy-in from 3rd party developers or reinventing the wheel. Thats why it pays of to learn just a bit of terminal stuff, so that you too can build those little composable things, so that you too can benefit from 60 years of little tools that do the job.
Still, I miss AppleScript, and Frontier, and DreamCard, and MacOS Classic...
Om om
andre
PS: I am no longer a Apple user, so if by any chance AppleScript is back, I am not aware of it, sorry.
Post by Bob Sneidar via use-livecode
It's funny you should say that. Long ago when the first Apple MacIntoshes came out, I fell in love with the GUI simply because I could use a computer without having to type in commands. For years, I would not even work with a PC, because all their was to work with was DOS, and even when Windows came out, it was really DOS pretending to be a GUI.
Later, when I went from being a hobbyist to doing real IT for a living, I was soooo exasperated with PCs because reformatting a hard drive was an evening's work, especially if the manufacturer wasn't real clear about how many sectors, blocks, etc in the sticker on the drive! But I always had Macs to look to, where I could say, "See? NO COMMAND LINE! THAT's how to do computing nowadays!"
Now, even with all the advances Microsoft has made in their OS, some things can *only* be done from a command line, and I think this is just laziness on the part of developers. Apple seems to have fallen in to this developer malaise, where it's easier to just write some terminal code and tell people, "Just type this command..."
People cannot remember commands, especially not terminal commands, with all the arguments and caveats and different ways to put it all together. Apple used to be, "The computer for the rest of us." Now it's just another computer.
Bob S
Post by Rick Harrison via use-livecode
Hi Kee,
Thanks for that. Although I’ve been down that
lane for sometime now. Why Apple keeps
making things worse and worse instead of
the other way around I don’t know.
In principle, I believe that no LiveCoder should
ever have to be subjected to using the Terminal.
Ideally we should have a stack that pulls everything
together for our LiveCode users so they don’t have
to even touch it.
I will let you know what I find out if anything.
Rick
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Richard Gaskin via use-livecode
2018-11-10 19:08:54 UTC
Permalink
Post by Bob Sneidar via use-livecode
People cannot remember commands, especially not terminal commands,
with all the arguments and caveats and different ways to put it all
together.
For end-users, the awareness of that principle is very powerful.

But where are we, here in this discussion? On a mailing list for
programmers using a rich language with 3,000+ tokens to memorize. :)

Just as LiveCode is the way we build applications, Terminal is the way
we manage our systems.

Locally, you can get away with never automating anything in bash (though
why wouldn't a programmer want to take advantage of automation?).

But for working with servers, bash is the lingua franca of sysadmin, the
foundation of efficient work to handle all the essentials and also make
systems more robust, secure, and redeployable.

Besides, most servers have no GUI, so Terminal is your only UI.

As programmers, we like the expressiveness of text and the opportunity
to learn.

--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
***@FourthWorld.com http://www.FourthWorld.com
JJS via use-livecode
2018-11-10 19:45:47 UTC
Permalink
By the way.

In Mojave i got a a message "you are running a 32bit program" (the
livecode ide).

Within a certain amount of time it's going to "force"  to use 64bit programs
Post by Richard Gaskin via use-livecode
Post by Bob Sneidar via use-livecode
People cannot remember commands, especially not terminal commands,
with all the arguments and caveats and different ways to put it all
together.
For end-users, the awareness of that principle is very powerful.
But where are we, here in this discussion?  On a mailing list for
programmers using a rich language with 3,000+ tokens to memorize. :)
Just as LiveCode is the way we build applications, Terminal is the way
we manage our systems.
Locally, you can get away with never automating anything in bash
(though why wouldn't a programmer want to take advantage of automation?).
But for working with servers, bash is the lingua franca of sysadmin,
the foundation of efficient work to handle all the essentials and also
make systems more robust, secure, and redeployable.
Besides, most servers have no GUI, so Terminal is your only UI.
As programmers, we like the expressiveness of text and the opportunity
to learn.
--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 ____________________________________________________________________
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
Richard Gaskin via use-livecode
2018-11-10 20:25:48 UTC
Permalink
Post by JJS via use-livecode
In Mojave i got a a message "you are running a 32bit program" (the
livecode ide).
Within a certain amount of time it's going to "force" to use 64bit
programs
Yep, and the team has come through: several months ago they delivered
v9.0, which now allows standalone building for 64-bit macOS systems.

It's now even better with v9.0.2rc1 released yesterday:
https://downloads.livecode.com/livecode/
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
***@FourthWorld.com http://www.FourthWorld.com
Pi Digital via use-livecode
2018-11-10 21:41:50 UTC
Permalink
https://downloads.livecode.com/livecode/9_0_0/LiveCodeNotes-9_0_0.pdf#page32
The IDE is now 64-bit by default on Mac
Moreover, the "Build for Mac OS X 64-bit" is checked by default on newly created stacks in the standalone settings for OS X. Existing stacks will retain their current settings.
Check your settings perhaps. You can double check by going to Apple>AboutThisMac>SystemReport(button)>Software>Applications>LiveCode 9.0.2> and look at 64-bit to see if it says yes. If it does, nothing to worry about.

Sean Cole
Pi Digital
By the way.
In Mojave i got a a message "you are running a 32bit program" (the livecode ide).
Within a certain amount of time it's going to "force" to use 64bit programs
JJS via use-livecode
2018-11-11 11:25:02 UTC
Permalink
Yes i know the standalone can be 64bit.

I also know how to check in Macos if a program is 64bit.

I was talking about the IDE itself. That's 32-bit.
Post by Pi Digital via use-livecode
https://downloads.livecode.com/livecode/9_0_0/LiveCodeNotes-9_0_0.pdf#page32
The IDE is now 64-bit by default on Mac
Moreover, the "Build for Mac OS X 64-bit" is checked by default on newly created stacks in the standalone settings for OS X. Existing stacks will retain their current settings.
Check your settings perhaps. You can double check by going to Apple>AboutThisMac>SystemReport(button)>Software>Applications>LiveCode 9.0.2> and look at 64-bit to see if it says yes. If it does, nothing to worry about.
Sean Cole
Pi Digital
By the way.
In Mojave i got a a message "you are running a 32bit program" (the livecode ide).
Within a certain amount of time it's going to "force" to use 64bit programs
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
Sean Cole (Pi) via use-livecode
2018-11-11 13:59:11 UTC
Permalink
The release notes for 9.0.0 stable state otherwise as quoted below
referring directly to the IDE, not Standalones.
Post by JJS via use-livecode
The *IDE* is now 64-bit by default on Mac
I also checked on my versions here and it is definitely 64bit so I’m not
sure why your machine is not saying the same.

Try this script for the file path to your LC ide in the terminal.

lipo -info /Applications/LiveCode\ Indy\ 9.0.2\ \(rc\
1\).app/Contents/MacOS/LiveCode-Indy


For me it shows:

are: i386 x86_64

Demonstrating both 32 and 64 bit.
The IDE itself is just a rev script that runs within the LC overall
environment so would not be 64 or 32 bit itself.

Sean


On Sun, 11 Nov 2018 at 11:25, JJS via use-livecode <
Post by JJS via use-livecode
Yes i know the standalone can be 64bit.
I also know how to check in Macos if a program is 64bit.
I was talking about the IDE itself. That's 32-bit.
https://downloads.livecode.com/livecode/9_0_0/LiveCodeNotes-9_0_0.pdf#page32
The IDE is now 64-bit by default on Mac
Moreover, the "Build for Mac OS X 64-bit" is checked by default on
newly created stacks in the standalone settings for OS X. Existing stacks
will retain their current settings.
Check your settings perhaps. You can double check by going to
Apple>AboutThisMac>SystemReport(button)>Software>Applications>LiveCode
9.0.2> and look at 64-bit to see if it says yes. If it does, nothing to
worry about.
Sean Cole
Pi Digital
On 10 Nov 2018, at 19:45, JJS via use-livecode <
By the way.
In Mojave i got a a message "you are running a 32bit program" (the
livecode ide).
Within a certain amount of time it's going to "force" to use 64bit
programs
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
JJS via use-livecode
2018-11-11 13:28:48 UTC
Permalink
Yep, you're correct. It says 64bit.

I must have been blind.

thanks!
Post by Sean Cole (Pi) via use-livecode
The release notes for 9.0.0 stable state otherwise as quoted below
referring directly to the IDE, not Standalones.
Post by JJS via use-livecode
The *IDE* is now 64-bit by default on Mac
I also checked on my versions here and it is definitely 64bit so I’m not
sure why your machine is not saying the same.
Try this script for the file path to your LC ide in the terminal.
lipo -info /Applications/LiveCode\ Indy\ 9.0.2\ \(rc\
1\).app/Contents/MacOS/LiveCode-Indy
are: i386 x86_64
Demonstrating both 32 and 64 bit.
The IDE itself is just a rev script that runs within the LC overall
environment so would not be 64 or 32 bit itself.
Sean
On Sun, 11 Nov 2018 at 11:25, JJS via use-livecode <
Post by JJS via use-livecode
Yes i know the standalone can be 64bit.
I also know how to check in Macos if a program is 64bit.
I was talking about the IDE itself. That's 32-bit.
https://downloads.livecode.com/livecode/9_0_0/LiveCodeNotes-9_0_0.pdf#page32
The IDE is now 64-bit by default on Mac
Moreover, the "Build for Mac OS X 64-bit" is checked by default on
newly created stacks in the standalone settings for OS X. Existing stacks
will retain their current settings.
Check your settings perhaps. You can double check by going to
Apple>AboutThisMac>SystemReport(button)>Software>Applications>LiveCode
9.0.2> and look at 64-bit to see if it says yes. If it does, nothing to
worry about.
Sean Cole
Pi Digital
On 10 Nov 2018, at 19:45, JJS via use-livecode <
By the way.
In Mojave i got a a message "you are running a 32bit program" (the
livecode ide).
Within a certain amount of time it's going to "force" to use 64bit
programs
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
kee nethery via use-livecode
2018-11-10 02:29:21 UTC
Permalink
I agree that the LiveCode Application Builder should handle all the details.

The stacks that others have built work great … until they don’t. That’s why my instructions are all Terminal based. If something errors out, you can see the error and perhaps deal with it. When everything is hidden behind a stack, making it work is more difficult, in my opinion.

Kee
Post by Rick Harrison via use-livecode
Hi Kee,
Thanks for that. Although I’ve been down that
lane for sometime now. Why Apple keeps
making things worse and worse instead of
the other way around I don’t know.
In principle, I believe that no LiveCoder should
ever have to be subjected to using the Terminal.
Ideally we should have a stack that pulls everything
together for our LiveCode users so they don’t have
to even touch it.
I will let you know what I find out if anything.
Rick
Loading...