Re: Maximum field height?
Hi Jacque, Scott made many of the same good points as you did - so I won't replicate my replies here. On 06/04/2020 05:20, J. Landman Gay via use-livecode wrote: On April 5, 2020 8:39:15 PM Alex Tweedly via use-livecode wrote: 1. xTalk features just don't work, or work totally inadequately (e.g. scrolling fields). Somewhat true. LC made a start by adding widgets you can drop onto the stack to create native mobile buttons and fields, but I'd like to see regular LC controls magically change to native mobile controls much as the Mac, Windows, and (sort of) Linux appearances do. That would make a world of difference. Yes !! But there are features on mobile that don't exist on desktop. LC has provided for things like Android toasts and iOS popups. These things are one reason the language can't be entirely universal; mobile requires a different feature set. But it would be great if a scrolling field would just be a scrolling field everywhere. On the other hand, mobile lets you scroll all sorts of things (images, carousels, etc.) so we'd still need our mobile scroller anyway. Same response to that as I have to mobilePick, mobilePickDate, etc. Why shouldn't they exist on desktop - if they're useful features for a good UI, why would LC not want to add them for desktop. I agree it could be easier, but it isn't impossible. But parity wherever possible would be my first choice in what I'd like to see improved. 2. Failure in cross-platform equivalence. If you mean mobile equivalence, Android is catching up quickly, in part because of the FM initiative. I appreciate that. iOS is pretty well covered for the most part. Some folks mentioned the issue of branching for different mobile platforms but that doesn't bother me much. We have to do that sometimes for the three desktop platforms already. The features that both iOS and Android do have in common use the same code and syntax. I mean that, but for all platforms. If there is a common piece of UI functionality (e.g. pick a date) then abstract that out to a library function (in the box - not one we each create separately and slightly differently), and have it use the appropriate platform method. And if that means we finally get a pickDate widget on desktop then I'd say "about time" (and ask for a pickTime function as well :-) The other two are, I suspect, not truly solvable. 3. It's not "Live"Code. Developing for Mobile gets you back into the horrible edit - compile (i.e. build a standalone) - test cycle. Yeah, this is a pain. I'm not sure there's any way around it but the addition of remote debugging has made it far easier. For a long time I felt like I was back in 1998 where I had to sprinkle "answer" dialogs all over the place just to know what my variable values were. There are some tricks though that help. I created a generic launcher app that loads my working stack so there's no actual compile required. I can't do this for complex apps, but I can do it for testing pieces and bits that will eventually go into the main app later. For simpler apps, the entire stack can be tested pretty easily this way. Great. Now why didn't LC create a Launcher app like that so that everyone (esp new users) can use it, one that runs in a standard way so we can easily communicate about it - and is documented. 4. You still need to deal with the ugly issues of the SDKs and the app-store requirements. For me this is the hardest part, way worse than developing the app itself. It's also why I'd much rather deal with Android than Apple. Google is pretty easy to deal with. Apple is a constantly moving target with a rollercoaster of requirements, not to mention the profiles and certificates and what seems to me to be an unnecessarily complex review process. Yes, but even getting the Android SDK seems to be (still) troublesome. I know it took me (literally) days way back when - it does seem to be better documented now, but apparently not quite straightforward. However, if you are just developing for yourself or a few other people, you don't have to mess with either app store. Android apps can be freely distributed to anyone by any method and you don't even need a Google account. iOS apps can be distributed to a few people as "testers" without going through their byzantine submission process, though you do still need to mess with their account, certificates and profiles. I'm thankful that the LC team keeps up with Apple's constantly changing requirements. Apple doesn't seem to value their developers much. So, for me personally, even if LC Ltd. could fix (1) and (2), I would still not even bother trying to build a mobile app; it's just not worth the hassle or the learning curve. It isn't such a steep learning curve as you'd think. One test app will probably get you going. If I were starting over, I'd start with Android because it's so much more flexible. The hardest part there is just
Re: Maximum field height?
Bob Sneidar wrote: > I’m curious though if a library could be created so that a handler for > a mobile message (let’s say a touch message) could “translate” into a > desktop message? In this way, the app on the mobile would send a > mouseUp message to the target. Why not? Most developers I know do exactly that. We all rewrite the same library, over and over, because it isn't in the box. Newcomers will not know to do this, or how. -- 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: Maximum field height?
Touch messages already send duplicate mouse messages. In fact, unless you need two-finger zooming, you don't need touch handlers at all. I only use standard mouse handlers generally because they wotk on both mobile and desktop. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On April 6, 2020 10:02:19 AM Bob Sneidar via use-livecode wrote: There’s the rub I think. For RunRev (is the company still called that?) to make what mobile objects they can universal, and leave the others as is would then create a situation where developers would have to know what controls were universal, and which were Mobile/Desktop only. It just adds another layer of complexity. I’m curious though if a library could be created so that a handler for a mobile message (let’s say a touch message) could “translate” into a desktop message? In this way, the app on the mobile would send a mouseUp message to the target. Seems crazy I know. I’m just Pea Brain Storming. Bob S On Apr 5, 2020, at 9:20 PM, J. Landman Gay via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: But there are features on mobile that don't exist on desktop. LC has provided for things like Android toasts and iOS popups. These things are one reason the language can't be entirely universal; mobile requires a different feature set. But it would be great if a scrolling field would just be a scrolling field everywhere. On the other hand, mobile lets you scroll all sorts of things (images, carousels, etc.) so we'd still need our mobile scroller anyway. ___ 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: Maximum field height?
I think that would kill the Apple Desktop OS. Bob S On Apr 6, 2020, at 6:37 AM, Paul Dupuis via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Apple is absolutely working towards iOS and macOS being highly similar. However, if you're hoping that brings increased simplicity of application development to iOS, that isn't Apple's aim. The value to them of unification is to get macOS app into the same exclusivity an app store as iOS. Currently deployment of macOS apps can be through the macOS App store or outside of it. iOS app must be through the App store. Apple wants to gradually migrate the macOS base to the point where they can say macOS apps will only be available through the App store as well. Then they can drive the same developer changes on OSX that they do on iOS and take their same 30% cut. ___ 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: Maximum field height?
There’s the rub I think. For RunRev (is the company still called that?) to make what mobile objects they can universal, and leave the others as is would then create a situation where developers would have to know what controls were universal, and which were Mobile/Desktop only. It just adds another layer of complexity. I’m curious though if a library could be created so that a handler for a mobile message (let’s say a touch message) could “translate” into a desktop message? In this way, the app on the mobile would send a mouseUp message to the target. Seems crazy I know. I’m just Pea Brain Storming. Bob S On Apr 5, 2020, at 9:20 PM, J. Landman Gay via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: But there are features on mobile that don't exist on desktop. LC has provided for things like Android toasts and iOS popups. These things are one reason the language can't be entirely universal; mobile requires a different feature set. But it would be great if a scrolling field would just be a scrolling field everywhere. On the other hand, mobile lets you scroll all sorts of things (images, carousels, etc.) so we'd still need our mobile scroller anyway. ___ 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: Maximum field height?
On 4/5/2020 10:48 PM, JB via use-livecode wrote: The question is why don’t they make them compatible? Is their some kind of FCC regulation that prevents Apple from using phone apps on the desktop? Back in the HyperCard days there was hyperDialer and I really liked it a lot but I think the company was blocked from using it by the phone companies or something like that. Anyway there are no replacements and I haven’t seen any others that survived so there is a reason the desktop does not have simple phone capabilities. Apple is absolutely working towards iOS and macOS being highly similar. However, if you're hoping that brings increased simplicity of application development to iOS, that isn't Apple's aim. The value to them of unification is to get macOS app into the same exclusivity an app store as iOS. Currently deployment of macOS apps can be through the macOS App store or outside of it. iOS app must be through the App store. Apple wants to gradually migrate the macOS base to the point where they can say macOS apps will only be available through the App store as well. Then they can drive the same developer changes on OSX that they do on iOS and take their same 30% cut. ___ 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: Maximum field height?
On April 5, 2020 8:39:15 PM Alex Tweedly via use-livecode wrote: 1. xTalk features just don't work, or work totally inadequately (e.g. scrolling fields). Somewhat true. LC made a start by adding widgets you can drop onto the stack to create native mobile buttons and fields, but I'd like to see regular LC controls magically change to native mobile controls much as the Mac, Windows, and (sort of) Linux appearances do. That would make a world of difference. But there are features on mobile that don't exist on desktop. LC has provided for things like Android toasts and iOS popups. These things are one reason the language can't be entirely universal; mobile requires a different feature set. But it would be great if a scrolling field would just be a scrolling field everywhere. On the other hand, mobile lets you scroll all sorts of things (images, carousels, etc.) so we'd still need our mobile scroller anyway. I agree it could be easier, but it isn't impossible. But parity wherever possible would be my first choice in what I'd like to see improved. 2. Failure in cross-platform equivalence. If you mean mobile equivalence, Android is catching up quickly, in part because of the FM initiative. I appreciate that. iOS is pretty well covered for the most part. Some folks mentioned the issue of branching for different mobile platforms but that doesn't bother me much. We have to do that sometimes for the three desktop platforms already. The features that both iOS and Android do have in common use the same code and syntax. The other two are, I suspect, not truly solvable. 3. It's not "Live"Code. Developing for Mobile gets you back into the horrible edit - compile (i.e. build a standalone) - test cycle. Yeah, this is a pain. I'm not sure there's any way around it but the addition of remote debugging has made it far easier. For a long time I felt like I was back in 1998 where I had to sprinkle "answer" dialogs all over the place just to know what my variable values were. There are some tricks though that help. I created a generic launcher app that loads my working stack so there's no actual compile required. I can't do this for complex apps, but I can do it for testing pieces and bits that will eventually go into the main app later. For simpler apps, the entire stack can be tested pretty easily this way. 4. You still need to deal with the ugly issues of the SDKs and the app-store requirements. For me this is the hardest part, way worse than developing the app itself. It's also why I'd much rather deal with Android than Apple. Google is pretty easy to deal with. Apple is a constantly moving target with a rollercoaster of requirements, not to mention the profiles and certificates and what seems to me to be an unnecessarily complex review process. However, if you are just developing for yourself or a few other people, you don't have to mess with either app store. Android apps can be freely distributed to anyone by any method and you don't even need a Google account. iOS apps can be distributed to a few people as "testers" without going through their byzantine submission process, though you do still need to mess with their account, certificates and profiles. I'm thankful that the LC team keeps up with Apple's constantly changing requirements. Apple doesn't seem to value their developers much. So, for me personally, even if LC Ltd. could fix (1) and (2), I would still not even bother trying to build a mobile app; it's just not worth the hassle or the learning curve. It isn't such a steep learning curve as you'd think. One test app will probably get you going. If I were starting over, I'd start with Android because it's so much more flexible. The hardest part there is just making sure you download the right SDK and Java version. OK - that's an easy decision for me - I don't do this for a living, I do it for fun. And right now Mobile development is no fun. It could be improved, but it isn't not-fun. It's just software development like anything else. As you say, I don't have much choice. I haven't really done a desktop app for a couple of years now, clients want mobile and mobile only. Desktop apps are going away. My main client deals in university software and half the students don't even own a computer any more, they do everything on their tablets or phones. I found that LC Android apps also run pretty well on Chromebooks, even though LC doesn't officially support those, and if students own a laptop at all, it's likely to be a Chromebook these days. They're cheap and fast and essentially immune to malware. When we only distributed desktop apps, students complained that they had to go to the school's computer lab because they didn't have a laptop. The downside is, I've all but run out of reasons to develop in LC. That would be a shame. You already have the skills, and aside from a few, but not all, mobile controls, the rest of it
Re: Maximum field height?
It seems if Apple made the iOS compatible with the desktop it would solve a lot of problems. The question is why don’t they make them compatible? Is their some kind of FCC regulation that prevents Apple from using phone apps on the desktop? Back in the HyperCard days there was hyperDialer and I really liked it a lot but I think the company was blocked from using it by the phone companies or something like that. Anyway there are no replacements and I haven’t seen any others that survived so there is a reason the desktop does not have simple phone capabilities. JB > On Apr 5, 2020, at 6:37 PM, Alex Tweedly via use-livecode > wrote: > > As I see it, there are 4 broad areas of problem for LC on mobile OSes. > > The first two have been well described earlier in the thread and should just > be fixed. > > 1. xTalk features just don't work, or work totally inadequately (e.g. > scrolling fields). > > 2. Failure in cross-platform equivalence. > > The other two are, I suspect, not truly solvable. > > 3. It's not "Live"Code. Developing for Mobile gets you back into the horrible > edit - compile (i.e. build a standalone) - test cycle. > > 4. You still need to deal with the ugly issues of the SDKs and the app-store > requirements. > > So, for me personally, even if LC Ltd. could fix (1) and (2), I would still > not even bother trying to build a mobile app; it's just not worth the hassle > or the learning curve. > > OK - that's an easy decision for me - I don't do this for a living, I do it > for fun. And right now Mobile development is no fun. > > The downside is, I've all but run out of reasons to develop in LC. I used to > write little (but useful) apps/games/utilities for myself, or my family, or > sometimes for friends. I don't think my wife's laptop has been switched on > this year - she uses her tablet and/or phone almost exclusively. And others > in the family are much the same. > > So I think the right solution is for LC Ltd is to add *another* target > platform - PWAs. (This has the advantage that it also tackles the inadequacy > of the HTML platform). > > LC Ltd should just pick a set of PWA components (I don't know which - maybe > Angular, Polymer, etc. I *really* don't know which - but just pick one for me > !!). Then they should identify a *subset* of LC script/UI features that can > be readily mapped to JS and a LC/JS library, and implement that. > > Given the ability to re-load JS it should be feasible to be (fairly) > "Live"Code, without a full stand-alone build step. It should produce > fast-loading, small "apps" that would allow many fairly straightforward apps > to be developed easily - bringing Mobile development back into the realm > where new / naive users (that includes me) can readily develop apps and run > them on the devices we all use these days. > > And I'd get to stick to LC :-) > > Alex. > > On 05/04/2020 21:53, Curry Kenworthy via use-livecode wrote: >> >> Agreed!!! I had grown weary of endless arguments previously pushing back >> against most LC critiques while the wagons were circled, so very glad to see >> this frankly discussed now. >> >> "Live" Code. Meaning: WYSIWYG between dev and runtime, no edit-compile-run >> cycle, much more efficient. Remember the marketing? For us the Users, it >> wasn't just marketing. It was real, and it was the reason and the >> empowerment. We lived it and used it. Still do on desktop. >> >> But LC has never been "Live" Code on mobile platforms. A big fail. Not just >> the UI, but also the mobileBlahBlah keywords that must be placed in if/then >> branches to avoid runtime errors on desktop whereas they should have been >> designed pan-platform. When these first appeared I was hoping they were >> temporary. Instead they've grown and multiplied, setting an arguably bad >> trend for the future. >> >> That was a huge design flaw or design mistake/bad decision for a product >> called "Live" Code. LC Ltd needs to understand and embrace some key >> characteristics of its own product. It's not just marketing, and it's not a >> HyperCard "Boomer" fad that will (or should) die out demographically with >> younger coders. It's valid, there's a reason, and it's so important. >> >> How's that for a "second"? :) >> >> Best wishes, >> >> Curry Kenworthy >> >> Custom Software Development >> "Better Methods, Better Results" >> LiveCode Training and Consulting >> http://livecodeconsulting.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: >
Re: Maximum field height?
As I see it, there are 4 broad areas of problem for LC on mobile OSes. The first two have been well described earlier in the thread and should just be fixed. 1. xTalk features just don't work, or work totally inadequately (e.g. scrolling fields). 2. Failure in cross-platform equivalence. The other two are, I suspect, not truly solvable. 3. It's not "Live"Code. Developing for Mobile gets you back into the horrible edit - compile (i.e. build a standalone) - test cycle. 4. You still need to deal with the ugly issues of the SDKs and the app-store requirements. So, for me personally, even if LC Ltd. could fix (1) and (2), I would still not even bother trying to build a mobile app; it's just not worth the hassle or the learning curve. OK - that's an easy decision for me - I don't do this for a living, I do it for fun. And right now Mobile development is no fun. The downside is, I've all but run out of reasons to develop in LC. I used to write little (but useful) apps/games/utilities for myself, or my family, or sometimes for friends. I don't think my wife's laptop has been switched on this year - she uses her tablet and/or phone almost exclusively. And others in the family are much the same. So I think the right solution is for LC Ltd is to add *another* target platform - PWAs. (This has the advantage that it also tackles the inadequacy of the HTML platform). LC Ltd should just pick a set of PWA components (I don't know which - maybe Angular, Polymer, etc. I *really* don't know which - but just pick one for me !!). Then they should identify a *subset* of LC script/UI features that can be readily mapped to JS and a LC/JS library, and implement that. Given the ability to re-load JS it should be feasible to be (fairly) "Live"Code, without a full stand-alone build step. It should produce fast-loading, small "apps" that would allow many fairly straightforward apps to be developed easily - bringing Mobile development back into the realm where new / naive users (that includes me) can readily develop apps and run them on the devices we all use these days. And I'd get to stick to LC :-) Alex. On 05/04/2020 21:53, Curry Kenworthy via use-livecode wrote: Agreed!!! I had grown weary of endless arguments previously pushing back against most LC critiques while the wagons were circled, so very glad to see this frankly discussed now. "Live" Code. Meaning: WYSIWYG between dev and runtime, no edit-compile-run cycle, much more efficient. Remember the marketing? For us the Users, it wasn't just marketing. It was real, and it was the reason and the empowerment. We lived it and used it. Still do on desktop. But LC has never been "Live" Code on mobile platforms. A big fail. Not just the UI, but also the mobileBlahBlah keywords that must be placed in if/then branches to avoid runtime errors on desktop whereas they should have been designed pan-platform. When these first appeared I was hoping they were temporary. Instead they've grown and multiplied, setting an arguably bad trend for the future. That was a huge design flaw or design mistake/bad decision for a product called "Live" Code. LC Ltd needs to understand and embrace some key characteristics of its own product. It's not just marketing, and it's not a HyperCard "Boomer" fad that will (or should) die out demographically with younger coders. It's valid, there's a reason, and it's so important. How's that for a "second"? :) Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.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: Maximum field height?
Richard: > Exactly. Reducing the differences between runtime and development > is a cornerstone of The xTalk Way. [...] > Suffice to say politely and succinctly: a decade later, LC for > mobile remains half-baked compared to what it could be, compared > to The xTalk Way that rests at the heart of its origins. > There, I said it. Someone had to. Agreed!!! I had grown weary of endless arguments previously pushing back against most LC critiques while the wagons were circled, so very glad to see this frankly discussed now. "Live" Code. Meaning: WYSIWYG between dev and runtime, no edit-compile-run cycle, much more efficient. Remember the marketing? For us the Users, it wasn't just marketing. It was real, and it was the reason and the empowerment. We lived it and used it. Still do on desktop. But LC has never been "Live" Code on mobile platforms. A big fail. Not just the UI, but also the mobileBlahBlah keywords that must be placed in if/then branches to avoid runtime errors on desktop whereas they should have been designed pan-platform. When these first appeared I was hoping they were temporary. Instead they've grown and multiplied, setting an arguably bad trend for the future. That was a huge design flaw or design mistake/bad decision for a product called "Live" Code. LC Ltd needs to understand and embrace some key characteristics of its own product. It's not just marketing, and it's not a HyperCard "Boomer" fad that will (or should) die out demographically with younger coders. It's valid, there's a reason, and it's so important. How's that for a "second"? :) Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.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: Maximum field height?
J. Landman Gay wrote: > On 4/5/20 1:12 PM, Richard Gaskin via use-livecode wrote: > >> Once I saw that the scroller works well on the field content I've >> been working with, I added a routine to my mobile lib that >> automatically removes the vScrollbar from any non-editable field >> that has one, and instantiates a matching scroller over it. > > That's my standard procedure too, unless I'm using a pseudo-scrolling > handler that allows pushing up or down on the field on desktop. It's > basically a simulation, but for quick access during development it's > faster to just use the built-in scrollbar. Exactly. Reducing the differences between runtime and development is a cornerstone of The xTalk Way. Dropping a field on a card works. If we want it scrollable, we click a checkbox. Once clicked, it works everywhere, adapting to the UI conventions of the host platform. Why should that not work on a phone? A generic solution REALLY SHOULD BE IN THE ENGINE (is that loud enough? Good), but in the dismaying absence of that feature completion some ten years later, being able to work around it by having a generic solution in a library is acceptable. That is, if it works: >> So yes, I'm using the field directly with no enclosing group, but no, >> I don't use the desktop scrollbar on mobile; the scroller overlay >> does a good job of tracking the user interaction, with the >> appropriate endpoint indication and all, and scrolling the field in >> response to the scroller's messages has worked well. > > I just released an app using this method and on iOS the stutter is > quite noticeable, as well as on Android devices with slower CPUs. > It's okay for short text, sort of (though there's a brief > jerk) but for anything longer it fails. Good to know. Thanks. It's a good thing for the more sensitive readers of this list that I have a busy Sunday planned, because my ALL CAPS portion above is just a small sample of the "When Keeping It Real Goes Wrong" episode I would otherwise drop on this list like a truckload of customer advocacy bricks. Suffice to say politely and succinctly: a decade later, LC for mobile remains half-baked compared to what it could be, compared to The xTalk Way that rests at the heart of its origins. There, I said it. Someone had to. And it's too bad, because on the desktop it absolutely rocks beyond just about any other option on the planet. It doesn't need to be this way. Software is eating the world, The xTalk Way is supremely productive, and LiveCode is the most powerful xTalk ever. LiveCode should be eating the planet. That it isn't is a function of the customer experience. If we don't soberly own that, there is no meaningful growth path forward. > Up until LC 9 it was possible to set the field to use a scrolling > layermode in the property inspector, but that's been removed. You > can still set it by script, but it has no effect (and probably never > did) and the engine defaults to dynamic layermode instead. If a scrolling field can't be scrolled on mobile with checkbox ease for the developer and well-met expectations for the user, that would be a bug. Let's not lower the bar. Let's complete the implementation. Let's deliver excellence, and enjoy excellent growth. The world is hungry for highly productive software development solutions, right now more than ever. Can we feed them? -- 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: Maximum field height?
What I wrote here originally: > I've switched over to trying a group set as a container and setting > the field itself to scrolling layermode. I haven't tried it yet on > mobile but we'll see. is wrong, the field inside the container group uses dynamic layermode. Scrolling layermode doesn't get applied to fields. We'll see if this works when I'm far enough along to build a test app. -- 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: Maximum field height?
On 4/5/20 1:12 PM, Richard Gaskin via use-livecode wrote: Once I saw that the scroller works well on the field content I've been working with, I added a routine to my mobile lib that automatically removes the vScrollbar from any non-editable field that has one, and instantiates a matching scroller over it. That's my standard procedure too, unless I'm using a pseudo-scrolling handler that allows pushing up or down on the field on desktop. It's basically a simulation, but for quick access during development it's faster to just use the built-in scrollbar. So yes, I'm using the field directly with no enclosing group, but no, I don't use the desktop scrollbar on mobile; the scroller overlay does a good job of tracking the user interaction, with the appropriate endpoint indication and all, and scrolling the field in response to the scroller's messages has worked well. I just released an app using this method and on iOS the stutter is quite noticeable, as well as on Android devices with slower CPUs. It's okay for short text, sort of (though there's a brief jerk) but for anything longer it fails. Up until LC 9 it was possible to set the field to use a scrolling layermode in the property inspector, but that's been removed. You can still set it by script, but it has no effect (and probably never did) and the engine defaults to dynamic layermode instead. While you're at it, it may be worthwhile turning the scrollbar of the field off and having your scrollerDidScroll set the scroll of the field directly, with no enclosing group at all. As above, that's what my previous app did. I'm going to change that for the next update, as it looks unprofessional. If it works as well for you as it's been doing for me, it saves me another test and gives confidence to others that actually development with LiveCode isn't nearly as cumbersome as that Lesson on scrolling fields suggests. Well, basically the lesson is correct. I wish it weren't so. But if you only use a few fields with short content, your easier method is probably passable. My previous app has a field whose content is almost always less than the field height, but only extends beyond that for a few lines occasionally. For something like that, I'd probably skip the group. If you feel like experimenting, try a field sized to a mobile screenrect with 50+ lines of wrapped text. Do it on iOS if you have one of those phones; the simulator won't give you the same response. -- 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: Maximum field height?
J. Landman Gay wrote: > On April 5, 2020 12:46:19 PM Richard Gaskin wrote: > >> I've had such good luck so far with using scrollers directly on >> fields that it never occurred to me that accelerated rendering >> would be useful for field objects. > > If you're using a vScrollbar then no problem. But for swipe scrolling > without a scrollbar, which is what mobile users expect, it's a > different story. Android isn't as bad as iOS but there's a noticeable > stutter on both. I've been too lazy and much too enamored with The xTalk Way for any of that: Once I saw that the scroller works well on the field content I've been working with, I added a routine to my mobile lib that automatically removes the vScrollbar from any non-editable field that has one, and instantiates a matching scroller over it. So yes, I'm using the field directly with no enclosing group, but no, I don't use the desktop scrollbar on mobile; the scroller overlay does a good job of tracking the user interaction, with the appropriate endpoint indication and all, and scrolling the field in response to the scroller's messages has worked well. But then again, I haven't used really long text with that. I'll explore that soon, and in the meantime I look forward to what you learn with this experiment from your earlier post: > I've switched over to trying a group set as a container and setting > the field itself to scrolling layermode. I haven't tried it yet on > mobile but we'll see. While you're at it, it may be worthwhile turning the scrollbar of the field off and having your scrollerDidScroll set the scroll of the field directly, with no enclosing group at all. If it works as well for you as it's been doing for me, it saves me another test and gives confidence to others that actually development with LiveCode isn't nearly as cumbersome as that Lesson on scrolling fields suggests. -- 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: Maximum field height?
On April 5, 2020 12:46:19 PM Richard Gaskin via use-livecode wrote: I've had such good luck so far with using scrollers directly on fields that it never occurred to me that accelerated rendering would be useful for field objects. If you're using a vScrollbar then no problem. But for swipe scrolling without a scrollbar, which is what mobile users expect, it's a different story. Android isn't as bad as iOS but there's a noticeable stutter on both. -- 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: Maximum field height?
J. Landman Gay wrote: > @Richard, when developing for desktop you don't need the enclosing > group, but on mobile you do because acceleratedRendering only applies > to groups. Without it you can't achieve smooth scrolling. I wish we > could just set a field to scrolling layermode, it would sure make > layout and resizing easier. My own mobiles apps haven't yet displayed text longer than a few dozen pages, but I was impressed with the smoothness. I'd always taken LC's field excellent field buffering for granted, given that their text engine is internal and used on all platforms. I've had such good luck so far with using scrollers directly on fields that it never occurred to me that accelerated rendering would be useful for field objects. Maybe Mark Waddingham could explain the relationship between LC's field buffering and the non-text buffering the engine does with groups? -- 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: Maximum field height?
Thanks guys. I did remember there was a limit but for some reason thought it was only for the width of a line. I've switched over to trying a group set as a container and setting the field itself to scrolling layermode. I haven't tried it yet on mobile but we'll see. @Richard, when developing for desktop you don't need the enclosing group, but on mobile you do because acceleratedRendering only applies to groups. Without it you can't achieve smooth scrolling. I wish we could just set a field to scrolling layermode, it would sure make layout and resizing easier. I think the new container layermode is supposed to help with this stuff. I haven't had to use it until now. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On April 5, 2020 9:15:24 AM Richard Gaskin via use-livecode wrote: J. Landman Gay wrote: > I have a field that reports a formattedheight of 125396. I want to > extend it to full height for use inside an enclosing scrolling group. I see that method used in the Lesson on using a scroller for text as well, but I've never understood why. What is the advantage of putting the field inside of a group rather than using the scroller with the field directly? > But when I try to set the height to the formattedHeight, I get an > error: Value is not a number. I think Paul has the answer there: groups have limit of 32,767px on either axis. That's about 30' on desktop systems so generally useful, but when using them to contain a field sized for long text it can easily be exceeded. -- 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: Maximum field height?
J. Landman Gay wrote: > I have a field that reports a formattedheight of 125396. I want to > extend it to full height for use inside an enclosing scrolling group. I see that method used in the Lesson on using a scroller for text as well, but I've never understood why. What is the advantage of putting the field inside of a group rather than using the scroller with the field directly? > But when I try to set the height to the formattedHeight, I get an > error: Value is not a number. I think Paul has the answer there: groups have limit of 32,767px on either axis. That's about 30' on desktop systems so generally useful, but when using them to contain a field sized for long text it can easily be exceeded. -- 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: Maximum field height?
On 4/5/2020 1:16 AM, J. Landman Gay via use-livecode wrote: I have a field that reports a formattedheight of 125396. I want to extend it to full height for use inside an enclosing scrolling group. But when I try to set the height to the formattedHeight, I get an error: Value is not a number. If I try to set its height in the property inspector, it reverts to 9,040. Does it exceed some maximum? If I set a scrollbar on the field, it scrolls fine and includes all the text. But it won't expand to its full height for use inside a scrolling group, which I need for smooth scrolling on mobile. I thought objects in LC still were limited to 32000px (or perhaps -32000 to +32000 in coordinates) from the ancient QuickDraw days ___ 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
Maximum field height?
I have a field that reports a formattedheight of 125396. I want to extend it to full height for use inside an enclosing scrolling group. But when I try to set the height to the formattedHeight, I get an error: Value is not a number. If I try to set its height in the property inspector, it reverts to 9,040. Does it exceed some maximum? If I set a scrollbar on the field, it scrolls fine and includes all the text. But it won't expand to its full height for use inside a scrolling group, which I need for smooth scrolling on mobile. -- 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
