search

timusus / RecyclerView-FastScroll

A simple FastScroller for Android's RecyclerView
Other
1.39k stars 183 forks source link

Merge from MaterialScrollBar library #17

Closed turing-tech closed 8 years ago

turing-tech commented 8 years ago

Hi there. Author of the MaterialScrollBar library here: https://github.com/krimin-killr21/MaterialScrollBar

I'd like to have your blessing to fork your library and start working on a library merge. Your lib is much more efficient codewise than mine hence why I'm suggesting using yours as a base. The two libs are so similar I think it would do us and the community good to work together. All I'd ask is for commit privileges if the pull request gets approved and then I'd depreciated my lib and redirect here. I'd work on integrating the following features:

  1. Date and custom-content pop-ups/indicators in addition to your current pop-up.
  2. Google launcher / Google PDF viewer style draging handle (see DragScrollBar from my lib) as an alternative style option.
  3. It looks like I may also be able to move all the custom logic from the FastScrollRecyclerView class into the FastScroller class and thus allow use of the lib with custom recylerViews which extend the vanilla class. We could then add XML and programmatic attachment as seen in my lib to associate the scroll bar and the recylerViews together. If you know of any logic in the class that would prevent this let me know.
  4. Any other features I think off.

Other than these changes we'd keep all of your code.

Regards

timusus commented 8 years ago

I'm actually quite reluctant to add any further customisation to this library at this point. My philosophy sort of resolves around keeping things as minimal as possible, so that users can easily understand what's happening under the hood, and customise the library to suit there needs with minimal effort.

I think there's definitely a place for custom popups/handles, and having a standalone FastScroller class that plugs into a RecyclerView is a good idea.

You're more than welcome to fork the library and build on this functionality, but I would prefer not to merge those changes into the base library, at least not without further consideration.

Hope that's OK. Let me know your thoughts.

turing-tech commented 8 years ago

I see where you're coming from. If that's the case then I suppose I'll just keep them separate. I do have to say though that seeing the code from Launcher3, the portions which really piqued my interest, I'll probably be implementing it in my own lib, which will render some portions of our libs functionally identical. I'll work on simplifying mine to a point where you might be okay with a merge but until then I've just got too many other freatures that I couldn't part with. Luckily I think our approaches are different enough that there will be a choice for users between simplicity and function in our libraries. If you have any alternative ideas about how to go about this I'd love to hear them but that seems like the best approach for me right now.

timusus commented 8 years ago

I'm really not worried to be honest.

If I were you, I'd choose whatever base makes things simplest. It's really not important where a library starts, it's the end result that matters.

If you choose to base it on Launcher3, great. If you base it on my library, I'll be glad to have contributed. As long as you include the appropriate licenses, everyone wins. I would recommend forking the library I've put together, as it fixes some major flaws in the Launcher3 FastScroll, as well as removing Launcher3 specific code. Some of the bugs were quite difficult to get on top of, so you'd be giving yourself a good start. It would also make future merges simpler.

Good luck, and keep me in the loop, I'd be happy to see your contributions. On 21 Feb 2016 10:07 PM, "Turing Technologies" notifications@github.com wrote:

I see where you're coming from. If that's the case then I suppose I'll just keep them separate. I do have to say though that seeing the code from Launcher3, the portions which really piqued my interest, I'll probably be implementing it in my own lib, which will render some portions of our libs functionally identical. I'll work on simplifying mine to a point where you might be okay with a merge but until then I've just got too many other freatures that I couldn't part with. Luckily I think our approaches are different enough that there will be a choice for users between simplicity and function in our libraries. If you have any alternative ideas about how to go about this I'd love to hear them but that seems like the best approach for me right now.

— Reply to this email directly or view it on GitHub https://github.com/timusus/RecyclerView-FastScroll/issues/17#issuecomment-186798691 .

turing-tech commented 8 years ago

Okay, great. Well then I'll take the code from here and put your licence in the readme. Thanks for the advice man.