Steve: it’s not just about zoom max, zoom min, it’s about more things. I repeat: it’s not about you, it’s about us.
Personally, I tryed to solve those problems two years a go , even I pull a request. If you remember time a go, somebody ask to upgrade the google’s api version to 9.4.0 do you remember? Because it take a lot of time I gave up and I decided to quit my development canceling my suscripción. Time after I re started to play with the cn1 because it’s simple and you can get good results if you don’t push so much the functionalities and it’s because that why I started this thread, simply asking if nobody needs before some functionalities or if did and each one keeps those improvements for themselves. If the right option is the second , I asked to my self :”why if we use this tool to simplify our projects, why we don’t contribute to make it more robust?? Enviado desde mi iPhone El 27 ago. 2018, a la(s) 09:33, Steve Hannah <[email protected]> escribió: > It looks like this thread really comes down to the OP wanting some specific > features in the google maps cn1lib (max/min zoom)? As far as I can tell, > there's never been an RFE for this. It might be a simple thing. Best thing > to do is file an RFE in either the Codename One issue tracker (preferred) or > the codenameone google maps issue tracker, describing the specific feature > addition (or as specifically as possible). > > The outstanding pull requests in the googlemaps cn1lib weren't merged because > they have many conflicts with the master branch and it isn't clear what > problems them solve. The issues that they address have likely been fixed > already in the master, in a different way. I should really just close them, > but haven't gotten around to it, > > For non-trivial pull requests, it is best to start with an RFE so that we can > provide feedback and some direction. This will make it much more likely that > the ultimate PR will be merged. For the pull request itself, it is best if > it only makes necessary changes for the feature. Smaller and more specific > the better. Commits should preferably be squashed so that it comes in one > commit into the master. When I look at a pull request that involves 30+ > changed files, spanning 12 or 13 separate commits, where most of the changes > are extraneous to the RFE, it is very time-consuming to sift through it. -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/7D019538-548D-4D02-8BFE-772EEA3896F0%40gmail.com. For more options, visit https://groups.google.com/d/optout.
