Re: Smooth scrolling
On Fri, Feb 5, 2021 at 4:10 AM Niggemann, Bernd via use-livecode < use-livecode@lists.runrev.com> wrote: > Thank you Trevor for making this available. After testing your library i > realize what an improvement it is. > And I agree that "ideally any engine improvents would tap into the scroll > wheel values provided by the OS" > > I don't see any difference regarding lineSize. Maybe > "ObjC_NSEventHasPreciseScrollingDeltas" is true. > Anyway in the comments of the LCB file you mention "row height" > Do you mean "effectiv lineSize" (synonym of borderSize) or "effective > textHeight"? > Hi Bernd, Glad you like it. I originally wrote the extension for use with the DataView (a more modern DataGrid) which has a "row" concept rather than a "line" concept. I hadn't applied it to fields before putting together the test yesterday. You are correct, if should be `textHeight`, not `lineSize`, in the script. > I added hScroll to your script (again this is Mac only and needs Trevor's > library installed) > > --- > on rawKeyDown pKey >-- if the optionKey is down then pass rawKeyDown -- just to test > scrolling of LC and library >if pKey = "65308" or pKey = "65309" then > set the vscroll of me to the vscroll of me \ >- item 2 of macCurrentEventScrollValues(the effective linesize of > me) >else if pKey is in "65310,65311" and the hScrollbar of me then > set the hscroll of me to the hscroll of me \ > - item 1 of macCurrentEventScrollValues(the effective linesize of me) >else > pass rawKeyDown >end if > end rawKeyDown > > Nice addition! -- Trevor DeVore ScreenSteps www.screensteps.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: Smooth scrolling
> Trevor wrote > > On macOS it is simple enough to get the true scroll values from the scroll > event using NSEvent.scrollingDeltaX and NSEvent.scrollingDeltaY. It is > possible to get those values using LCB as demonstrated in the > mac_scroll_wheel.lcb extension that is included with the DataView control > I've made available. Here is a link to the source code: > > https://github.com/trevordevore/levurehelper-dataview/blob/develop/mac_scroll_wheel.lcb > . > Ideally any engine improvements would tap into the > scroll wheel values provided by the OS. Thank you Trevor for making this available. After testing your library i realize what an improvement it is. And I agree that "ideally any engine improvents would tap into the scroll wheel values provided by the OS" I don't see any difference regarding lineSize. Maybe "ObjC_NSEventHasPreciseScrollingDeltas" is true. Anyway in the comments of the LCB file you mention "row height" Do you mean "effectiv lineSize" (synonym of borderSize) or "effective textHeight"? I added hScroll to your script (again this is Mac only and needs Trevor's library installed) --- on rawKeyDown pKey -- if the optionKey is down then pass rawKeyDown -- just to test scrolling of LC and library if pKey = "65308" or pKey = "65309" then set the vscroll of me to the vscroll of me \ - item 2 of macCurrentEventScrollValues(the effective linesize of me) else if pKey is in "65310,65311" and the hScrollbar of me then set the hscroll of me to the hscroll of me \ - item 1 of macCurrentEventScrollValues(the effective linesize of me) else pass rawKeyDown end if end rawKeyDown Kind regards Bernd ___ 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: Smooth scrolling
On Tue, Feb 2, 2021 at 4:25 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > JeeJeeStudio wrote: > > > Panos wrote: > >> This bug report contains a workaround for smooth scrolling - hope it > >> helps. > >> https://quality.livecode.com/show_bug.cgi?id=19759 > > > > > > Maybe it's me but i don't see any difference in scrolling between the > > left and right on win10 > > The original description of the problem here lacks specificity. It's not > just any scrolling that is affected, but scrolling that happens in > response to a scroll wheel or trackpad gestures. > > The script Panos posted in the bug report has two gradations of scroll > increment, based on the interval between keydown messages corresponding > to the scroll wheel/trackpad gesture. > I came across this thread and thought I would add an additional comment. The scrolling can be improved further by using the scroll event values provided by the operating system. On macOS it is simple enough to get the true scroll values from the scroll event using NSEvent.scrollingDeltaX and NSEvent.scrollingDeltaY. It is possible to get those values using LCB as demonstrated in the mac_scroll_wheel.lcb extension that is included with the DataView control I've made available. Here is a link to the source code: https://github.com/trevordevore/levurehelper-dataview/blob/develop/mac_scroll_wheel.lcb Anyone who is interested and running macOS can download the compiled version of the extension and test it out in the sample stack. 1) Visit the following link and click the "Download" button https://github.com/trevordevore/levurehelper-dataview/blob/develop/mac_scroll_wheel.lcm 2) Then run this in the Message Box and select the .lcm file to load it: answer file "Select Extension";load extension from file it;put the result 3) Add this script to any field you want to test with: on rawKeyDown pKey if pKey = "65308" or pKey = "65309" then set the vscroll of me to the vscroll of me - item 2 of macCurrentEventScrollValues(the effective linesize of me) else pass rawKeyDown end if end rawKeyDown On my computer I see the best results in the test stack from the bug report using this method. Ideally any engine improvements would tap into the scroll wheel values provided by the OS. -- Trevor DeVore ScreenSteps ___ 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: Smooth scrolling
JeeJeeStudio wrote: > Panos wrote: >> This bug report contains a workaround for smooth scrolling - hope it >> helps. >> https://quality.livecode.com/show_bug.cgi?id=19759 > > > Maybe it's me but i don't see any difference in scrolling between the > left and right on win10 The original description of the problem here lacks specificity. It's not just any scrolling that is affected, but scrolling that happens in response to a scroll wheel or trackpad gestures. The script Panos posted in the bug report has two gradations of scroll increment, based on the interval between keydown messages corresponding to the scroll wheel/trackpad gesture. It's good. Very good. I see the difference here on Ubuntu. It's so good it should be added to the engine, so we don't merely rely solely on the odd chance that someone wanting to make attractive software with LC happens to stumble across this thread. If there's a concern about backward compatibility (understandable given the many ways scrollbarDrag messages are used) perhaps fields could have a smoothScrolling property added to govern this. And since this behavior reflects modern scrolling standards, it should be on by default (yet can be turned off for the edge cases where people need the older linear scroll for specialized use cases). That said, with the team's current priorities I don't see this happening for quite some time. That's too bad, because it means every new user will get a poorer impression of the LiveCode experience than they could be having. -- 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: Smooth scrolling
Maybe it's me but i don't see any difference in scrolling between the left an right on win10 Op di 2 feb. 2021 om 17:34 schreef Mark Wieder via use-livecode < use-livecode@lists.runrev.com>: > On 2/1/21 7:10 PM, Richard Gaskin via use-livecode wrote: > > > using Kafka's Metamorphosis... > > ...then you should expect bugs. > > -- > 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 > ___ 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: Smooth scrolling
On 2/1/21 7:10 PM, Richard Gaskin via use-livecode wrote: using Kafka's Metamorphosis... ...then you should expect bugs. -- 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: Smooth scrolling
Very nice. Thanks Panos > On Feb 2, 2021, at 2:54 PM, panagiotis merakos via use-livecode > wrote: > > Hello folks, > > This bug report contains a workaround for smooth scrolling - hope it helps. > > https://quality.livecode.com/show_bug.cgi?id=19759 > > Cheers, > Panos > -- > > On Tue, 2 Feb 2021 at 16:17, Craig newman via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> On a Mac, I made a field with 25000 words or so. Certainly dragging the >> thumb is jerky. >> >> But dragging the thumb forces the field's scroll to track the thumbPos, as >> it relates to the number of lines and the total "pixel" travel available to >> that thumb. I don't see how a field could scroll smoothly at all, since the >> thumb and the scroll are locked together. >> >> In other words, how can it "glide" from one line (scroll position) to >> another, since the thumbPos has a finite number of possible locations, and >> if there are a LOT of lines, each location may be several lines away? >> >> Craig >> >> -Original Message- >> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On >> Behalf >> Of Richard Gaskin via use-livecode >> Sent: Monday, February 01, 2021 10:11 PM >> To: use-livecode@lists.runrev.com >> Cc: Richard Gaskin >> Subject: Re: Smooth scrolling >> >> David Epstein wrote: >> >>> My impression is that a LiveCode field scrolls less smoothly than > a >> comparable field in some other programs, such as MS Word and > Scrivener. >> If I paste about 25,000 words into a word wrapped > scrolling field, and >> then drag the scrolling thumb up and down > there is much more jumpiness >> than I see when I do the same thing > to the same text in those other >> programs. (LC 9.6 on Mac OS 10.12.6). >>> Do others see the same thing? Does anyone know the underlying cause > >> of this, or a remedy? >> >> Nice to hear the name Scrivener. Blount did some good rethinking of how >> words are managed when he came up with that app. >> >> In the olden days I remember being impressed with how smoothly LC scrolled >> vs things like Word, which wasn't all that surprising given that LC buffers >> the whole field in RAM while Word pages from disk. >> >> A lot's changed since then. Not only have SSDs taken over to narrow the >> gap, >> but I no longer have a copy of Word to compare anything to. :) >> >> But I did just do a quick test of LC v9.6.2rc2 vs LibreOffice Write on >> Ubuntu 18.04, using Kafka's Metamorphosis to get a reasonably close number >> of words to your test (Gutenberg Project RTF is 25,180 words: >> http://www.gutenberg.org/files/5200/5200-r.rtf ). >> >> Very different setup of course, but FWIW LC and LibreOffice are quite close >> in scrolling, though LC seems noticeably smoother. >> >> Of course Ubuntu and macOS couldn't be more different from top to bottom, >> with different font managers, buffering APIs, compositors, etc., so while >> it >> was easy for me to do this quick test it's almost entirely useless. >> >> What might be nice would be someone with good knowledge of Apple low-level >> tools, similar to the ones we see for Android or to some degree strace, >> where graphical UI stuff can be profiled so we can see what Word and LC are >> doing differently. >> >> It might also be worth setting the field's layerMode to "scrolling" and the >> stack's compositorType to "CoreGraphics" to see if that improves things. >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> >> ambassa...@fourthworld.comhttp://www.FourthWorld.com >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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: Smooth scrolling
Hello folks, This bug report contains a workaround for smooth scrolling - hope it helps. https://quality.livecode.com/show_bug.cgi?id=19759 Cheers, Panos -- On Tue, 2 Feb 2021 at 16:17, Craig newman via use-livecode < use-livecode@lists.runrev.com> wrote: > On a Mac, I made a field with 25000 words or so. Certainly dragging the > thumb is jerky. > > But dragging the thumb forces the field's scroll to track the thumbPos, as > it relates to the number of lines and the total "pixel" travel available to > that thumb. I don't see how a field could scroll smoothly at all, since the > thumb and the scroll are locked together. > > In other words, how can it "glide" from one line (scroll position) to > another, since the thumbPos has a finite number of possible locations, and > if there are a LOT of lines, each location may be several lines away? > > Craig > > -Original Message- > From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On > Behalf > Of Richard Gaskin via use-livecode > Sent: Monday, February 01, 2021 10:11 PM > To: use-livecode@lists.runrev.com > Cc: Richard Gaskin > Subject: Re: Smooth scrolling > > David Epstein wrote: > > > My impression is that a LiveCode field scrolls less smoothly than > a > comparable field in some other programs, such as MS Word and > Scrivener. > If I paste about 25,000 words into a word wrapped > scrolling field, and > then drag the scrolling thumb up and down > there is much more jumpiness > than I see when I do the same thing > to the same text in those other > programs. (LC 9.6 on Mac OS 10.12.6). > > Do others see the same thing? Does anyone know the underlying cause > > of this, or a remedy? > > Nice to hear the name Scrivener. Blount did some good rethinking of how > words are managed when he came up with that app. > > In the olden days I remember being impressed with how smoothly LC scrolled > vs things like Word, which wasn't all that surprising given that LC buffers > the whole field in RAM while Word pages from disk. > > A lot's changed since then. Not only have SSDs taken over to narrow the > gap, > but I no longer have a copy of Word to compare anything to. :) > > But I did just do a quick test of LC v9.6.2rc2 vs LibreOffice Write on > Ubuntu 18.04, using Kafka's Metamorphosis to get a reasonably close number > of words to your test (Gutenberg Project RTF is 25,180 words: > http://www.gutenberg.org/files/5200/5200-r.rtf ). > > Very different setup of course, but FWIW LC and LibreOffice are quite close > in scrolling, though LC seems noticeably smoother. > > Of course Ubuntu and macOS couldn't be more different from top to bottom, > with different font managers, buffering APIs, compositors, etc., so while > it > was easy for me to do this quick test it's almost entirely useless. > > What might be nice would be someone with good knowledge of Apple low-level > tools, similar to the ones we see for Android or to some degree strace, > where graphical UI stuff can be profiled so we can see what Word and LC are > doing differently. > > It might also be worth setting the field's layerMode to "scrolling" and the > stack's compositorType to "CoreGraphics" to see if that improves things. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.comhttp://www.FourthWorld.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Smooth scrolling
On a Mac, I made a field with 25000 words or so. Certainly dragging the thumb is jerky. But dragging the thumb forces the field's scroll to track the thumbPos, as it relates to the number of lines and the total "pixel" travel available to that thumb. I don't see how a field could scroll smoothly at all, since the thumb and the scroll are locked together. In other words, how can it "glide" from one line (scroll position) to another, since the thumbPos has a finite number of possible locations, and if there are a LOT of lines, each location may be several lines away? Craig -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Richard Gaskin via use-livecode Sent: Monday, February 01, 2021 10:11 PM To: use-livecode@lists.runrev.com Cc: Richard Gaskin Subject: Re: Smooth scrolling David Epstein wrote: > My impression is that a LiveCode field scrolls less smoothly than > a comparable field in some other programs, such as MS Word and > Scrivener. If I paste about 25,000 words into a word wrapped > scrolling field, and then drag the scrolling thumb up and down > there is much more jumpiness than I see when I do the same thing > to the same text in those other programs. (LC 9.6 on Mac OS 10.12.6). > Do others see the same thing? Does anyone know the underlying cause > of this, or a remedy? Nice to hear the name Scrivener. Blount did some good rethinking of how words are managed when he came up with that app. In the olden days I remember being impressed with how smoothly LC scrolled vs things like Word, which wasn't all that surprising given that LC buffers the whole field in RAM while Word pages from disk. A lot's changed since then. Not only have SSDs taken over to narrow the gap, but I no longer have a copy of Word to compare anything to. :) But I did just do a quick test of LC v9.6.2rc2 vs LibreOffice Write on Ubuntu 18.04, using Kafka's Metamorphosis to get a reasonably close number of words to your test (Gutenberg Project RTF is 25,180 words: http://www.gutenberg.org/files/5200/5200-r.rtf ). Very different setup of course, but FWIW LC and LibreOffice are quite close in scrolling, though LC seems noticeably smoother. Of course Ubuntu and macOS couldn't be more different from top to bottom, with different font managers, buffering APIs, compositors, etc., so while it was easy for me to do this quick test it's almost entirely useless. What might be nice would be someone with good knowledge of Apple low-level tools, similar to the ones we see for Android or to some degree strace, where graphical UI stuff can be profiled so we can see what Word and LC are doing differently. It might also be worth setting the field's layerMode to "scrolling" and the stack's compositorType to "CoreGraphics" to see if that improves things. -- 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: Smooth scrolling
David Epstein wrote: > My impression is that a LiveCode field scrolls less smoothly than > a comparable field in some other programs, such as MS Word and > Scrivener. If I paste about 25,000 words into a word wrapped > scrolling field, and then drag the scrolling thumb up and down > there is much more jumpiness than I see when I do the same thing > to the same text in those other programs. (LC 9.6 on Mac OS 10.12.6). > Do others see the same thing? Does anyone know the underlying cause > of this, or a remedy? Nice to hear the name Scrivener. Blount did some good rethinking of how words are managed when he came up with that app. In the olden days I remember being impressed with how smoothly LC scrolled vs things like Word, which wasn't all that surprising given that LC buffers the whole field in RAM while Word pages from disk. A lot's changed since then. Not only have SSDs taken over to narrow the gap, but I no longer have a copy of Word to compare anything to. :) But I did just do a quick test of LC v9.6.2rc2 vs LibreOffice Write on Ubuntu 18.04, using Kafka's Metamorphosis to get a reasonably close number of words to your test (Gutenberg Project RTF is 25,180 words: http://www.gutenberg.org/files/5200/5200-r.rtf ). Very different setup of course, but FWIW LC and LibreOffice are quite close in scrolling, though LC seems noticeably smoother. Of course Ubuntu and macOS couldn't be more different from top to bottom, with different font managers, buffering APIs, compositors, etc., so while it was easy for me to do this quick test it's almost entirely useless. What might be nice would be someone with good knowledge of Apple low-level tools, similar to the ones we see for Android or to some degree strace, where graphical UI stuff can be profiled so we can see what Word and LC are doing differently. It might also be worth setting the field's layerMode to "scrolling" and the stack's compositorType to "CoreGraphics" to see if that improves things. -- 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: Smooth scrolling
David: > My impression is that a LiveCode field scrolls less smoothly > than a comparable field in some other programs Fair impression. :) > 25,000 words into a word wrapped scrolling field Performance does degrade as text size increases. (Exponentially, after a certain point.) > Does anyone know the underlying cause of this, For fun, try the same text in LC 5.5 or 4.6! I would expect snappier results. Performance took a huge hit with LC 7 and 8. There was (and is) a myth that this is completely due to Unicode. But in a series of videos and published tests, I proved otherwise. Many other areas were impacted. So beware of that myth! So Unicode (and the way it was implemented) played a part, but it's not the only culprit. This is an ongoing saga. To their credit, the LC team has made good optimizations in a few areas! Mark was quite responsive to the "need for speed." On the flip side, overall LC performance remains ... underwhelming. > or a remedy? It helps to optimize your own code/UI/setup as much as you can: Most LC user code is poorly organized and wastes tons of CPU time. Many times people also have extravagant or sloppy UI. And their problem-solving setup is not focused; lots of extra crap. Tightening up all these can help a LOT! You'll see results. Bonus good news: Standalone will run a little smoother than IDE. (IDE is a bit on the bloatware side.) Optimize all you can, and your build may be blessed a bit extra! :) Beyond that, the ultimate solution is join the effort. Make a useful test stack, maybe a video to demo results. Design the test code well. Post a bug report. I'm still involved in this campaign, but currently "mute" - post-COVID, breathing got worse; can't talk in video or on phone. But I'm adjusting to that - I'll be using sound effects, TTS, whatever. So hopefully this year I'll get another test and video posted. I encourage others (and yourself) to do the same! I believe LC can be quite a bit faster. So far, I've been proven correct 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
Smooth scrolling
My impression is that a LiveCode field scrolls less smoothly than a comparable field in some other programs, such as MS Word and Scrivener. If I paste about 25,000 words into a word wrapped scrolling field, and then drag the scrolling thumb up and down there is much more jumpiness than I see when I do the same thing to the same text in those other programs. (LC 9.6 on Mac OS 10.12.6). Do others see the same thing? Does anyone know the underlying cause of this, or a remedy? David Epstein ___ 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: smooth scrolling
On Sat, Jan 11, 2014 at 7:16 PM, J. Landman Gay jac...@hyperactivesw.comwrote: So that's the reason. It makes me crazy and it happens all the time. The script goes zooming off somewhere and it happens so fast I'm not even sure whether to scroll up or down to get back where I was. Exactly my experience. Surprising that I didn't figure it out before. *--* *Stephen Barncard - San Francisco Ca. USA - Deeds Not Words* ___ 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
smooth scrolling
I've just figured out what's bothered me most about Livecode fields and why they act different than native fields (at least on the mac). They are not very 'magic mouse' friendly - and any vertical scrolling type gestures on it get translated into 'rough scrolling' moves ( jumps line by line as opposed to pixels ) everywhere, and at the same time the horizontal scrolling is totally free. As a result there is a lot of unintended text movement - the Magic Mouse is VERY sensitive. And when a small movement mistake is made, the attention to the current line is totally destroyed when the viewport moves wildly about the screen. This drives me nuts. I thought smooth scrolling was a non-issue anymore on a mac. Yet there it is. Real text fields in other apps don't do this. Only Livecode has these antiquated field specs… is there any way to get smooth scrolling from gestures? Why was this overlooked? Is this a major weakness? Was the feature limited for speed reasons, and why can't it be on a par with other applications? Or is it 'dumbed down' to meet the limitations of other platforms? Should I file a report, or am I just PNP? *--* *Stephen Barncard - San Francisco Ca. USA - Deeds Not Words* ___ 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: smooth scrolling
I see the way in which fields scroll (particularly with something like a magic mouse) as an issue. They don’t “feel” right and, in the app produced, users do notice. In fields with a lot of text, the field jumps in large increments. It looks bad and I do get feedback that the field is hard to read because of the “jumps”. If you have a fixed length field that is not too long (or short) you can script your own scrolling by capturing the rawKeyDown message. The length of the field plays into this because the message fires just infrequently enough that the information you need isn’t there. I am really hoping that when cocoa is fully implemented we will get native fields with smoothly scrolling and, please, OSX style spell checking. I fear that may not be the case due to a desire to have things be cross platform. So, please do file a report. Thanks, John On Jan 11, 2014, at 12:41 PM, stephen barncard stephenrevoluti...@barncard.com wrote: I've just figured out what's bothered me most about Livecode fields and why they act different than native fields (at least on the mac). They are not very 'magic mouse' friendly - and any vertical scrolling type gestures on it get translated into 'rough scrolling' moves ( jumps line by line as opposed to pixels ) everywhere, and at the same time the horizontal scrolling is totally free. As a result there is a lot of unintended text movement - the Magic Mouse is VERY sensitive. And when a small movement mistake is made, the attention to the current line is totally destroyed when the viewport moves wildly about the screen. This drives me nuts. I thought smooth scrolling was a non-issue anymore on a mac. Yet there it is. Real text fields in other apps don't do this. Only Livecode has these antiquated field specs… is there any way to get smooth scrolling from gestures? Why was this overlooked? Is this a major weakness? Was the feature limited for speed reasons, and why can't it be on a par with other applications? Or is it 'dumbed down' to meet the limitations of other platforms? Should I file a report, or am I just PNP? *--* *Stephen Barncard - San Francisco Ca. USA - Deeds Not Words* ___ 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: smooth scrolling
On Sat, Jan 11, 2014 at 12:59 PM, John j...@onechip.com wrote: If you have a fixed length field that is not too long (or short) you can script your own I know that, but workarounds have to be 'patched into' the IDE. I shouldn't have to do this. Another issue I have with the editor is the background color - I prefer a dark background with light text, not the other way around, but there is no way to change it (without again having to hack the IDE). Styles are long overdue. *--* *Stephen Barncard - San Francisco Ca. USA - Deeds Not Words* ___ 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: smooth scrolling
I was willing to put up with the IDE issues, I was more interested in what my apps look like. I shouldn’t have to script around field behavior there either. You can change the background color of the script editor in LC preferences but, you cannot change the cursor color or set the text color for the syntax type. It sort of defeats the purpose. A medium gray background seems to work Ok but, like you, I really would like more control over the text editor. Again, my big gripe is the apps don’t act like “real” or “native” apps and users do notice. If this is fixed, I assume some of the IDE issues will be fixed as well. Thanks, John On Jan 11, 2014, at 1:06 PM, stephen barncard stephenrevoluti...@barncard.com wrote: On Sat, Jan 11, 2014 at 12:59 PM, John j...@onechip.com wrote: If you have a fixed length field that is not too long (or short) you can script your own I know that, but workarounds have to be 'patched into' the IDE. I shouldn't have to do this. Another issue I have with the editor is the background color - I prefer a dark background with light text, not the other way around, but there is no way to change it (without again having to hack the IDE). Styles are long overdue. *--* *Stephen Barncard - San Francisco Ca. USA - Deeds Not Words* ___ 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: smooth scrolling
On 1/11/14, 2:41 PM, stephen barncard wrote: I've just figured out what's bothered me most about Livecode fields and why they act different than native fields (at least on the mac). They are not very 'magic mouse' friendly - and any vertical scrolling type gestures on it get translated into 'rough scrolling' moves ( jumps line by line as opposed to pixels ) everywhere, and at the same time the horizontal scrolling is totally free. As a result there is a lot of unintended text movement - the Magic Mouse is VERY sensitive. And when a small movement mistake is made, the attention to the current line is totally destroyed when the viewport moves wildly about the screen. This drives me nuts. So that's the reason. It makes me crazy and it happens all the time. The script goes zooming off somewhere and it happens so fast I'm not even sure whether to scroll up or down to get back where I was. -- 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
