Future updates and flutter_map thoughts...

[ibrierley]

Obviously things seem quiet here in terms of getting changes and updates through, so it feels like maybe it's worth discussing this again ? People put some useful hard work and pull requests in, and it feels a bit unrewarding to be met with silence rather than encouragement.

Typically what happens with many open source projects it's reliant on one or two people whose focus shifts, and I assume that's what's happened here with @johnpryan and @kengu for example. We all have changing priorities after great work.

What would be useful is some thoughts from them as to where they are with it, and if they have any ideas.

I for example would be fine to try and help out a bit when time permits (which is often very limited like the rest of us), but I suspect myself and others don't necessarily feel they know the code (especially as it grows) well enough to be certain something should be approved for example, without some other issue not being introduced. Some bits of code it's not even clear how it should be used.

But, I'm wondering if there is some middle ground. For example having a set of requirements for changes, eg if it was required for any changes to include a test and some code to reproduce the problem it's trying to solve, and the solution (basically so it's relatively easy for anyone to review and see the problem is fixed), and then maybe 2 reviews or something. Would it be enough ?

There's probably some overall decisions that should be trickier, i.e not everything should be approved, for example if it can be done with a plugin, or maybe if it strays from Leaflet too much (maybe that ship has sailed somewhat though). We've also had discussions about documentation on a similar issue. Not sure what the ideal here is.

So basically, just trying to get the ball rolling to see where we are and if there's any way forward, other than just forking. It would be useful if John/Ken give their thoughts as well as any others.

[JaffaKetchup]

The below is my raw thoughts. Some of it may (and likely will be) wrong:

I agree mostly with this.

Looking at the most recent PRs, most of them have under 100 lines of change in either addition or deletion, which would indicate that that perhaps the best way for this library to grow from this point is in small steps.
This would mean that a solution like you gave in your 3rd paragraph might be suitable. I'm sure actions could be setup to decide (based no. of lines changed) whether a maintainer is needed, or it can just be merged with some suitable reviews - maybe some process of verification?

Although I think plugins are a good idea for larger functionality, many of the PRs just wouldn't fit as plugins: take the recent #1115 for example. Its such a small function, but seems extremely useful and part of the core concepts of this library. Really, the whole PR was exposing methods already hidden internally... which brings me to my next point.

You also mentioned that "others don't necessarily feel they know the code [...] Some bits of code it's not even clear how it should be used". I looked through some of the code today for a different reason, and found my self confused.
I think this library is trying to cover such a large area (essentially the whole of 'mapping') that the code has grown and grown through PRs that haven't documented their functionality correctly (came across an example of this today), and haven't left an 'easy route' of discovery. This is results in other PRs just changing the bare minimum so they don't break anything, which leads to more complex code, which repeats itself.

The three put together - spaghetti-ish code, lack of documentation, many internal methods - then also seem to lead to bugs and errors, as has been seen recently with all the LateInitializationError reports. As well as potentially putting people off this library, this also leads to people submitting PRs to try and fix the problems. This isn't an issue in itself, but rather the sheer amount of incompatible, slightly-different PRs builds up.

I also agree some input from the maintainers about where they see this going would be nice: the last time I saw one of them was on the 23rd Sep 2021.

I'm already trying to cover the documentation issues, which I still think would help, but progress is slow there and I would many 'second' opinions. If anyone reading this wants to help with documentation, please leave a comment on #992 :).

Perhaps a second community effort would be good to try to, once and for all, fix all the null-safety errors, and perhaps rewrite/refactor/expose/organise some code. Maintainer help would be great here too: they have first hand knowledge of what does what.
If we end up finding that it's too difficult or the maintainers can't help, maybe a 'fork' would be the best idea: 'flutter_map v2'. But that would be a last resort.

So my summary:

1. Please can maintainers give an insight

2. If possible, can some more people be given 'maintainer permissions' to start digging through the backlog of PRs

3. Some automation on the GitHub side would be nice

4. Anyone willing to help, please do

   it feels a bit unrewarding to be met with silence rather than encouragement

   a. Documentation needs writing (Documentation Improvements #992)

   • Can maintainers give the go-ahead for the new docs to be made more 'official' and be linked to as beta from the README
   • I/some others? need to finish writing some of the pages
   • Then the in-code docs need to be written - this will require step b.

   b. Code needs 'untangling' and exposing

Thanks :) Hope that made sense.

TLDR/Extra summary: I think 'flutter_map' still has places to go, but some organisation is needed.

[jithware]

Has anyone tried to make direct contact with @johnpryan (see https://www.jpryan.me/)?

[ibrierley]

Yes, I have, and I'm hoping there may be some news in the not too distant future, but sometimes things go slow I know.

[kengu]

Hi everyone, I'm still here, and have no plans to leave the project anytime soon. I can't commit to being available all the time, as this is a spear-time thing for me. I think many of the issues that are raised could easily be handled using gitter.com or something similar for IM/discussions. With regards to PRs, I'll make en effort going through all with green checks soon.

I would also like to promote @ibrierley and @JaffaKetchup for write access @johnpryan. So that we are a couple of more people able to merge PRs.

[jithware]

@kengu any update from @johnpryan in providing write access for @ibrierley and @JaffaKetchup? Would like to have someone available to approve and merge pull requests.

[johnpryan]

Okay, Ian and Luka should have access now.

[JaffaKetchup]

@johnpryan Thank you :)

[comatory]

I think it would also be helpful to create `CONTRIBUTORS` file. At the moment it's not very clear what is the best place for PRs. I did contribute a little bit and was told there's `fleaflet-docs` organization now that deals with that. Getting up the website with docs would also be great.

[kengu]

I agree

[johnpryan]

Hi everyone, thanks for your patience, I'm busy with other projects at the moment. I've given @ibrierley and @JaffaKetchup write access.

[jithware]

I'm not familiar with the process, however I found this:

https://dart.dev/tools/pub/cmd/pub-uploader

@johnpryan is this something you need to do for @JaffaKetchup and @ibrierley?

[jithware]

Though it is possible to use a git repo as a dependency in pubspec.yaml:

  flutter_map:
    git:
      url: https://github.com/fleaflet/flutter_map.git

If you have one or more flutter map plugin dependencies, it will produce a similar error:

Because flutter_map_marker_cluster 0.4.4 depends on flutter_map >=0.13.1 <1.0.0 and no versions of flutter_map_marker_cluster match >0.4.4 <0.5.0, flutter_map_marker_cluster ^0.4.4 requires flutter_map from hosted.
So, because ... depends on both flutter_map from git and flutter_map_marker_cluster ^0.4.4, version solving failed.

Because of this, I believe it will be necessary to periodically publish to pub.dev. @johnpryan will you be available to do this or does it make sense to also allow @JaffaKetchup and @ibrierley to do so? It would be very helpful to have to master published to pub.dev so I can use the recent updates that have been occurring.

[ibrierley]

Darn, I hate those error messages, takes me about 10 reads, and I still don't quite understand it fully :D. Where do the figures for "no versions of flutter_map_marker_cluster match >0.4.4 <0.5.0" actually come from, where has that been specified ?

Also, just pondering, why is flutter_map being loaded from git in this case (or was it just an example) ?

[jithware]

Yeah this is just an example where someone wants to use the latest code from master because it has not yet been published to pub.dev. The output comes from running flutter pub get with flutter_map_marker_cluster: ^0.4.4 in a project's pubspec.yaml file. I have tried changing the plugins to git as well, but that too leads to what appears to be circular dependencies. Maybe I could fork all the plugins I'm using, update all to point to git, then point my project to the forks and maybe that'd work, but a lot easier just to get a new publish of flutter_map to pub.dev ;)

[jithware]

@kengu any chance you can hold of @johnpryan one last time to sort out who can have access to publish to pub.dev and answer @JaffaKetchup question?

[JaffaKetchup]

@johnpryan Thanks for the write access. Maybe it would be a good idea to create a team (called 'maintainers' or something), so pings can be centralised and reviews can be requested by everyone at once?
@fleaflet/maintainers Your thoughts?

It would also be nice to enable the "Update PR" button under Pull Requests on the General page in Settings, so that maintainers can pull upstream on PRs without waiting for the contributor (who may go inactive).

[JaffaKetchup]

I've been thinking about #1165.
There are so many performance issues now, that I'm considering whether it's appropriate for some code to be rewritten to a certain extent. As well as untangling the code - as has been mentioned above - this would give opportunity for as many breaking changes as needed to fix bugs, as well as introduce functionality that should've been implemented years ago (see #800 with #1160 for example).
I would be willing to help out, but I'm not sure whether this is a good idea or not. With the documentation, it was clear that it needed to be redone. With this, it's a much bigger project, and we would need more support than we have right now, with 2 or 3 active maintainers.
Perhaps it would be an opportunity to collaborate somehow with https://pub.dev/packages/map or another mapping package (I haven't been on there before, but it looks quite good - and is very much smaller than this package in lines of code). This would allow the flutter community to have 2 choices - use big companies maps, or use these mapping package(s).
Please let me know what you guys think.

[ibrierley]

Sorry, a bit rambling...

I think some of the performance issues are a bit conflated and needs a bit of care there. Eg ones trying to draw thousands of markers and using clustering are a very different problem to someone mentioning drawing 2 lines crashes or stalls their system. Eg probably I feel the 1&2 should be distinct from 3&4. I've tested 4 and think it's pretty decent, and is probably a bit mixed up as an issue in itself (not to say it can't be improved in the future).

I think the difficulty is always the tradeoff with adding more features, and it weighing on the system and dev time. For example every time I look at the tile_layer I find it too convoluted now. Nested Opacity widgets, animations and things like that, which do serve a purpose, and there's a couple of nasty bugs crept in with Flutter 2.8.x which will be hard to iron out.

I looked (briefly) at packages/map and whilst haven't tried it on an actual device, the web side has some bugs as well, so I feel like collaboration is always good, but not quite sure where that gets us here (if a thought was to use that as a base I mean). It may be simple at first, but then someone needs gestures working on a rotated tileset etc....

Here's a question. If you stripped away the tile_layer, (or even all the "/layers" is flutter_map that complicated (or buggy...there may be a new issue since 2.8.0 but leaving that aside for the moment) ? What are the complex elements, that people struggle with (as I struggle with some bits others probably struggle with something else, that would be needed in any other solution). Some bits I haven't really looked at. Suppose you removed all the layer code and only had them as plugins....(not suggesting that...yet :D).

Flutter_map can have plugins, and I think that's been the focus really of the way for the future updating for new features etc, as contributors come and go which makes sense to me. Want a new performant tile_layer ? Then actually it's not that insanely difficult to add one as a plugin. Want a new/amended performant polyline layer ? Again, it's not that difficult to write a new one stripping out the unwanted bits, or adding better bits. There are some issues around consistency (i.e with gestures and stuff)

That's possibly also the way to try and isolate some of the fiddly bugs. Write a simpler plugin to do the same job. See if it has the same issues (then it's either core flutter_map or Flutter itself).

I feel like the key is fixing the core stuff and not adding more. If a new feature is needed, do it as a plugin. If it's felt it becomes essential, then roll it in as an integral layer or feature later ? (I think a few private methods could be public though).

Now, if I had more time, I'd thought about something like a flutter_map_plus, keep flutter_map core maintained (even without layers), and then add a layer of useful features for people as plugins somehow (things like geolocation, geojson, clustering). Providing new or alternative plugins somehow, but could easily just lead to more mess and be even harder to maintain.

/ramble