Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Sean Cole wrote: > I've added updates to this bug relating to the script editor issues > and crashes > > https://quality.livecode.com/show_bug.cgi?id=22389 Thank you, Sean. I'm signed onto the report, and will add any notes I can if I see this on my Mac. -- 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
On 3/12/20 9:12 PM, Sean Cole (Pi) via use-livecode wrote: I was able to reproduce the issue (continually) so I did another screen recording. It's either the auto-type suggestion thing or it's the error bullet it puts on the numbers (which would then tie up with the breakpoint and other SE errors). Interesting! Sean- That's awesome! A repeatable recipe. I notice that the error indicator moves between lines 3356 and 3357, as it should, as you type, finally ending up at line 3358 at the hang. So with that in mind... Did you press return after typing "then" or did the hang happen as soon as you typed that word? Does the hang only happen if you have the Breakpoints tab selected? How about if you selected the Errors tab instead? You're using 9.5.1 Indy and I see you have the Autocomplete option enabled... do you have the Control Structure Completion option enabled as well? -- Mark Wieder ahsoftw...@gmail.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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
I was able to reproduce the issue (continually) so I did another screen recording. It's either the auto-type suggestion thing or it's the error bullet it puts on the numbers (which would then tie up with the breakpoint and other SE errors). Interesting! Sean On Fri, 13 Mar 2020 at 03:47, Sean Cole (Pi) wrote: > I've added updates to this bug relating to the script editor issues and > crashes > > https://quality.livecode.com/show_bug.cgi?id=22389 > > ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
I've added updates to this bug relating to the script editor issues and crashes https://quality.livecode.com/show_bug.cgi?id=22389 ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
I see now. I confess that I stopped reading the subject itself after a while when the thread took off on a tangent. You make a valid point. LC actually did what you describe when 64-bit started to be required on OS X. They released a rapid update and made the deadline but it was close. I heard they really had to scramble, but they knew how important it was. Apparently Apple doesn't give much advance notice to third-party IDE developers. If you're working in Xcode these changes are less intrusive. I haven't yet installed Catalina, but I submitted an app to the App Store last week built with Xcode 11.1 and LC 9.6dp2, and it ran on iOS 13. It was not rejected for that reason (though I did screw up on something else.) Unless something has changed since then, I think you can proceed. LC has always met the final deadlines for these things and I'm sure they'll do it again. But I agree that a longer lead time would ease everyone's mind. Is Xcode 11.3 or iOS 13.3 required soon? I thought we still had a month or more left. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 12, 2020 8:54:11 PM Pi Digital via use-livecode wrote: The clue is in the subject heading, Jacque. At least, I thought it was plain enough. The script editor and HTML issues I mentioned were just ‘mind wind’ in the process of bemoaning the speed of uptake to current OS and Xcode support. Here’s the big issue. Essential updates that all users are dependent on, like OS support, are held off from release while other minor updates are worked on and refined. I would venture to suggest that a new policy for these heavy releases to come quicker in a x.x.x release while the other combination/collection of fixes and features be sent out in an x.x release. This would then make sure critical errors/features (which I would say OS support fits into) are addressed and released quicker while not being held off at the mercy of other fixes waiting in the wings. Using this method would make it easier on the hub too. Anyone working on non critical updates can develop to the sub major release (ie. 9.7) while other more critical fixes can be applied to minor (not minor in urgency) releases (ie. 9.6.24). These can then have just one or three fixes that then get fed upstream into the 9.7 develop branch to be then checked against any other features being added to it. Does that make sense? Sean Cole Pi Digital ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
The clue is in the subject heading, Jacque. At least, I thought it was plain enough. The script editor and HTML issues I mentioned were just ‘mind wind’ in the process of bemoaning the speed of uptake to current OS and Xcode support. Here’s the big issue. Essential updates that all users are dependent on, like OS support, are held off from release while other minor updates are worked on and refined. I would venture to suggest that a new policy for these heavy releases to come quicker in a x.x.x release while the other combination/collection of fixes and features be sent out in an x.x release. This would then make sure critical errors/features (which I would say OS support fits into) are addressed and released quicker while not being held off at the mercy of other fixes waiting in the wings. Using this method would make it easier on the hub too. Anyone working on non critical updates can develop to the sub major release (ie. 9.7) while other more critical fixes can be applied to minor (not minor in urgency) releases (ie. 9.6.24). These can then have just one or three fixes that then get fed upstream into the 9.7 develop branch to be then checked against any other features being added to it. Does that make sense? Sean Cole Pi Digital ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
This one was okay. :) You sound a little more relaxed. I frequently have the same frustrations as you do, but knowing a little about the team helps moderate my posts. I think this long thread could have been shorter if you had just said what roadblocks in particular are preventing you from completing the work. I do understand you're having issues with the script editor, but what features exactly do you need that don't exist? (I hope I didn't miss something.) When I felt completely blocked because I couldn't find a way to scroll to metadata in a field, several people jumped in to help me and Mark Waddingham even provided a complete handler. I would have lost the job without that. I'm grateful. So maybe we can help you too. Throw out a challenge. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On March 12, 2020 6:54:28 PM Pi Digital via use-livecode wrote: Hi all Thank you for all your kind words. Sorry, you said ‘no’ sarcasm. Oops. My bad. I had posted this originally to the dev-livecode list but I thought (accurately) I wouldn’t get a reponse from that. I’m sooo sorry (oops, I did it again) that this is viewed potentially by newbies. Although hiding the truth (‘forever’) is not a good policy either. Maybe one of them will notice that it doesn’t support the latest OSs/Xcode/Android. [Sharp inhale] Suppose they find out! Oh no!! I’ve been looking around but I can’t find a rant-livecode forum or the use-livecodeAtYourPeril forum or even a tryToUse-LiveCodeButEndUpUsingHeapsOfJavascriptAndPHPWorkaroundsInstead forum. Or even the dontUse-LiveCodeBecauseItsCrashedAgain forum. I’ve been thinking for a while whilst reading the various support and ‘spanking’ messages what I might write. But I worked out that the only ‘nice’ thing would be to say nothing (as my dear grandma always said I should). But at some point something has to be said. I currently have a client breathing heavily behind me because I can’t supply what they need. And by now I should be able to. My competitors, they’re new suppliers, are able to. I would be trying to fix the LC issues with HTML deployment myself if I wasn’t so bogged down with the workarounds on top of workarounds that are so messing with my head. I’ve been working 18hr days for months. So forgive me for asking a legitimate question (ok, in mild rant form) on a forum which is the ONLY place I can vent to others who USE-LIVECODE!! Name me one other place where Only veteran users can go and vent with like minded pro users of LC and I’m there! I someone created one I guarantee it would get tonnes more use than this one albeit unseen by the LC team. Which brings me to the final point (‘phew’ I hear you say!). Someone asked what I thought I would get from posting it here. Well, as someone else pointed out, the likes of the CTO do poke there heads this way every now and then. Interestingly today, maybe by coincidence, the amount of git-pulls have been massive in comparison to the last three months. Hopefully this means they are indeed gearing up to release a fixed 9.6GM or RC for us to work with on Friday (their preferred release day historically). I’d like to think (for my own satisfaction only) that my OP pushed towards it but would be just as ‘happy’(ish) if they were already about to. Either way, my original point of posting was to get a heads up and vent a teeny-tiny amount of my current frustration at this current time which is just a part of the never ending circle of futility I find myself in. Now, ‘that’ up there is what you call a rant :) I felt ill before typing this but feel much better now. Thank you all again. I’ve re-read this to be sure I wasn’t abusive or saying anything unfair or unqualified. Sarcastic, yes, but not of the hurtful kind. I’m trying to make light of it despite the mild-affronts and my warm neck. There was no Attack on LC. It was a question of Why the wait and How do I explain to my soon to be lost client and pay packet to my mortgage lenders. I hope you all now understand. Sean Cole Pi ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Pi Digital wrote: > I had posted this originally to the dev-livecode list but I thought > (accurately) I wouldn’t get a reponse from that. Yep, the dev list has been more or less retired since LC went open source. I'm not sure why it's still even up, except that a few people wanted it when they last asked if it should remain. So it's running, but few read it. This list is a good choice. > I currently have a client breathing heavily behind me because I can’t > supply what they need. And by now I should be able to. My competitors, > they’re new suppliers, are able to. Happens all the time. I've formed relationships with others employing complimentary skills and tooling for that purpose, bringing their specialties on board for things outside of my core services. And sometimes the project as a whole is sufficiently outside of what I do that I just refer the client to another qualified professional. No one does everything. Relationships bridge the gaps the cross-training or interest haven't yet filled. It's a big world, and software is eating it. Lots of opportunity for nearly any specialty or mix of specialties. > I would be trying to fix the LC issues with HTML deployment myself > if I wasn’t so bogged down with the workarounds on top of workarounds > that are so messing with my head. When LC's HTML export was first announced, I read up on Emscripten and how it works. Impressive for certain things, but when the result is running a scripting language inside of a canvas object interpreted by another scripting language, I figured I'd stick with brushing up my JS. I know at least one developer who has been using it profitably for a very specialized service. I'm glad for him. But my own needs are in a different field, with a different market, and working closer to the browser engine is a better fit for my own work. Similarly, I used to use LC for systems administration, until I learned bash. I can get the work done with LC, but I can get it done more quickly with the language designed specifically for that niche. LC's sweet spot is xplat desktop GUIs, where it's unbeatable. It's a good contender for mobile apps, and as a server tool*. Personally, I don't even think about HTML export, even though I helped fund the project to see whee it might go. And even though I spend some time in JS and bash, much of that work has at least some LC mixed in along the way. There's always some GUI tool, or some text processing for which awk feels awkward. Lots of choices, combined and recombined as needed. LC is nice, but it's not every language. There are hundreds, with more each year, because each is contributing a unique mix of strengths the others don't have. Back in the day I used to even write object store systems in LC (think MondgoDB scaled down for shared-hosting CGI). Not bad, and on two projects I still use it, but for new work I'm more inclined spin up a VPS and install Mongo or Couch. Same with server management. I started down the DIY road with an LC-based system and some clever (if I do say so myself ) use of the bash "expect" program. Fun and all, but ultimately a lot of work to handle every edge case or new capability. And all the while Ansible is sitting there waiting to be used by those who need a daemonless option, or go old-school with a few bash scripts. You know how much I enjoy and value LiveCode. But I don't use it for everything. I use it where it's the best choice for the task at hand. * RE server use: This is one area where I feel LiveCode's potential has yet to be fully realized by the world. Consider Ruby or Python: fine languages, but rarely used as CGIs before Rails and Django. Now Ruby on Rails has grown to such an audience that it's almost single-handedly justified returning to CGI in many shops. LiveCode performs roughly on par with both of them, but with chunk expressions - most of what we need to do on servers is text manipulation, and for that LC rocks! Our community is blessed with Ralf Bitter's tremendously excellent revIgniter framework. Modeled on WebIgniter, it's an excellent toolkit for a great many tasks. But the PHP world has more than one framework. Same with Python. I'd like to believe that as we build out great server apps with LC, out of this activity will emerge new and useful libraries, tools, and frameworks that can help the rest of the world come to appreciate the benefits of scripting in LiveCode. Same with streaming desktop apps, so easy in LC, so valuable to users, so underutilized... -- 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
Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
No offence taken at all, Matthias. I felt you hit ‘the nail’ on the head, not me. ;) I do regret bringing up my last ‘incident’ at all. It’s a bit of a splinter that just won’t go away for me and hard not to be reminded of far to often when I face the near same issues of failure I did back then. But thank you (not sarcasm this time) for looking out for me. Sean Cole Pi Digital Productions Ltd eMail Ts & Cs > On 12 Mar 2020, at 23:18, matthias rebbe via use-livecode > wrote: > > > >>> Am 13.03.2020 um 00:09 schrieb hh via use-livecode >>> : >>> >>> Matthias wrote: >>> I did NOT refer to any personal problems. So please do not impute >>> such an intention to me. >> >> Sorry Matthias, I obviously misinterpreted "your problems last year". >> Hopefully Sean Cole didn't also misinterpret this. >> > I hope so too. > > As you might know i am native German who had English only in school (30 years > ago). Although i am trying my best to express my thoughts correctly without > being misunderstood, it sometimes might sound other than it was intended. > > > >> ___ >> 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Hi all Thank you for all your kind words. Sorry, you said ‘no’ sarcasm. Oops. My bad. I had posted this originally to the dev-livecode list but I thought (accurately) I wouldn’t get a reponse from that. I’m sooo sorry (oops, I did it again) that this is viewed potentially by newbies. Although hiding the truth (‘forever’) is not a good policy either. Maybe one of them will notice that it doesn’t support the latest OSs/Xcode/Android. [Sharp inhale] Suppose they find out! Oh no!! I’ve been looking around but I can’t find a rant-livecode forum or the use-livecodeAtYourPeril forum or even a tryToUse-LiveCodeButEndUpUsingHeapsOfJavascriptAndPHPWorkaroundsInstead forum. Or even the dontUse-LiveCodeBecauseItsCrashedAgain forum. I’ve been thinking for a while whilst reading the various support and ‘spanking’ messages what I might write. But I worked out that the only ‘nice’ thing would be to say nothing (as my dear grandma always said I should). But at some point something has to be said. I currently have a client breathing heavily behind me because I can’t supply what they need. And by now I should be able to. My competitors, they’re new suppliers, are able to. I would be trying to fix the LC issues with HTML deployment myself if I wasn’t so bogged down with the workarounds on top of workarounds that are so messing with my head. I’ve been working 18hr days for months. So forgive me for asking a legitimate question (ok, in mild rant form) on a forum which is the ONLY place I can vent to others who USE-LIVECODE!! Name me one other place where Only veteran users can go and vent with like minded pro users of LC and I’m there! I someone created one I guarantee it would get tonnes more use than this one albeit unseen by the LC team. Which brings me to the final point (‘phew’ I hear you say!). Someone asked what I thought I would get from posting it here. Well, as someone else pointed out, the likes of the CTO do poke there heads this way every now and then. Interestingly today, maybe by coincidence, the amount of git-pulls have been massive in comparison to the last three months. Hopefully this means they are indeed gearing up to release a fixed 9.6GM or RC for us to work with on Friday (their preferred release day historically). I’d like to think (for my own satisfaction only) that my OP pushed towards it but would be just as ‘happy’(ish) if they were already about to. Either way, my original point of posting was to get a heads up and vent a teeny-tiny amount of my current frustration at this current time which is just a part of the never ending circle of futility I find myself in. Now, ‘that’ up there is what you call a rant :) I felt ill before typing this but feel much better now. Thank you all again. I’ve re-read this to be sure I wasn’t abusive or saying anything unfair or unqualified. Sarcastic, yes, but not of the hurtful kind. I’m trying to make light of it despite the mild-affronts and my warm neck. There was no Attack on LC. It was a question of Why the wait and How do I explain to my soon to be lost client and pay packet to my mortgage lenders. I hope you all now understand. Sean Cole Pi ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Not just dropped APIs. It starts already with Apple deciding if the functionality of an iOS App is worth to be approved for the Appstore or not. I had created 3 apps for a customer which were not accepted by Apple by the "lack" of functionality. At least that was the reason they told us, although we could proof that there were other similar apps in the store with less functionality. Some of them were even approved later than our apps were submitted. The good thing was that i get paid anyway because the complete design and functionality was described by the customer in specification sheets. So i was not responsible for the rejection of the apps. It´s always a risk to develop iOS apps. You´ll never know if they get accepted or not. An other risk is that every new iOS release might break your existing app in the iOS app store. > > Perhaps a good approach is to include in any contract for software products > or development the disclaimer that if the customer requests support for a 3rd > party API, that functionality and support for that API is restricted to the > terms of the 3rd party. Not sure how to word that legally. > That´s a good idea. So the developer is not responsible if there are changes to the 3rd party API and thereby the functionality of the program is disturbed or impaired. > Bob S ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> Am 13.03.2020 um 00:09 schrieb hh via use-livecode > : > >> Matthias wrote: >> I did NOT refer to any personal problems. So please do not impute >> such an intention to me. > > Sorry Matthias, I obviously misinterpreted "your problems last year". > Hopefully Sean Cole didn't also misinterpret this. > I hope so too. As you might know i am native German who had English only in school (30 years ago). Although i am trying my best to express my thoughts correctly without being misunderstood, it sometimes might sound other than it was intended. > ___ > 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
I hesitate to opine, but there's so much here. I think anytime a product is dependent on a Google API, long term support is uncertain. For example, recently Google dropped support for Google Docs. The copier companies have written plugins to their copiers SPECIFICALLY to work with Google Docs. So Toshiba, Konica, Canon, Ricoh... all sold commercial products to support an API that CUSTOMERS ASKED FOR, and now it's gone. Poof. Bang. Their recourse? Nil. Nada. See, Google very wisely advised everyone that they reserved the right to discontinue any or all of their API services at their own discretion, so no one has any recourse. Not the end user, not the hardware vendor. This begs the question, what recourse can any of us expect when we support a 3rd party API from ANYONE, including one of our own? Apple and Google can change their terms of service or APIs anytime they want, and can pull the rug out from under our commercial products and we are helpless. Oracle can push out a critical update to their SQL server that sqlYoga can't handle, and Trevor can say, "Yeah, no not going to update that product because I've discontinued supporting it." I'd be forced to completely refactor what is now a fairly complex app. This is the nature of software development in this pervasively connected world of ours. Perhaps a good approach is to include in any contract for software products or development the disclaimer that if the customer requests support for a 3rd party API, that functionality and support for that API is restricted to the terms of the 3rd party. Not sure how to word that legally. Bob S > On Mar 12, 2020, at 15:31 , matthias rebbe via use-livecode > wrote: > > Herman, the problems i referred to were the problems he had with a library > that did not work anymore after Google changed something and he was in urgent > need of a fix, which was not possible because Monte were at sleep at the time > of Sean´s posting and therefore he lost an important customer. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> Matthias wrote: > I did NOT refer to any personal problems. So please do not impute > such an intention to me. Sorry Matthias, I obviously misinterpreted "your problems last year". Hopefully Sean Cole didn't also misinterpret this. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> Am 12.03.2020 um 23:15 schrieb hh via use-livecode
> :
>
>
> What I woud like to see is that Sean Cole(pi digital) can write here his
> opinion without being attacked just for writing that: No content-based
> attack, but using the most nasty kind of attack, using (supposed) personal
> problems ("your problems last year").
> While content-based attacks would have been OK for me.
>
Herman, the problems i referred to were the problems he had with a library
that did not work anymore after Google changed something and he was in urgent
need of a fix, which was not possible because Monte were at sleep at the time
of Sean´s posting and therefore he lost an important customer.
I did NOT refer to any personal problems. So please do not impute such an
intention to me.
> If this is not possible, I'll better leave this list.
>
> ___
> 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> Richard G. wrote at Mike K.:
> The rest of us are having conversations with none other than the lead
> engineer, right here on this list this morning.
Yes the CTO was in the last two weeks probably more often here than in the
last two years before that two weeks. But he's now more often searching
for excuses than for real help, because there is no real progress with LCS
(except removing 9.5 bugs), LCB and HTML5.
> Help me understand: what would you like to see?
What I woud like to see is that Sean Cole(pi digital) can write here his
opinion without being attacked just for writing that: No content-based
attack, but using the most nasty kind of attack, using (supposed) personal
problems ("your problems last year").
While content-based attacks would have been OK for me.
If this is not possible, I'll better leave this list.
___
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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
it really has been, by multiple people, over multiple years. i'm not going to repeat myself, or them. ___ 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: Philosophical questions about the fontNames
On 2020-03-12 17:23, Paul Dupuis via use-livecode wrote: Yes, it does. Lacking a detailed technical understanding of the ridiculous complexity of the macOS (or Windows for that matter), is one reason we used/use HyperCard, SuperCard, MetaCard, Revolution, LiveCode for the past 25+ years for our app development. It *SEEMED* like a reasonable attempt at HIG compliance to set the fonts of our objects to the special names and also *SEEMED* like it was then reasonable to want to show what font was selected in a menu, but it is absolutely true that I was assuming that "(Text) became Segui UI on Windows and Calibri (or whatever) on macOS and NOT something like .AppleSystemUIFont! Heh - its been an interesting learning exercise for us both - both technically and process-wise :) I would stress here that this is just a reminder where failing to provide an adequate use-case when asking for something, or indeed posting a bug report about long-standing behavior which you believe should be changed is critically important. The thing is if you focus on a very specific technical detail as being the problem, and describe it as just that it 'robs' the person reading of it any context in which to make any sort of judgement from a wider point of view and perhaps short-circuit digressions into rabbit holes :) The main thing is that your code is going to be simpler as a result of this! 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
Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Mike Kerner wrote: > there is a difference between complaining and flameing > badgering over the status of qr's shouldn't be necessary. badgering > over comms shouldn't be necessary. Agreed, but there have been two posts with abstractions about "communications" and neither has expressed what exactly it is they're looking for. The rest of us are having conversations with none other than the lead engineer, right here on this list this morning. Help me understand: what would you like to see? -- 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
interesting. i didn't realize the oauth routines were in an lcs library. it's only 423 lines, and a lot of that is documentation. On Thu, Mar 12, 2020 at 4:08 PM Ralph DiMola via use-livecode < use-livecode@lists.runrev.com> wrote: > I have another type of slowdown on Win 10 that I can't get an exact recipe > for because it doesn't happen every time. Open up the stack and everything > is fast then open up the SE make some changes (no testing breakpoints used) > and the card renders and then LC hangs for 10 to 40 seconds(not > responding). > The time it hangs is directly proportional to the amount of stuff on the > card. When I tried to debug I did F11s until I reached the last "pass > opencard" the one I guess goes to the engine. Everything is fast up to that > point. Type an F11 and then LC hangs for 30 seconds before it comes back to > life. Close the SE and it's fast again. Not as fast as a fresh open but > fast > enough to put the app through its paces. Maybe related to your problem? > > Even if we can't get a recipe for all of these issues maybe all of them put > together will ring a bell at LC central? > > Ralph DiMola > IT Director > Evergreen Information Services > rdim...@evergreeninfo.net > > -Original Message- > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On > Behalf > Of Richard Gaskin via use-livecode > Sent: Thursday, March 12, 2020 2:47 PM > To: use-livecode@lists.runrev.com > Cc: Richard Gaskin > Subject: Re: OAuth2 was Re: google sheets - anybody doing anything besides > mergGoogle > > J. Landman Gay wrote: > > I wonder if the crashes are a problem with a different OS (I'm > on > Mac,) or something about your stack. I haven't had any debugging > crashes > since the fix was implemented. > ... > > I know typing can be very slow on Windows but it > isn't bad on Mac. > > I had an confounding experience last night along those lines: > > I have one project I normally run under Windows 10, and I'd found that each > time an execution error is thrown it takes several seconds for the Script > Editor to finally appear showing me the errant line. > > So I had a few spare minutes last night and figured I'd come up with a > recipe to submit a bug report, and possibly even fix it if I could find a > script bottleneck. > > No go. In a fresh stack the SE opens almost immediately, pretty much as it > does on my main Linux box and my Mac. > > So to diagnose this further I'm going to need to use my Flight Recorder > tool > (available in the Stacks section of LiveNet if interested), and log > everything going on when the SE is trying to report a bug while my client's > complex app is running. > > Because the issue isn't evident on Mac when working on the same client's > project, I'm pretty sure there's something in the Win engine that could use > some optimization. > > But given how it's only noticeable in certain projects and not others, > pinning down the root cause has not been trivial. > > This doesn't have anything to do with typing per se, but does illustrate > how > difficult it can be to pin down bottlenecks, esp. when an issue shows up in > one projects but not others. > > -- > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
I have another type of slowdown on Win 10 that I can't get an exact recipe for because it doesn't happen every time. Open up the stack and everything is fast then open up the SE make some changes (no testing breakpoints used) and the card renders and then LC hangs for 10 to 40 seconds(not responding). The time it hangs is directly proportional to the amount of stuff on the card. When I tried to debug I did F11s until I reached the last "pass opencard" the one I guess goes to the engine. Everything is fast up to that point. Type an F11 and then LC hangs for 30 seconds before it comes back to life. Close the SE and it's fast again. Not as fast as a fresh open but fast enough to put the app through its paces. Maybe related to your problem? Even if we can't get a recipe for all of these issues maybe all of them put together will ring a bell at LC central? Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Thursday, March 12, 2020 2:47 PM To: use-livecode@lists.runrev.com Cc: Richard Gaskin Subject: Re: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle J. Landman Gay wrote: > I wonder if the crashes are a problem with a different OS (I'm > on Mac,) or something about your stack. I haven't had any debugging > crashes since the fix was implemented. ... > I know typing can be very slow on Windows but it > isn't bad on Mac. I had an confounding experience last night along those lines: I have one project I normally run under Windows 10, and I'd found that each time an execution error is thrown it takes several seconds for the Script Editor to finally appear showing me the errant line. So I had a few spare minutes last night and figured I'd come up with a recipe to submit a bug report, and possibly even fix it if I could find a script bottleneck. No go. In a fresh stack the SE opens almost immediately, pretty much as it does on my main Linux box and my Mac. So to diagnose this further I'm going to need to use my Flight Recorder tool (available in the Stacks section of LiveNet if interested), and log everything going on when the SE is trying to report a bug while my client's complex app is running. Because the issue isn't evident on Mac when working on the same client's project, I'm pretty sure there's something in the Win engine that could use some optimization. But given how it's only noticeable in certain projects and not others, pinning down the root cause has not been trivial. This doesn't have anything to do with typing per se, but does illustrate how difficult it can be to pin down bottlenecks, esp. when an issue shows up in one projects but not others. -- 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
i'm kind-of annoyed. i have spent enough of my company's funds and my personal time doing lc sessions for beginners. the two years before the lc global sessions, we had a similar level of communication from hq as we do now. there is a difference between complaining and flameing badgering over the status of qr's shouldn't be necessary. badgering over comms shouldn't be necessary. badgering over roadmaps shouldn't be necessary why am i putting out rfq's, trying to find alternatives to lc? and yes, the internet doesn't forget. perhaps lc should take that to heart. we should all take that to heart with our customers. On Thu, Mar 12, 2020 at 3:36 PM prothero--- via use-livecode < use-livecode@lists.runrev.com> wrote: > Well said, Jacqueline! > Bill > > William A. Prothero > Santa Barbara, CA. 93105 > http://earthlearningsolutions.org/ > > > On Mar 12, 2020, at 11:58 AM, J. Landman Gay via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > On 3/12/20 12:39 PM, hh via use-livecode wrote: > >> The uselist is not a LC-praising list. As long as we have the freedom > of speech > >> everybody can say whether he is contented with LC or not. And nothing > written does > >> change anything*with LC*, also not your positive-only (and excellent) > posts ... > > > > Tone is important. There is difference whether the post is a discussion > of a problem, or a rant against the team and the company. Discussions are > useful and productive. A rant that attacks the dedicated people who are > doing their best for us can cause some of us to become defensive. > > > > For myself, it feels like an attack on my friends. I know these people, > how hard they work, and how much they want LC to succeed. I also know that > they are deluged with work, they need to choose their priorities carefully, > and they care very much. To date, they have met every requirement that the > shifting sands at Apple and Google have thrown at them. They need to drop > everything else to meet those deadlines, but they do it. Of course, that > puts them behind on other things. > > > > These list posts go into a permanent archive where they can discourage > others from trying LC well into the future; I see no point in making LC > look bad to any interested parties. A frank discussion is fine, readers > absolutely do need to know where traps may lie and what the current status > of the product is. But sarcasm and scathing condemnation is neither > acceptable nor productive. > > > > Basically: be kind. Think how you'd feel if what you are about to write > was directed at you. > > > > -- > > Jacqueline Landman Gay | jac...@hyperactivesw.com > > HyperActive Software | http://www.hyperactivesw.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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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: Philosophical questions about the fontNames
On 3/12/2020 3:24 PM, Richard Gaskin via use-livecode wrote: With more substantial content (web authoring, printed materials, etc.) the user cares very much, and the likelihood of ever wanting the OS-specific default font is low, so assigning your own default font explicitly would work well (even better for some apps, let the user define a default). So while I do support your request to extend "effective" to apply here (notwithstanding the considerable effort the team would need to do to figure out what the values of the OS constants refer to), I also recognize it's not a common use case. Worth supporting, IMO, but of low priority. Now, after Mark's explanation, I get it. I'll definitely go back to explicitly specifying default fonts by platform. As you know, if you do that right, because of LiveCode's inheritance, you really only need to do it for a few objects on startup. I really did go down a rabbit hole. I saw the new (something) font names, look at what I thought they were for and thought I could make code cleaner by using them. Now I know, that is not the case for my specific application. For other people or for some future App of mine they may be ideal. And, I agree with you. Of all the bugs and enhancement Curry and I have submitted in the past 6 month, making 'effective' work in this case would be near the bottom of my priority list. And yes, I expect we'll always be stuck with pain points in cross-platform UI work that NO development environment will ever make truly seamless because the OS vendors themselves try to differentiate their products by their appearance and the way the UI works (among many other factors). I can still wish it wasn't so though... I am working on a new tool requested by a customer. The crunching and analysis of the research data coding is simple compared to the UI which will probably take me 10 times as long to code and get to look and function "right" on macOS and Windows. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Well said, Jacqueline! Bill William A. Prothero Santa Barbara, CA. 93105 http://earthlearningsolutions.org/ > On Mar 12, 2020, at 11:58 AM, J. Landman Gay via use-livecode > wrote: > > On 3/12/20 12:39 PM, hh via use-livecode wrote: >> The uselist is not a LC-praising list. As long as we have the freedom of >> speech >> everybody can say whether he is contented with LC or not. And nothing >> written does >> change anything*with LC*, also not your positive-only (and excellent) posts >> ... > > Tone is important. There is difference whether the post is a discussion of a > problem, or a rant against the team and the company. Discussions are useful > and productive. A rant that attacks the dedicated people who are doing their > best for us can cause some of us to become defensive. > > For myself, it feels like an attack on my friends. I know these people, how > hard they work, and how much they want LC to succeed. I also know that they > are deluged with work, they need to choose their priorities carefully, and > they care very much. To date, they have met every requirement that the > shifting sands at Apple and Google have thrown at them. They need to drop > everything else to meet those deadlines, but they do it. Of course, that puts > them behind on other things. > > These list posts go into a permanent archive where they can discourage others > from trying LC well into the future; I see no point in making LC look bad to > any interested parties. A frank discussion is fine, readers absolutely do > need to know where traps may lie and what the current status of the product > is. But sarcasm and scathing condemnation is neither acceptable nor > productive. > > Basically: be kind. Think how you'd feel if what you are about to write was > directed at you. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.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: Philosophical questions about the fontNames
Paul Dupuis wrote: > I *do* find that cross-platform UI design and implementation to still > be the hardest thing to do in LiveCode (on a relative scale of course, > since LiveCode overall is easy) > > I would just like to be able to say in a preferences box for my app > that I am deploying to this platform and that platform and have the > LiveCode IDE or engine (or both) figure out what fonts and what sizes > everything should be to comply with the ever changing OS vendor HIGs! For the most part you do, now that the team added the "(*)" textFont directives. Your case is one where I would advocate extending "effective" to apply. I understand Mark's comments and generally support them, but like they say, exceptional circumstances require exceptional solutions. The semantic difference between object inheritance and OS inheritance is real, but far more subtle than a hundred other things already in the language, and likely lost on most new users anyway. "Give 'em the pickle". But even here, it's a relatively narrow intersection of needs: Most user-written content is either a sort of form or something more substantial. With forms, the user neither knows nor care what the font is, they just want to type. With more substantial content (web authoring, printed materials, etc.) the user cares very much, and the likelihood of ever wanting the OS-specific default font is low, so assigning your own default font explicitly would work well (even better for some apps, let the user define a default). So while I do support your request to extend "effective" to apply here (notwithstanding the considerable effort the team would need to do to figure out what the values of the OS constants refer to), I also recognize it's not a common use case. Worth supporting, IMO, but of low priority. > I constantly run into things like we make a button with a label that > fits on one platform and then on another the label is too long or a > filed is sized to display x lines on this platform but on that > platform the line sizes are different! G! It really is infuriating > at times. And not even the IDE gets it right all the time, if you run Gnome with its large default font size. I've given a lot of thought to how I might make tooling to take care of the implications of xplat font metrics on layouts. And after thinking about it a very long time, I thought better of it. :) Way too much work, and how I might decide to handle things with one control in one app will inevitably vary from how I'd handle it elsewhere. There are probably underlying design patterns we could identify for such things, and make tooling for those. But even then there will be edge cases, so we're either limiting layout options to a specific set of patterns, or raising expectations to a level that cannot be met. Personally, I don't mind so much. I make tooling where I can, and hand-craft where not. All the while I see my counterparts using other tools working even harder just for a single platform. With LC as my not-so-secret weapon, I eat them for lunch. -- 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: Philosophical questions about the fontNames
On 3/12/2020 12:22 PM, hh via use-livecode wrote: Indeed, the current implementation of (Default),(Menu),(Message),(Styled Text),(System),(Text),(Tooltip) is not very useful. For example (System) at size 13 on MacOS 10.15 is on Windows 10 at about (System) at size 12. So one needs nevertheless a platform switch. I *do* find that cross-platform UI design and implementation to still be the hardest thing to do in LiveCode (on a relative scale of course, since LiveCode overall is easy) I would just like to be able to say in a preferences box for my app that I am deploying to this platform and that platform and have the LiveCode IDE or engine (or both) figure out what fonts and what sizes everything should be to comply with the ever changing OS vendor HIGs! I constantly run into things like we make a button with a label that fits on one platform and then on another the label is too long or a filed is sized to display x lines on this platform but on that platform the line sizes are different! G! It really is infuriating at times. I would love the IDE to help, even by things like showing a bounding box for a button label that takes all platforms checked in the standalone setting into account. Fit Width seems to be platform specific. (And yes, I know that is just shifting a huge burden from me to LiveCode). Sorry, just using this thread to rant about UI building woes. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
On 3/12/20 12:39 PM, hh via use-livecode wrote: The uselist is not a LC-praising list. As long as we have the freedom of speech everybody can say whether he is contented with LC or not. And nothing written does change anything*with LC*, also not your positive-only (and excellent) posts ... Tone is important. There is difference whether the post is a discussion of a problem, or a rant against the team and the company. Discussions are useful and productive. A rant that attacks the dedicated people who are doing their best for us can cause some of us to become defensive. For myself, it feels like an attack on my friends. I know these people, how hard they work, and how much they want LC to succeed. I also know that they are deluged with work, they need to choose their priorities carefully, and they care very much. To date, they have met every requirement that the shifting sands at Apple and Google have thrown at them. They need to drop everything else to meet those deadlines, but they do it. Of course, that puts them behind on other things. These list posts go into a permanent archive where they can discourage others from trying LC well into the future; I see no point in making LC look bad to any interested parties. A frank discussion is fine, readers absolutely do need to know where traps may lie and what the current status of the product is. But sarcasm and scathing condemnation is neither acceptable nor productive. Basically: be kind. Think how you'd feel if what you are about to write was directed at you. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
J. Landman Gay wrote: > I wonder if the crashes are a problem with a different OS (I'm > on Mac,) or something about your stack. I haven't had any debugging > crashes since the fix was implemented. ... > I know typing can be very slow on Windows but it > isn't bad on Mac. I had an confounding experience last night along those lines: I have one project I normally run under Windows 10, and I'd found that each time an execution error is thrown it takes several seconds for the Script Editor to finally appear showing me the errant line. So I had a few spare minutes last night and figured I'd come up with a recipe to submit a bug report, and possibly even fix it if I could find a script bottleneck. No go. In a fresh stack the SE opens almost immediately, pretty much as it does on my main Linux box and my Mac. So to diagnose this further I'm going to need to use my Flight Recorder tool (available in the Stacks section of LiveNet if interested), and log everything going on when the SE is trying to report a bug while my client's complex app is running. Because the issue isn't evident on Mac when working on the same client's project, I'm pretty sure there's something in the Win engine that could use some optimization. But given how it's only noticeable in certain projects and not others, pinning down the root cause has not been trivial. This doesn't have anything to do with typing per se, but does illustrate how difficult it can be to pin down bottlenecks, esp. when an issue shows up in one projects but not others. -- 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
I also see the red dot misalignment (still using 9.5.1 rc 1). Since I use LC virtually every day to make changes and fixes to the app we use, I cannot really participate in DP's. Bob S > On Mar 12, 2020, at 11:17 , J. Landman Gay via use-livecode > wrote: > > On 3/11/20 9:50 PM, Sean Cole (Pi) via use-livecode wrote: >> 9.5.1 and 9.6 dp2 are still exhibiting breakpoint crashes. Not >> as often as before but, still, there are occurrences. And for some very odd >> reason an early sign it's going to become a problem I notice the line >> numbers don't scroll with the script after I've run one with a breakpoint >> that I've then stepped through - you know - so I can do my job and work out >> where bugs are. When I see this I have to close the script editor and >> reopen it to prevent it from crashing altogether - although sometimes it >> gives no warning. >> Next time I see it happening I'll do a screen recording so all can see it >> in it's glory. >> Counter to what Jacque says, it does not 'fix' itself. It persists until it >> gives up. It still crashes occasionally. > > I wonder if the crashes are a problem with a different OS (I'm on Mac,) or > something about your stack. I haven't had any debugging crashes since the fix > was implemented. > > The misalignment of the script and the red dots was the issue I thought you > were talking about. I do see that. But if I begin to step through the script > (if debugging) it rights itself. Also, I just did a quick test and scrolling > didn't change the line numbers, so that may also point to a difference in the > OS the IDE is running on. I know typing can be very slow on Windows but it > isn't bad on Mac. > > A recipe would be useful to the team. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
As to my contentedness with LC, let me say that without LC, my options would be Javascript, Python or a host of other script based languages, or else some variant of C. That is to say I would be out of options because I simply am too lazy and otherwise occupied with my real job to justify the time it would take to get "good" at any of these options. So from that perspective I am not only contented with LC, I am giddy! But then I am not producing commercial mobile apps either, and for the business I work for, anything useful I produce is icing on the cake! I am under no time constraints, or constraints of any kind! Having seen the myriad of threads on mobile app development and the pains involved, I can sympathize with anyone attempting it. The hoops RunRev has to go through to keep up is staggering to me, but let's step back for a moment and look at what mobile support for LC really is. Apart from LC (or any other non-java mobile app environment) what you would have to do is use the environment provided by Apple or Google. If you did, you would have to learn Javascript, and in the bargain you would STILL be subject to the restrictions and changes inherent to those environments. But WITH LC, you don't need to learn Javascript at all! You can use a familiar and incredibly easy to learn language in a pretty amazing GUI, and then (if all your ducks are in a row) generate a first class Mobile App. A better way to look at it might be this. Suppose Apple and Google requirements had remained static since LC first began supporting mobile apps. Would any of the obvious pains LC devs are suffering still be issues? If for the most part the answer is no, then you can see the pains are not being caused by RunRev. My 2¢ Bob S > On Mar 12, 2020, at 11:08 , hh via use-livecode > wrote: > >>> hh wrote: >>> The uselist is not a LC-praising list. As long as we have the freedom of >>> speech everybody can say whether he is contented with LC or not. >> >> Bob S. wrote: >> I was not aware we had such freedoms on this list! For instance, if I begin >> to speak of fermented dairy products, I will certainly be censured! >> And well I should be!!! > > I wonder why you want to speak of fermented dairy products in order to express > whether you are contented with LC or not. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
LC = Less Cheese ;-) Rick > On Mar 12, 2020, at 2:16 PM, Richard Gaskin via use-livecode > wrote: > > It went on for so many days Heather eventually stepped in and kindly asked us > to please stop the cheese conversation so those interested in LiveCode could > have more LC and less cheese filling their In Boxes. ___ 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
On 3/11/20 9:50 PM, Sean Cole (Pi) via use-livecode wrote: 9.5.1 and 9.6 dp2 are still exhibiting breakpoint crashes. Not as often as before but, still, there are occurrences. And for some very odd reason an early sign it's going to become a problem I notice the line numbers don't scroll with the script after I've run one with a breakpoint that I've then stepped through - you know - so I can do my job and work out where bugs are. When I see this I have to close the script editor and reopen it to prevent it from crashing altogether - although sometimes it gives no warning. Next time I see it happening I'll do a screen recording so all can see it in it's glory. Counter to what Jacque says, it does not 'fix' itself. It persists until it gives up. It still crashes occasionally. I wonder if the crashes are a problem with a different OS (I'm on Mac,) or something about your stack. I haven't had any debugging crashes since the fix was implemented. The misalignment of the script and the red dots was the issue I thought you were talking about. I do see that. But if I begin to step through the script (if debugging) it rights itself. Also, I just did a quick test and scrolling didn't change the line numbers, so that may also point to a difference in the OS the IDE is running on. I know typing can be very slow on Windows but it isn't bad on Mac. A recipe would be useful to the team. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
hh wrote: >> Bob S. wrote: >> I was not aware we had such freedoms on this list! For instance, if I >> begin to speak of fermented dairy products, I will certainly be >> censured! >> And well I should be!!! > > I wonder why you want to speak of fermented dairy products in order to > express whether you are contented with LC or not. It's a very old community in-joke: A good many years ago (more than a decade?) a thread that became contentious morphed into a very long discussion of cheese preferences, which soon became even more contentious (I leaned more about the passionate cheese preferences of my colleagues than I'd ever imagined). It went on for so many days Heather eventually stepped in and kindly asked us to please stop the cheese conversation so those interested in LiveCode could have more LC and less cheese filling their In Boxes. In the years since, "cheese" has become a comical shorthand for any longish thread not related to using or improving LC, and the only expressly verboten topic on this list. :) -- 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Bob Sneidar wrote: > I was not aware we had such freedoms on this list! For instance, if I > begin to speak of fermented dairy products, I will certainly be > censured! And well I should be!!! > > Also, and seriously, Freedom of Speech is something that is unique to > a handful of cultures. It is by no means global. Freedom of Speech is indeed a wonderful thing, but does not apply here: this list is a privately-owned communications channel that doesn't receive any funding from the US federal government. Yet despite no legal requirement to do so, the spirit of that freedom seems well embraced by the owners of this list, with unusually light moderation. And like all good freedoms this one is enjoyed equally, so even folks who have good experiences with LiveCode or seek ways issues can become actionable are allowed to speak their mind as well. Just no cheese, please. Every community has its boundaries of good taste. :) -- 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> > hh wrote: > > The uselist is not a LC-praising list. As long as we have the freedom of > > speech everybody can say whether he is contented with LC or not. > > Bob S. wrote: > I was not aware we had such freedoms on this list! For instance, if I begin > to speak of fermented dairy products, I will certainly be censured! > And well I should be!!! I wonder why you want to speak of fermented dairy products in order to express whether you are contented with LC or not. ___ 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
monte has previously said that merggoogle is using a c-library. the "need" for merggoogle is to not rewrite the existing code and/or write a new library from scratch. otherwise i wouldn't need to issue an rfq to have someone write a library. i could have it done for free. or i would be overrun with offers from n00bs to write it because it's so darn easy and i'm such a fool for paying money to have it done. yay, i can't wait for the bidding war to begin. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
I was not aware we had such freedoms on this list! For instance, if I begin to speak of fermented dairy products, I will certainly be censured! And well I should be!!! Also, and seriously, Freedom of Speech is something that is unique to a handful of cultures. It is by no means global. Bob S > The uselist is not a LC-praising list. As long as we have the freedom of > speech > everybody can say whether he is contented with LC or not. And nothing written > does > change anything *with LC*, also not your positive-only (and excellent) posts > ... > ___ 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: Philosophical questions about the fontNames
Hi Mark, > Am 12.03.2020 um 17:47 schrieb Mark Waddingham via use-livecode > : > ... > A couple of weeks ago (or maybe longer?) yep, about four weeks ago. > Klaus noticed a really strange problem with text extraction from a PDF > printed using LiveCode on macOS - specifically digits did not extract as > digits (they looked absolutely fine). [ He seemed to get quite > hot-under-the-collar-about-it, but they may have just been his Germanic > enthusiasm ;) ]. Well, yes, I only seemed to! A little WTF in the subject (I am not an american!) is definitively no indication of me being "hot-under-the-collar-about-whatsoever", THAT will look (and sound) differently. 8-) I was only very curious what had happened. OK, thanks for listening, please carry on... > ... > > Hope this helps, > > Mark. Best Klaus -- Klaus Major https://www.major-k.de kl...@major-k.de ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
+10 > On Mar 12, 2020, at 09:41 , matthias rebbe via use-livecode > wrote: > > Posting here about a real problem/bug makes sense, because others might jump > in and confirm the same experience or might help to solve the problem > As always, a good recipe, if possible, makes it even easier to reproduce it. > I very often try to reproduce problems reported here in the list to find out > if it´s a general problem/bug in LC or just a problem that occurs only at the > system of the reporter. ___ 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: Philosophical questions about the fontNames
Another approach might be to find a font or subset of fonts that looks the same on all platforms and use that. You may have to pay for the font(s) but you gain consistency. Bob S > On Mar 12, 2020, at 10:23 , Paul Dupuis via use-livecode > wrote: > > Yes, it does. Lacking a detailed technical understanding of the ridiculous > complexity of the macOS (or Windows for that matter), is one reason we > used/use HyperCard, SuperCard, MetaCard, Revolution, LiveCode for the past > 25+ years for our app development. > > It *SEEMED* like a reasonable attempt at HIG compliance to set the fonts of > our objects to the special names and also *SEEMED* like it was then > reasonable to want to show what font was selected in a menu, but it is > absolutely true that I was assuming that "(Text) became Segui UI on Windows > and Calibri (or whatever) on macOS and NOT something like .AppleSystemUIFont! > > So, we'll revert our code back to the classic conditional of: > > switch platform() >case "Win32" > set the textFont of fld "X" to "Segue UI" -- or whatever seems > appropriate > set the textFont of fld "Y" to "Segue UI" > ... set all the rest of the objects > break >case "MacOS" > set the textFont of fld "X" to "something" > > break >case "next platform" > etc. > > We went down a rabbit hole where, without knowing better, it seemed that the > above could be replaced with > > set the textFont of fld "X" to "(Text)" > set the textFont of fld "Y" to "(Text)" > etc > > and eliminate the switch statement entirely. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> > hh wrote: > > Some people are very angry about deficiencies of LC, what I can understand > > from > > their view, and *we should hear what they have to say*. > > Matthias wrote: > Why. Posting here won´t change anything. The uselist is not a LC-praising list. As long as we have the freedom of speech everybody can say whether he is contented with LC or not. And nothing written does change anything *with LC*, also not your positive-only (and excellent) posts ... > > hh wrote: > > [And, by the way, macOS 10.15 is repeating some beginner mistakes from the > > early > > MacOS X versions. Obviously a lot of beginners are currently at work there.] > > Matthias wrote: > Because people want always something new. It must be always the newest. > Because of > that the lifecycles of products and software are getting shorter and shorter > and > therefore there is less time for development and testing. But they changed methods of working things to non-working or half-way working methods (for example in Mail.app). Beginner mistakes ... ___ 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
Sean Cole wrote: > On Thu, 12 Mar 2020 at 00:17, Richard Gaskin via use-livecode < > use-livecode at lists.runrev.com> wrote: > >> I had thought the problem at that time was that your app was using >> Google's older auth method, before they switched to OAth2. > > Correct. But not the oAuth Lib directly anyway. What bothered me was > oAuth had been added but not to the Google extension. Which was odd See my other post on this from earlier today: http://lists.runrev.com/pipermail/use-livecode/2020-March/258798.html Hopefully Monte can chime in with details on that. >> The Oath2 lib is in LC's Github repository: >> >> https://github.com/livecode/livecode/blob/develop/extensions/script-libraries/oauth2/oauth2.livecodescript >> >> So now I'm confused: is OAuth2 not working in LC 9.x? > > I don't rely on any third party stuff anymore as it's out of my > control and have to wait an age before someone perhaps, maybe, some > year, updates it. Thank you for the clarification. Since we haven't seen posts about LC's Oauth2 here and searches for both "oauth" and "oauth2" turn up no bug reports in the bug DB, it seems reasonable to assume it's working well. I tend to keep third-party stuff to a minimum in deployments myself, esp. where source is not available. But the OAuth2 library is a part of the LC product, available in all editions and included in the Github repo for everyone to review. >> I'm also confused about "near silence" - Mark Waddingham has posted >> here three times this month, and it's only the 10th. He's even >> posted in the forums more frequently lately than I'm used to seeing. > > Do you mean wIth reference to progress, roadmap, where the updates are > and how far along...? Or just in response to other specific questions > and ramblings about an existing feature or somewhat? I was replying to your comment. What did you have in mind? >> As for the breakpoints crasher, I'd thought that was addressed in >> v9.1, no? > > Afraid not. 9.5.1 and 9.6 dp2 are still exhibiting breakpoint crashes. > Not as often as before but, still, there are occurrences. Thank you for confirming the breakpoint fixes in place now. If you have a recipe or a bug ID number for the remaining issue I'd be happy to see what I can do to try to steward it through completion. With many who had noted the earlier issues no longer seeing breakpoint crashes, the specific intersection of factors leading to any remaining ones may be difficult to pin down. But like all crashers I've seen before, once we have a solid recipe the fix is usually quickly delivered. -- 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: Philosophical questions about the fontNames
On 3/12/2020 12:47 PM, Mark Waddingham via use-livecode wrote: On 2020-03-12 15:53, Paul Dupuis via use-livecode wrote: So here is the simple use-case I ran into. We have a field with an editor toolbar for rich content editing in an app. The field is set to (Text) upon start up, as in: set the textFont of fld "X" to "(Text)" So that the font is initially in the appropriate default font for the platform the app is running on. In the toolbar we also have a Font pup menu with the available fonts listed for the user to change the font they want in the field. It is the UI standard that such a menu SHOW the user the currently selected font. ... If there is a good work-around for this apparent conflict, I'm definitely open to giving it a try or if I simply missed something obvious, I'm happy to be educated. I think the conflict comes from the assumption that having the default be '(Text)' (or the font underlying them) is the correct thing to do. If the field allows user-settable styling (even just font), then I'd suggest that it doesn't need to use the 'default system font for the platform' and you can just choose a sensible default - i.e. it isn't a UI text area from a HIG perspective, it is a user styled text area/document area. As a comparison, TextEdit defaults to Helvetica and WordPad defaults to Calibri or Times New Roman (depending on version I think) [ I can't remember what Notepad uses on Windows 10, something horrendously ugly and bitmap based still, probably! ] My point of view here is mainly motivated by the following... A couple of weeks ago (or maybe longer?) Klaus noticed a really strange problem with text extraction from a PDF printed using LiveCode on macOS - specifically digits did not extract as digits (they looked absolutely fine). [ He seemed to get quite hot-under-the-collar-about-it, but they may have just been his Germanic enthusiasm ;) ]. Changing the font to Courier or Arial solved the problem - digits could be copied as digits again. It wasn't until I ran an internal tool I wrote for Kognition many moons ago on the generated PDF that I figured out what the cause was. The effective font of the offending field was '(System)' - this came out in the PDF as '.SFNSText'. (Note: I still don't quite know why it munges digits - my guess is that it doesn't have a traditional CMAP table). This is a font you won't find listed in the fontNames, nor (I don't think) In FontBook or anywhere else. It is a seemingly highly specialized and custom crafted font designed only for screen display in the macOS UI. Indeed, if I interrogate the NSFont object we get internally when requesting the font for (Text), I get '.AppleSystemUIFont' - which is similarly not appropriate for what you want. TL;DR version: Theme fonts '(...)' should only be used for 'fixed' UI display - they won't print in the same way and cannot be chosen in the same way by name. For text that might be printed, or where the font can be chosen by the user, you should choose sensible default fonts similar to those of the basic apps for styled text entry on the platform the program is running on. Hope this helps, Yes, it does. Lacking a detailed technical understanding of the ridiculous complexity of the macOS (or Windows for that matter), is one reason we used/use HyperCard, SuperCard, MetaCard, Revolution, LiveCode for the past 25+ years for our app development. It *SEEMED* like a reasonable attempt at HIG compliance to set the fonts of our objects to the special names and also *SEEMED* like it was then reasonable to want to show what font was selected in a menu, but it is absolutely true that I was assuming that "(Text) became Segui UI on Windows and Calibri (or whatever) on macOS and NOT something like .AppleSystemUIFont! So, we'll revert our code back to the classic conditional of: switch platform() case "Win32" set the textFont of fld "X" to "Segue UI" -- or whatever seems appropriate set the textFont of fld "Y" to "Segue UI" ... set all the rest of the objects break case "MacOS" set the textFont of fld "X" to "something" break case "next platform" etc. We went down a rabbit hole where, without knowing better, it seemed that the above could be replaced with set the textFont of fld "X" to "(Text)" set the textFont of fld "Y" to "(Text)" etc and eliminate the switch statement entirely. set ___ 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: Philosophical questions about the fontNames
On 2020-03-12 15:53, Paul Dupuis via use-livecode wrote: So here is the simple use-case I ran into. We have a field with an editor toolbar for rich content editing in an app. The field is set to (Text) upon start up, as in: set the textFont of fld "X" to "(Text)" So that the font is initially in the appropriate default font for the platform the app is running on. In the toolbar we also have a Font pup menu with the available fonts listed for the user to change the font they want in the field. It is the UI standard that such a menu SHOW the user the currently selected font. ... If there is a good work-around for this apparent conflict, I'm definitely open to giving it a try or if I simply missed something obvious, I'm happy to be educated. I think the conflict comes from the assumption that having the default be '(Text)' (or the font underlying them) is the correct thing to do. If the field allows user-settable styling (even just font), then I'd suggest that it doesn't need to use the 'default system font for the platform' and you can just choose a sensible default - i.e. it isn't a UI text area from a HIG perspective, it is a user styled text area/document area. As a comparison, TextEdit defaults to Helvetica and WordPad defaults to Calibri or Times New Roman (depending on version I think) [ I can't remember what Notepad uses on Windows 10, something horrendously ugly and bitmap based still, probably! ] My point of view here is mainly motivated by the following... A couple of weeks ago (or maybe longer?) Klaus noticed a really strange problem with text extraction from a PDF printed using LiveCode on macOS - specifically digits did not extract as digits (they looked absolutely fine). [ He seemed to get quite hot-under-the-collar-about-it, but they may have just been his Germanic enthusiasm ;) ]. Changing the font to Courier or Arial solved the problem - digits could be copied as digits again. It wasn't until I ran an internal tool I wrote for Kognition many moons ago on the generated PDF that I figured out what the cause was. The effective font of the offending field was '(System)' - this came out in the PDF as '.SFNSText'. (Note: I still don't quite know why it munges digits - my guess is that it doesn't have a traditional CMAP table). This is a font you won't find listed in the fontNames, nor (I don't think) In FontBook or anywhere else. It is a seemingly highly specialized and custom crafted font designed only for screen display in the macOS UI. Indeed, if I interrogate the NSFont object we get internally when requesting the font for (Text), I get '.AppleSystemUIFont' - which is similarly not appropriate for what you want. TL;DR version: Theme fonts '(...)' should only be used for 'fixed' UI display - they won't print in the same way and cannot be chosen in the same way by name. For text that might be printed, or where the font can be chosen by the user, you should choose sensible default fonts similar to those of the basic apps for styled text entry on the platform the program is running on. Hope this helps, 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
Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> Am 12.03.2020 um 17:08 schrieb hh via use-livecode > : > > Some people are very angry about deficiencies of LC, what I can understand > from > their view, and *we should hear what they have to say*. > Why. Posting here won´t change anything. > Especially when they get angry about the whitewashing of bugs by some list > members. > Currently i am not aware of that. I must have missed such discussions on this list. But i am sure there were such discussions otherwise you wouldn´t write it. When a bug is confirmed in the bugbase, no one can whitewash it. When it´s confirmed then it´s confirmed. Posting here about a real problem/bug makes sense, because others might jump in and confirm the same experience or might help to solve the problem As always, a good recipe, if possible, makes it even easier to reproduce it. I very often try to reproduce problems reported here in the list to find out if it´s a general problem/bug in LC or just a problem that occurs only at the system of the reporter. But just moaning here in the list about deficiencies does not make sense to me. What should that do? No one can help. > What's wrong that's wrong, no matter who tries to whitewash bugs or even > tries to > keep quiet about (remaining) bugs. The latter is, compared to the promises of > the > LC main page, more harmful for the reputation of LC than telling the truth. > > And what's good with LC that's good. We too tell the truth with that. > > [And, by the way, macOS 10.15 is repeating some beginner mistakes from the > early > MacOS X versions. Obviously a lot of beginners are currently at work there.] Because people want always something new. It must be always the newest. Because of that the lifecycles of products and software are getting shorter and shorter and therefore there is less time for development and testing. > ___ > 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: Philosophical questions about the fontNames
Thanks for chiming in, Mark. Would it be helpful to have a bug report on this, or should I wait to see what you find in your code review? -- Richard Gaskin Fourth World Systems Mark Waddingham wrote: On 2020-03-11 22:36, Richard Gaskin via use-livecode wrote: Querying the fontNames includes: (Default) (Styled Text) (Menu) (Text) (Message) (Tooltip) (System) These are not font names, but constants the engine accepts so that we can have good-looking, HIG-savvy UIs on multiple platforms. But they're not font names. They're not fonts at all. They're engine directives. So should they be included in the fontNames? (Yes, I know I can exclude them. I've been doing this a while, I can do lots of things. But if a newcomer wants to make a Fonts menu or list she also needs to know the filter command, and why she needs to use it to filter out things that aren't fonts. #learnability) Haha - I noticed that at the top of Richmond's screenshot on the forums and I had the same thought... I also had a sneaky suspicion you would also comment on it! I am inclined to agree with you - those font names are added explicitly after fetching the list of font names from the system - so there isn't a deeply technical reason why they are there. I'll need to dig back to see if there is any internal discussion about it from when the theme support was added. After all, it is useful for the IDE to have those in the list, but it is also easy for it to add them in its own code! For all intents and purposes, they should never appear in a 'user-settable' font list in any non-UI editing type application - so the impact of changing it is probably next to zero. Warmest Regards, Mark. ___ 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
Mike Kerner wrote: > 6. there doesn't seem to be any interest in updating merggoogle. It'll be good to hear from Monte on this, but I'd guess the reason merGoogle isn't actively supported is because the meat of it is handling authentication, and the REST API itself if pretty straightforward. Now that Google requires OAuth2 (they stopped supporting their earlier auth), and LC has the actively-supported OAuth2 library in all editions, there would seem little need for merGoogle, esp. since the OAuth2 lib works on all supported platforms. Monte, is this correct? -- 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: Philosophical questions about the fontNames
Indeed, the current implementation of (Default),(Menu),(Message),(Styled Text),(System),(Text),(Tooltip) is not very useful. For example (System) at size 13 on MacOS 10.15 is on Windows 10 at about (System) at size 12. So one needs nevertheless a platform switch. ___ 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: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
Some people are very angry about deficiencies of LC, what I can understand from their view, and *we should hear what they have to say*. Especially when they get angry about the whitewashing of bugs by some list members. What's wrong that's wrong, no matter who tries to whitewash bugs or even tries to keep quiet about (remaining) bugs. The latter is, compared to the promises of the LC main page, more harmful for the reputation of LC than telling the truth. And what's good with LC that's good. We too tell the truth with that. [And, by the way, macOS 10.15 is repeating some beginner mistakes from the early MacOS X versions. Obviously a lot of beginners are currently at work there.] ___ 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: Philosophical questions about the fontNames
On 3/12/2020 3:46 AM, Mark Waddingham via use-livecode wrote: On 2020-03-11 23:38, Paul Dupuis via use-livecode wrote: I filled a bug report on this back in February: https://quality.livecode.com/show_bug.cgi?id=22564 Mark Waddingham declared it was not a bug but a documentation issue, so I filed and enhancement request: https://quality.livecode.com/show_bug.cgi?id=22569 Personally, I think the following code SHOULD work: set the textFont of fld "X" to "(Text)" put the effective textFont of fld "X" And return the actual font used for (Text) on the current platform (for example Segue UI on Windows 10. My goal was to be able to read somewhere like in the dictionary or user guide or run some code to find out what the actual font is for each of the "specials" on Windows and macOS. To be accurate, your request / report is entirely different from Richard's philosophical question. True. I thought is was on the same topic though, so I responded. You want 'the effective fontName' of a chunk / object to return the actual name of the font which the system is using to render the glyphs - which would be huge departure from its current (very LC-specific) meaning. Also I did not declare it a documentation issue (because it is not). My exact wording was: "I suspect it is possible to get the names of the actual system-provided fonts - but there is no facility in LiveCode for this at present. Please file an enhancement request for this ability." My apology for mis-characterizing what you said. Yes, I interpreted that a "enhancement" for what I wanted, could be delivered by a documentation request and I thought that documenting the fonts corresponding to the fontNames engine directives would be easier that any sort of technical change to the engine - another assumption based on observation of the rate of documentation fixes vs the rate of engine technical fixes. Both are impressive for the size of the team, but doc fixes do seem to out pace technical changes since they are generally easier. This is precisely because the mapping is not fixed. Both Windows and Linux allow the user to change the relevant fonts used at the system level, and macOS uses highly-specialized UI fonts for the purpose (as Klaus and I recently discovered when he was having a problem with text extraction from PDFs printed from LC!). True, and this point negates that a documentation approach would solve what I was looking for. So, my bad for being short sighted in asking for a documentation enhancement. That was a mistake, and I see that now. My current point of view is that this need represents an edge-case, and it is more than likely that changing your approach to whatever it is you believe you need it for means you won't... So, an important question is here why do you need to know the actual font being used when an object is set to render with one of the meta-(theme)- fonts? So here is the simple use-case I ran into. We have a field with an editor toolbar for rich content editing in an app. The field is set to (Text) upon start up, as in: set the textFont of fld "X" to "(Text)" So that the font is initially in the appropriate default font for the platform the app is running on. In the toolbar we also have a Font pup menu with the available fonts listed for the user to change the font they want in the field. It is the UI standard that such a menu SHOW the user the currently selected font. My problem, if I try to follow platfrom UI guidelines by setting the text field's font to (Text), I then can not - say get the effective textFont of fld "X" - to find out which Fontname in the UI standard popup font menu should be checked as the current font. Now in the scheme of our own list of App bugs to fix and enhancements to build, whether the Font menu precisely corresponds to UI standards or not is not at the top of our list, but it still would have been nice not to have conflicting UI standards issues: Using textFont = (Text) gets me the appropriate fonts by platform, but then I can show what the selected font for the field is in a standard UI font menu. If there is a good work-around for this apparent conflict, I'm definitely open to giving it a try or if I simply missed something obvious, I'm happy to be educated. ___ 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: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle
see the rfq i posted. there are a variety of issues in merggoogle 1. mac/ios only 2. doesn't seem to work in newer versions of lc for some reason (works in 9.0.1, for instance, but not in 9.5.x) 3. google is going to shut off...something...that merggoogle is using in september. i don't know what that is, but i get emails from google telling me that i'm using a deprecated api that is going to be nuked in six months. the only place that i could possibly be using that api is merggoogle 4. we have had to include a lot of error trapping code because merggoogle somehow gets out of step with google, which breaks the process, and it is impossible to debug because of the way merggoogle works (you can't see all the raw traffic). so for example, we might say "load a worksheet", and instead we will get a message that the list of spreadsheets is loaded. the problem with that is that there is no way to recover once that happens, and you have to start over. there are multiple bug reports on this particular issue, but the workaround was a lot of workaround code to specifically ensure that the sequence occurs as expected. 5. the rest api seems like it has more features 6. there doesn't seem to be any interest in updating merggoogle. On Wed, Mar 11, 2020 at 4:46 PM Ben Rubinstein via use-livecode < use-livecode@lists.runrev.com> wrote: > Hi Mike, > > I haven't forgotten, but finally found time to take a look today and > started > writing minimal comments, and thought I should at least test it - for some > reason the authorisation isn't working. For whatever reason, the call to > OAuth2 results in the error "Malformed auth code." So I can't get to test > what > I'm sending. > > I'm unclear whether I've done something strange or wrong, or whether > Google > has changed something that breaks LC's implementation. I've come across > references which suggest that, but they date back to last year, and I > believe > I've used this stack in January. (I also tried using LC 9.0.4 with the > same > result.) > > I will try to get back to this. In the meantime, have you - or anyone - > found > issues recently with OAuth2, in particular against any of the Google APIs? > > Ben > > > On 08/03/2020 22:22, Mike Kerner via use-livecode wrote: > > it might help us get started. i'm going to probably put out an rfq to > wrap > > the v4 rest api, because we're going to have to come to a solution, > either > > using lc or some other tool. > > > > On Sun, Mar 8, 2020 at 6:01 PM Ben Rubinstein via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> Mike, > >> > >> Very happy to share what I've got, but it's really not much - just a > very > >> thin > >> wrapper round Google's API - and it's undocumented, mostly rough code - > >> copied > >> from one stack to the next, usually done in a tearing hurry! > >> > >> I'll try to pull something together, but please promise not to judge > me... > >> > >> Ben > >> > >> On 06/03/2020 15:13, Mike Kerner via use-livecode wrote: > >>> Ben, > >>> would you send me what you've got? I was considering paying someone to > >>> wrap the entire v4 api and dropping mergGoogle, so any head start would > >> be > >>> useful. LC wants tribute to do the work (which is a little > disappointing > >>> since we financed the original external, so we sort-of hoped that it > >> would > >>> become a thing, and it would get updated as required, but crap > happens). > >>> > >>> On Thu, Mar 5, 2020 at 6:04 PM Ben Rubinstein via use-livecode < > >>> use-livecode@lists.runrev.com> wrote: > >>> > On 04/03/2020 20:37, Mike Kerner via use-livecode wrote: > > is anyone using anything besides mergGoogle to work with google > sheets? > > care to share, if you are? > > I'm just using the Google Sheets API directly from LiveCode - just > >> pushing > JSON back and forth. The API is limited, but what's there is very easy > >> to > work > with - much better than manipulating xlsx files. > > I started using it to get data from clients, and then processing data > >> and > pushing it back into the sheets. I've also used on some experimental > >> image > processing, where I found that pushing the results of LiveCode > functions > into > a google sheet immediately gave me an nice interface in which to > review > the > data, and then I could also use the spreadsheet functions to do > >> evaluation > and > testing. > > Ben > > > > ___ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good."
Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???
> Am 12.03.2020 um 01:08 schrieb Sean Cole (Pi) via use-livecode > : > > Tired and ill. My business is constantly lagging behind my competitors > because we're always on the backfoot waiting for LC to frikin' work! I'm > going to end up losing all my new customers again since the last LC epic > fail. Why do they keep doing this to me? They do it not just to you. ;) Please don´t take it personally, but repeating your discontent here in the list about LC, the development cycle and how LC Ltd. is doing things does not help at all. If you are unsatisfied, then why not writing directly to LC Ltd. What do you expect with your posts? Your posts could even scare potential new paying customers. Remember, the internet does not forget... I understand your personal situation, especially after your problems last year, but such posts do not help. Just my 2 cents. All the best, Matthias ___ 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: Philosophical questions about the fontNames
On 2020-03-11 22:36, Richard Gaskin via use-livecode wrote: Querying the fontNames includes: (Default) (Styled Text) (Menu) (Text) (Message) (Tooltip) (System) These are not font names, but constants the engine accepts so that we can have good-looking, HIG-savvy UIs on multiple platforms. But they're not font names. They're not fonts at all. They're engine directives. So should they be included in the fontNames? (Yes, I know I can exclude them. I've been doing this a while, I can do lots of things. But if a newcomer wants to make a Fonts menu or list she also needs to know the filter command, and why she needs to use it to filter out things that aren't fonts. #learnability) Haha - I noticed that at the top of Richmond's screenshot on the forums and I had the same thought... I also had a sneaky suspicion you would also comment on it! I am inclined to agree with you - those font names are added explicitly after fetching the list of font names from the system - so there isn't a deeply technical reason why they are there. I'll need to dig back to see if there is any internal discussion about it from when the theme support was added. After all, it is useful for the IDE to have those in the list, but it is also easy for it to add them in its own code! For all intents and purposes, they should never appear in a 'user-settable' font list in any non-UI editing type application - so the impact of changing it is probably next to zero. 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
Re: Philosophical questions about the fontNames
On 2020-03-11 23:38, Paul Dupuis via use-livecode wrote: I filled a bug report on this back in February: https://quality.livecode.com/show_bug.cgi?id=22564 Mark Waddingham declared it was not a bug but a documentation issue, so I filed and enhancement request: https://quality.livecode.com/show_bug.cgi?id=22569 Personally, I think the following code SHOULD work: set the textFont of fld "X" to "(Text)" put the effective textFont of fld "X" And return the actual font used for (Text) on the current platform (for example Segue UI on Windows 10. My goal was to be able to read somewhere like in the dictionary or user guide or run some code to find out what the actual font is for each of the "specials" on Windows and macOS. To be accurate, your request / report is entirely different from Richard's philosophical question. You want 'the effective fontName' of a chunk / object to return the actual name of the font which the system is using to render the glyphs - which would be huge departure from its current (very LC-specific) meaning. Also I did not declare it a documentation issue (because it is not). My exact wording was: "I suspect it is possible to get the names of the actual system-provided fonts - but there is no facility in LiveCode for this at present. Please file an enhancement request for this ability." This is precisely because the mapping is not fixed. Both Windows and Linux allow the user to change the relevant fonts used at the system level, and macOS uses highly-specialized UI fonts for the purpose (as Klaus and I recently discovered when he was having a problem with text extraction from PDFs printed from LC!). My current point of view is that this need represents an edge-case, and it is more than likely that changing your approach to whatever it is you believe you need it for means you won't... So, an important question is here why do you need to know the actual font being used when an object is set to render with one of the meta-(theme)- fonts? 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
