Is this really how the scrollView is supposed to work?

dave.haynes, I also don’t use the widget library for any of the UI in my apps with the exception of the scrollview for the same reasons. If your local version of scrollview is in any way even a bit better than the corona widget library version, would you be up for sharing it? I’d greatly appreciate it.

julius, it’s now become very specific to how we’re using it and not really designed to be as portable/reusable as it should be. Part of it was just trying to fix things early on in the app’s development when we were still just “adding on” to the existing scrollview. Another part of it was that we were doing that when we didn’t really know what the heck we were doing in Lua. :slight_smile:  If we could start over, knowing what we know now, it would be much different.

Dave

The scrollView has a bunch of moving parts. Some people want scroll bars, some don’t. Some want it to scroll fast at times and slow at others. But at the end of the day, it’s a group with a touch handler on it. If you don’t need all the bells and whistles you can make you’re own.  If you want to improve it, download the source from http://github.com/coronalabs and take a crack at it. It’s pure Lua.

Rob

This thread is about to have a 2 year anniversary and still the scroll view is still the same? Even if it could have been so much better with 2 hours of work on your part? I have a hard time believing this…

CORONA: Are you seriously suggesting that each developer should write their own scrollView code?

Is that what you suggest? Then I have a suggestion. Remove the whole thing from the widget library. It is exactly as someone wrote in this thread. Experienced Corona users have given up on it and is writing their own code.

Watching Corona develop and evolve is exciting, and watching the progress with tvOS, Windows, and OS X apps is pretty neat. But I still feel like there are a few more basic things that need some love. Maybe now that the staff is bigger some of these things can be focused on.

I think the widget library could be moved to a proper plugin, *if* the plugin system worked better, so that (like most other libraries in other languages), I could get a specific version of that plugin.  I’ve beat that drum as much as I can, I think, in another forum post, but it would be really helpful because then if your app is working great with version 2 of the widget library, you could just keep using that one.  When version 3 is released, you could try it, and if it has breaking changes for your app, you could just continue using version 2.  It would allow the Corona staff the freedom to completely overhaul things without worrying about breaking apps everywhere.

But the plugin system still doesn’t support that, as far as I know, which means you’re still better off having your own version of the widget library (in my opinion).

Dave

This is concerning.  I have a project in the pipeline that needs a scrollview and I had assumed these issues were fixed by now.  Does anyone have a third party solution?

Can you provide a list of specifically what’s wrong with ScrollView (and bug caseID’s would be great)? I’ll look into the issues. As far as I know there are edge cases that we could address, but the core ScrollView is working for many people.

Hi Rob, and thanks for looking into this.

Sure, I can repeat what I wrote in the original post. It’s actually very limited and has only to do with how the scrollView reacts to the swiping motion when the users scrolls.

 


  • Constant scroll speed (not controlled by gesture speed)
    I want the scrolling to be fast or slow dependent on the "flick gesture speed! As it is now, the scroll speed is completely independent of the gesture speed, making the scrollView feeling very clumsy.
     
  • No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture
    Sometimes the user drags the (list) scrollView a bit back and forth, before he wants to scroll a bit further. This isn’t possible now, because such a movement just cancels the scroll.
     
  • No scrolling if the finger is moved longer than a certain distance before flicking
    If the user wants to scroll fast, it’s natural to make a larger flick motion, but if the motion is over a certain distance, the scrollView also seems to cancel the scroll!
     
  • Occasional bugging - the scrollView scrolls in the wrong direction
    This happens maybe one of 30 times I try to scroll and it is not caused by reaching the limits of the scroll area.

I have made a small video showing some of these issues: VIDEO (sorry about the lousy resolution, it’s youtube)

 


 

 

I have not made a bug case out of this, because I have gotten the impression from Corona that there are no bugs. This is just how it works.

Constant scroll speed (not controlled by gesture speed)

This seems like a feature request to me. I looked and I don’t see anything at http://feedback.coronalabs.com for this.

No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture

No scrolling if the finger is moved longer than a certain distance before flicking

Occasional bugging - the scrollView scrolls in the wrong direction

These feels like bugs, have you reported them? I looked through the open bug cases and didn’t see anything similar.

Please file a bug report for each of these separately.

We need a simple project that shows the problem. Likely our widget demo might do the trick. If it does show it, just zip it up and use that. If not, we need a main.lua, config.lua, build.settings and any resources to build and run the app to see the problem.  Please put that in a .zip file and use the Report a Bug link at the top.

For the feature request, please use the Feedback link I added above.

Thanks

Rob

OK, now I’ve at least added the feature request and bug report. Let’s see what happens :slight_smile:

How do I follow my bug reports or know if any of them are recognized as bugs?

We normally ask you to post your case ID’s (came to you in an email) back here so when questions come up, we can look them up. The other thing you can do is look at the daily builds page and see what’s changed. There is a link on there that reads:

A summary of what’s happened since the last Public Release is available here.

You can look through those release notes and see when widget things get fixed. However I don’t believe there have been any widget fixes since 4/5. And I know the feature request has not been worked on yet.

It’s also useful to post the feature request URL back to the forum thread as well so others can learn about it and vote it up.

Rob

Ok, so there’s no automatic mechanism for giving the bug reporter a feedback that the bug is being fixed/worked on. We have to go through the lists manually?

Maybe I should add this as a feature request… :slight_smile:

This thread is about to have a 2 year anniversary and still the scroll view is still the same? Even if it could have been so much better with 2 hours of work on your part? I have a hard time believing this…

CORONA: Are you seriously suggesting that each developer should write their own scrollView code?

Is that what you suggest? Then I have a suggestion. Remove the whole thing from the widget library. It is exactly as someone wrote in this thread. Experienced Corona users have given up on it and is writing their own code.

Watching Corona develop and evolve is exciting, and watching the progress with tvOS, Windows, and OS X apps is pretty neat. But I still feel like there are a few more basic things that need some love. Maybe now that the staff is bigger some of these things can be focused on.

I think the widget library could be moved to a proper plugin, *if* the plugin system worked better, so that (like most other libraries in other languages), I could get a specific version of that plugin.  I’ve beat that drum as much as I can, I think, in another forum post, but it would be really helpful because then if your app is working great with version 2 of the widget library, you could just keep using that one.  When version 3 is released, you could try it, and if it has breaking changes for your app, you could just continue using version 2.  It would allow the Corona staff the freedom to completely overhaul things without worrying about breaking apps everywhere.

But the plugin system still doesn’t support that, as far as I know, which means you’re still better off having your own version of the widget library (in my opinion).

Dave

This is concerning.  I have a project in the pipeline that needs a scrollview and I had assumed these issues were fixed by now.  Does anyone have a third party solution?

Can you provide a list of specifically what’s wrong with ScrollView (and bug caseID’s would be great)? I’ll look into the issues. As far as I know there are edge cases that we could address, but the core ScrollView is working for many people.

Hi Rob, and thanks for looking into this.

Sure, I can repeat what I wrote in the original post. It’s actually very limited and has only to do with how the scrollView reacts to the swiping motion when the users scrolls.

 


  • Constant scroll speed (not controlled by gesture speed)
    I want the scrolling to be fast or slow dependent on the "flick gesture speed! As it is now, the scroll speed is completely independent of the gesture speed, making the scrollView feeling very clumsy.
     
  • No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture
    Sometimes the user drags the (list) scrollView a bit back and forth, before he wants to scroll a bit further. This isn’t possible now, because such a movement just cancels the scroll.
     
  • No scrolling if the finger is moved longer than a certain distance before flicking
    If the user wants to scroll fast, it’s natural to make a larger flick motion, but if the motion is over a certain distance, the scrollView also seems to cancel the scroll!
     
  • Occasional bugging - the scrollView scrolls in the wrong direction
    This happens maybe one of 30 times I try to scroll and it is not caused by reaching the limits of the scroll area.

I have made a small video showing some of these issues: VIDEO (sorry about the lousy resolution, it’s youtube)

 


 

 

I have not made a bug case out of this, because I have gotten the impression from Corona that there are no bugs. This is just how it works.

Constant scroll speed (not controlled by gesture speed)

This seems like a feature request to me. I looked and I don’t see anything at http://feedback.coronalabs.com for this.

No scrolling if the finger is moved even slightly in the opposite direction before the flicking gesture

No scrolling if the finger is moved longer than a certain distance before flicking

Occasional bugging - the scrollView scrolls in the wrong direction

These feels like bugs, have you reported them? I looked through the open bug cases and didn’t see anything similar.

Please file a bug report for each of these separately.

We need a simple project that shows the problem. Likely our widget demo might do the trick. If it does show it, just zip it up and use that. If not, we need a main.lua, config.lua, build.settings and any resources to build and run the app to see the problem.  Please put that in a .zip file and use the Report a Bug link at the top.

For the feature request, please use the Feedback link I added above.

Thanks

Rob

OK, now I’ve at least added the feature request and bug report. Let’s see what happens :slight_smile: