ScrollablePositionedList: Docs should state lists items can't contain GlobalKeys.

[marcglasberg]

Because of this bug #137 it's actually not possible to have any widgets with global keys inside of the ScrollablePositionedList.

This should be clearly stated in the docs, since this bug is almost a year old.

======== Exception caught by widgets library ==============
The following assertion was thrown while finalizing the widget tree:
Duplicate GlobalKey detected in widget tree.

Question: Is ScrollablePositionedList still in development, or is it abandoned? Lot's of old problems that never get fixed. If it's abandoned that's ok, but it would be better if this was clearly stated in pub.dev, so that maybe someone would be interested in forking this widget. I doubt anyone will fork and continue development unless you folks clearly state that further development is not happening.

[ulusoyca]

@marcglasberg It is great point. I would also like to understand how credible a library is when the publisher has google.dev badge.

[jamesderlin]

Question: Is ScrollablePositionedList still in development, or is it abandoned? Lot's of old problems that never get fixed.

It's not abandoned, but it's unfortunately not a priority. google.dev packages often are written by Googlers who are not on the Dart and Flutter teams, so their primary jobs are to work on other things. A couple of weeks ago, I made some changes to make it easier to accept pull requests, so PRs are welcome.

Regarding this bug: I'm slightly reluctant to document (and thereby formalize) this limitation since IMO bug #137 should be fixed. I suppose it might be okay if the docs stated that it's only a current limitation.

[marcglasberg]

@jamesderlin James, thanks for your response. Not a priority is one thing, but it seems to me this project will not really be worked on anymore.

Would you and @tarobins be willing to transfer it to the Flutter Community (https://github.com/fluttercommunity) in case they accept it? If so, I'll talk to them and see if they are willing to accept ownership of this package in pub.dev and resume development.

[tarobins]

@marcglasberg as @jamesderlin pointed out, the biggest limitation is time and PRs are welcome.

When looking at PRs, two things are most important:

1. API changes are reasonable. In particular, they should mirror other flutter APIs when possible.
2. Tests. One thing I've run into with some PRs is that they don't have tests. I'm really reluctant to accept PRs without tests because the functionality that the PR adds or fixes is likely (almost guaranteed) to break in the future and people will be unhappy. Even if the author is ok with the potential of future breakage, other people might come to depend on the untested behaviour and be unhappy when it breaks.

If those two are satisfied, I'm pretty happy to approve PRs. #2 is often the biggest speed bump to approving PRs and, as I said, I'm really reluctant (bordering on not willing) to change that policy. If someone wants to fork the repo and continue development without such a strict requirement for tests, well, I have no opposition to that.

[tarobins]

Perhaps I should make a note in the SPL readme or something about the above.