feat: add static Marker.computePixelAlignment method to calculate absolute alignment

[monsieurtanuki]

What I've done:

• Created a factory Marker.withPixelAlignment in order to set pixel-precise marker alignment, cf. [FEATURE] (Re-)Support absolute Marker alignment #1771
• Updated the "Marker Layer" example to show that new feature with non)-standard "U-turn-left" icons
  

What can still be done:

• I'm open to name change or to constructor against factory - but I wanted to keep the const and I'm not sure we can do that if computing the alignment
• I can create another example, as reusing the "Marker Layer" for 2 distinct purposes can be confusing
• Now Marker has a specific pixel-alignment constructor that MarkerLayer does not have. Not sure if that would make sense to create a new MarkerLayer constructor with the left+top parameters being used as default.

Impacted files:

• marker.dart: added factory Marker.withPixelAlignment
• markers.dart: now a click on the map creates a new "U-turn-left" marker with custom alignment

[JaffaKetchup]

Now Marker has a specific pixel-alignment constructor that MarkerLayer does not have. Not sure if that would make sense to create a new MarkerLayer constructor with the left+top parameters being used as default.

This is a good point, and it makes me wonder whether it would be better just to have a more simple implementation where _computeAlignment becomes a static public method on Marker named computePixelAligment. Then we wouldn't need to have any new constructors, and everything would be much simpler. What do you think?

[monsieurtanuki]

This is a good point, and it makes me wonder whether it would be better just to have a more simple implementation where _computeAlignment becomes a static public method on Marker named computePixelAligment. Then we wouldn't need to have any new constructors, and everything would be much simpler. What do you think?

Looks good to me! I've just pushed it.
Perhaps this may deserve a specific example, e.g. where the MarkerLayer has an Alignment computed by Marker.computePixelAligment for U-turn-left icons, and U-turn-left Markers without specified Alignment.

[monsieurtanuki]

@JaffaKetchup Finally I've removed my inconsistent example and just kept the new static Marker.computePixelAligment method.

[josxha]

I personally liked the factory constructor better since it was more self explaining to me.
Seeing that the relative alignment gets calculated into top/left pixel values anyways I wonder if it would be better to make pixel alignment the default and give users the option for relative alignment?

But since non-realtive marker alignment is a much needed feature so I'm down for a static method.
Edit: It would be really helpful to hint to this static method and its usage from the default Marker constructor.

[monsieurtanuki]

I personally liked the factory constructor better since it was more self explaining to me.

I agree with you. It can still be done, in this PR or a next one.
The added value of the public static method is that it can be used for both MarkerLayers and individual Markers. Once you've understood it at the low level, you can use it at the high level.

Seeing that the relative alignment gets calculated into top/left pixel values anyways I wonder if it would be better to make pixel alignment the default and give users the option for relative alignment?

Possible, but I'd like to avoid breaking changes.
Besides, it looks like no solution (Alignment vs pixel) is the perfect one, and we may dance tango between both, cf. #1659, several times a year.

But since non-realtive marker alignment is a much needed feature so I'm down for a static method.

Cool

Edit: It would be really helpful to hint to this static method and its usage from the default Marker constructor.

I've just added

/// [alignment] may be computed using [computePixelAlignment].

I don't know how it works here: feel free to merge my PR when relevant.

[JaffaKetchup]

LGTM, thanks for this :)
I think it's good that we've distilled it down into the most vital component, we can always make the factories at a later point, as you said.