attribution button with bar

[westnordost]

Fixes #174

Screen_recording_20250113_231257.mp4

I deviated from my suggestion in #174 because:

• No dialog: there's not really the need for a dialog, if the attribution text(s) are too long, they can just wrap to several lines
• No Text buttons but links in text: fully native and JS implementation is incoming. This means that parsing the attribution text+link will be redone and probably parsed directly to AnnotatedStrings
  
  which will enable to (correctly) have only parts of the attribution text link to the attribution source, as it should be and as it is done in MapLibre JS.
• no button background: personal taste, I guess. IMO the info button should not look like a regular (but smaller?) map button like the compass, etc. because it's rather related to the map than to the HUD-like UI on top of the map (just like the scalebar). It would IMO look weird to have a smaller mis-aligned button amongst other map buttons. Also, if the attribution text is shown fully before map move, it's quite fine to make this button somewhat unobtrusive. Anyway, I think this can be customized anyway with IconButtonColors? (didn't try)

I briefly tried out to give the info button 1px white halo, like the scalebar has, but in my eyes, this looked a bit disruptive, even though one would think it would look consistent with the scalebar.

Question:

• should the text links by default be styled? I am surprised there is no default styling for text links in Compose. E.g. colored like text buttons, with underscore-effect on hover.

TODO:

• The attribution should automatically retract when the map is being interacted with (i.e. moved) by the user. But I think there is no API for that yet, right?

[sargunv]

The attribution should automatically retract when the map is being interacted with (i.e. moved) by the user. But I think there is no API for that yet, right?

There is, it'd be the same technique used to stop following on user gesture in the camera follow demo, though it's not reliable yet on the JS side. It has caveats that should be fixed in the future (see #77). #230 should make this API robust.

should the text links by default be styled? I am surprised there is no default styling for text links in Compose. E.g. colored like text buttons, with underscore-effect on hover.

Maybe an underline by default? No strong opinion here, though it'd be nice if the links were visibly clickable

there's not really the need for a dialog, if the attribution text(s) are too long, they can just wrap to several lines

if such wrapping is unlikely with common map styles and common displays, sounds good to me

no button background

I agree having an unobtrusive button is best, but perhaps we can still include the background when the text is expanded? So it starts with the attribution text and button, then on gesture the text collapses into the button and the background collapses + fades.

[westnordost]

I'll look into it

[westnordost]

Implemented both suggestions. The issue with styleState.queryAttributionLinks() is that it only queries the current situation. If it changes, the widget is not updated. As a matter of fact, the attribution info for all the styles seems to be empty, at least at the time in which the attribution button is (first) composed. (I tested with a hardcoded attribution list.) Probably at that time the style didn't fully load yet.
So, it would be better if styleState.attribution was actually a field.

Screen_recording_20250115_015845.mp4

Maybe an underline by default? No strong opinion here, though it'd be nice if the links were visibly clickable

Tried it out. While still for each attribution the whole link is clickable, this looks odd. Also, I've looked into M3 guidelines, and they don't loose a word about in-text links (and TextButtons have a different appearance).
I think if the link is colored in the primary color (like text links) and underlined on focus, hover and press, that would be a good default in the future, but right now it would look odd.

[sargunv]

The issue with styleState.queryAttributionLinks() is that it only queries the current situation. If it changes, the widget is not updated.

Yup, it would be good to have it work through State, similar to camera position and camera move reason. That's #164

[westnordost]

So merging this is actually blocked by #164, because when a user just naively employed this, no attribution would be shown.

[sargunv]

Yeah I think so.

Still, thanks for doing this! Will review in a bit

[westnordost]

Regarding #250: Maybe it would make sense to allow the button to be align towards any corner. However, I didn't do this because I have not idea how to do it. When you review the code, you'll see that several things are aligned to the bottom right within the widget:

• the info button, so that it always stays in its corner, regardless of the height of the attribution info texts (which may grow to several lines)
• the texts within the attribution info field are aligned to the end
• the containing box aligns its content to the bottom right, so that the AnimatedVisibility animation also expands/retracts the content from/to there, respectively

It could be parametrized, but the issue is that it is a wild mix of Arrangement, Alignment and Alignment.Horizontal, so passing e.g. an Alignment will not work as it is not possible to inspect the fields of an Alignment (the bias is not part of the interface).

[westnordost]

I'll try out an idea how to implement this.

[sargunv]

it is not possible to inspect the fields of an Alignment

I've done this elsewhere in the library by just asking the Alignment instance to align a 1x1 box in some convenient rect. For an example, check how I map Alignment to Android gravity or the iOS bit mask for the SDK ornaments.

[sargunv]

I'm not sure if the material 3 library has tooltip or popup menu components, but if it does we could probably look at how they work too