Variable for %GPS in quick chat. Feature request #2653

[suteny0r]

#2653

Implemented %GPS variable for use in quick chat. First run inserts quick chat item for dropping location pin in message. It can be edited or deleted. On first run, if there are no entries in the quick chat table, this entry will be recreated. This also allows the user to change the URL to use any other mapping service instead of Google Maps.

This PR supersedes #3533

Thanks @deeno, good idea.

[deeno]

@suteny0r Uh thanks, though I'm not sure what for?. 🧐🤨

[DaneEvans]

AI crap, detekt. Then you can consider trying to hurry us up

[suteny0r]

@suteny0r Uh thanks, though I'm not sure what for?. 🧐🤨

You brought #2653 to my attention (on discord). It was a superior method of achieving the location pin drop that I had submitted, so I rewrote it and resubmitted it. The new method allows the user to modify the map URL to use any map service provider they like. It allows them access to the immediate send selector.

In contrast to waypoints, this method allows the user to send to private channels, and to DM individual nodes. It also doesn't have the 'anyone can delete the waypoint I just created' problem. Waypoints in general are just a bad way of communicating position. They are static. If you are travelling, the waypoint you create is a marker showing where you were, at one time, not where you are. Messages are ephemeral. You don't have to go back and clean up the ones you send. Its obvious that a location you drop in a message isn't meant to indicate permanence.

[DaneEvans]

I'm Deeno over there, he's someone else.

You still aren't getting green ticks here. Read the contributing.md, run spotless and detekt. delete the unnecessary AI junk, then I'll review it.

And stop trying to speed things up while not doing your part.

[suteny0r]

I'm Deeno over there, he's someone else.

You still aren't getting green ticks here. Read the contributing.md, run spotless and detekt. delete the unnecessary AI junk, then I'll review it.

And stop trying to speed things up while not doing your part.

Thanks for bringing that to my attention.

[DaneEvans]

why is this not a named tuple?

[suteny0r]

Now it is.

[DaneEvans]

should be checking for the presence of the string before it does any other logic.

if message.lower.contains ('%gps') 
     if <valid gps data> 
         <do the replace> 

if <any other quick message params we want?> 

[suteny0r]

Good catch. Now it does.

[suteny0r]

and now it does, properly.

[DaneEvans]

why are we changing this key?

[suteny0r]

The key was changed from uuid to position to fix a crash: Key "0" was already used.

Both the alert bell action and the default location pin action are created with uuid=0L (the default
value). When both are present in the LazyRow, this causes a key collision that crashes the app.

The position field is guaranteed unique:

Bell action: position = -1
Location pin action: position = -2 (or could be 0 if it's user-editable)
User-created actions: position = 0, 1, 2...
This ensures each item in the LazyRow has a unique, stable key for proper Compose recomposition.

[DaneEvans]

We're not going to serve a google link to the mesh by default.

[suteny0r]

Good point. I'll make it conditional on whether it's the f-droid or google build to use google maps or openstreetmaps.

[suteny0r]

The layout of the OSM URL required that I separate the %GPS variable into %LAT and %LON. The app now constructs the appropriate URL, depending on whether it is the fdroid or google build.

[justinormont]

Would it be possible to have a geo intent (geo:47.62148,-122.34814), which the app will highlight. When clicked android opens a list of apps which handle geolocation, and a user can also set a default app.

Geo urls can also be expanded to include other metadata sent to the receiving app, like a label to put on the point, e.g. geo:47.62148,-122.34814(FriendXYZ @ 2025-11-09 16:40).

This format still allows the lat/long to be copied/pasted manually.

Code to send the intent is something like: (note AI assisted example)

fun openLabeledGeoIntent(latitude: Double, longitude: Double, label: String? = null) {
    val uriString = if (!label.isNullOrEmpty()) {
        "geo:0,0?q=$latitude,$longitude(${Uri.encode(label)})" // Slightly different format than the sending format due to better app support if using a label
    } else {
        "geo:$latitude,$longitude"
    }
    val geoUri = Uri.parse(uriString)
    val mapIntent = Intent(Intent.ACTION_VIEW, geoUri)
    mapIntent.resolveActivity(packageManager)?.let {
        startActivity(mapIntent)
    }
}

Usage:

openLabeledGeoIntent(47.62148, -122.34814, "FriendXYZ @ 2025-11-09 16:40")

[suteny0r]

Would it be possible to have a geo intent (geo:47.62148,-122.34814), which the app will highlight. When clicked android opens a list of apps which handle geolocation, and a user can also set a default app.

Geo urls can also be expanded to include other metadata sent to the receiving app, like a label to put on the point, e.g. geo:47.62148,-122.34814(FriendXYZ @ 2025-11-09 16:40).

This format still allows the lat/long to be copied/pasted manually.

Code to send the intent is something like: (note AI assisted example)

fun openLabeledGeoIntent(latitude: Double, longitude: Double, label: String? = null) {
    val uriString = if (!label.isNullOrEmpty()) {
        "geo:0,0?q=$latitude,$longitude(${Uri.encode(label)})" // Slightly different format than the sending format due to better app support if using a label
    } else {
        "geo:$latitude,$longitude"
    }
    val geoUri = Uri.parse(uriString)
    val mapIntent = Intent(Intent.ACTION_VIEW, geoUri)
    mapIntent.resolveActivity(packageManager)?.let {
        startActivity(mapIntent)
    }
}

Usage:

openLabeledGeoIntent(47.62148, -122.34814, "FriendXYZ @ 2025-11-09 16:40")

Would this be a less portable way to implement the feature? There is an iOS client as well, which I hope to port this feature to, once the quickchat feature is implemented there. There is also a web client.

Remember, it's just a quickchat message template. It builds the template differently depending on whether the build is for f-droid (OSM) or play store (Google Maps), but the template can be edited to support any mapping service that lets you pass the coordinates as parameters.

[justinormont]

Similar technique on the Meshtastic browser client:

• Sender: (on browser client)
  • Sends a Geo URI "I'm at geo:47.62148,-122.34814" message (either from a newly implimented quick chat utilizing a browser's getCurrentPosition(), or a manually entered message)
• Receiver: (on browser client)
  • Parses the Geo URI
  • Creates an <a herf="..." target="_blank"> tag, but uses the existing Meshtastic browser client's geolocation technique:
    https://github.com/meshtastic/web/blob/7f21b3b531fce84794d7d417ca7daf0db911a069/packages/web/src/components/Dialog/NodeDetailsDialog/NodeDetailsDialog.tsx#L382-L392
  • Nothing to do on click, as it's a normal <a herf="..." target="_blank"> tag

Future item: I'd leave it for future fixes, but the linked to code could be further improved by adding a config item to allow the user to select which map service they'd like to use, as there isn't OS handling of geo intents which otherwise gives users control of which map app used.

[suteny0r]

I just noticed that the current browser client doesn't make even web urls clickable.

Since the current iOS client doesn't have quick chat yet, it can only view the links, not create them, and the web client can't even view the existing format without copy/paste, switching to this new method wouldn't be impacting the existing audience that much. I will see if I can get it working.

Thanks again for the input.

[justinormont]

I tested your newer debug build (on an isolated dev phone); it's working well.

One outlier case, if GPS Mode = DISABLED is set on the node, the "%LAT,%LON" doesn't get replaced with coordinates, producing a sent message of "geo:%LAT,LON":

Though likely the same result, you could also test:

• GPS Mode = NOT_PRESENT
• Before the node's GPS has a GPS fix
• GPS provided by the phone, which is under Settings => App => Provide phone location to mesh

[suteny0r]

now, if quick chat message contains variables that require location, button is disabled unless location is available. PR updated. Builds updated.

[justinormont]

That works. Thanks.

When disabled, the 📍 quick chat looks like:

The user may not know why it's disabled; that said I don't see elsewhere in the app where small pop-ups are used to explain a UI element. LGTM.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 0.51%. Comparing base (7372a3c) to head (7c27419).
⚠️ Report is 93 commits behind head on main.

Files with missing lines	Patch %	Lines
...n/org/meshtastic/core/ui/component/AutoLinkText.kt	0.00%	14 Missing ⚠️
...g/meshtastic/feature/messaging/MessageViewModel.kt	0.00%	14 Missing ⚠️
...kotlin/org/meshtastic/feature/messaging/Message.kt	0.00%	12 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##            main   #3535      +/-   ##
========================================
+ Coverage   0.49%   0.51%   +0.01%     
========================================
  Files        370     376       +6     
  Lines      22233   21255     -978     
  Branches    2543    2569      +26     
========================================
- Hits         111     109       -2     
+ Misses     22101   21126     -975     
+ Partials      21      20       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[justinormont]

Might recommend internally using the geo:0,0?q=47.6062,-122.3321(Our Office) format, due to Google Maps not producing a pin as mentioned in https://en.wikipedia.org/wiki/Geo_URI_scheme#Unofficial_extensions:

Google Maps adopts an unconventional approach to displaying the points: it shows the map for, but does not display a map pin, when a location is given in the standard way. A pin only shows up when given as the query. In other words, to show a pin at the Wikimedia Foundation office, one should not use geo:37.78918,-122.40335 but geo:0,0?q=37.78918,-122.40335.

Suggested change

	val geoPattern = Pattern.compile("geo:[-+]?\\d*\\.?\\d+,[-+]?\\d*\\.?\\d+(?:\\([^)]*\\))?")
	Linkify.addLinks(it, geoPattern, "geo:")
	val geoPattern = Pattern.compile("geo:([-+]?\\d*\\.?\\d+,[-+]?\\d*\\.?\\d+)(?:\\(([^)]*)\\))?")
	// For better support, internally transform to the geo:0,0?q=LATITUDE,LONGITUDE(LABEL) format
	val geoTransformFilter = Linkify.TransformFilter { match, url ->
	val coordinates = match.group(1)
	val label = match.group(2)
	"geo:0,0?q=$coordinates" + if (!label.isNullOrEmpty()) "(${Uri.encode(label)})" else ""
	}
	Linkify.addLinks(spannable, geoPattern, "", null, geoTransformFilter)

[suteny0r]

I actually wrote it that way to begin with, but ran into complications. "Some vendors, such as Android OS, have adopted extensions to the "geo" URI scheme:" such as the label in parenthesis after the coordinates. This unofficial extension requires URL customizations that in some cases are vendor specific. For example, "To add the label in Google Maps, it will be like: geo:0,0?q=37.78918,-122.40335(Wikimedia+Foundation)" changes it from passing lat and lon as params to turning them into query terms with those params, requiring a placeholder of 0,0 where the coordinates would normally go. When I first wrote support for OSM, in a previous version, it's URL format worked properly when coordinates were passed as parameters, but when converted to a query, using coordinates as search terms, it would often fail displaying errors.

In the end I decided I would rather not make it require specific layouts for particular mapping services, sometimes with conflicting requirements, and to just forego the label. Maybe when it becomes officially part of RFC 5870 it can be made to work across multiple mapping providers in a uniform way.

[suteny0r]

I changed my mind. The problems I had seen were from browser resolution of a hastily constructed OSM URL. I re-implemented the label to include the shortname, used the unofficial extension format, installed OsmAnd, and tested. It worked perfectly, and it is a lot nicer to have the label.

I'll be updating the PR momentarily. Thanks again for prodding me to make it better.

Since I'm not allowed to post builds on my fork here, if you want to see it you will need to click the 'suteny0r:location-variable' in the header and look in the right sidebar.

[suteny0r]

updates complete

[jamesarich]

@suteny0r don't post releases from your fork

[justinormont]

Does this match the full "geo:37.7749,-122.4194(foo)"? I think it stops before the '(' as it now requires a '?' char to continue the regex matching.

[suteny0r]

You are correct. Impressive catch. Now both forms of the geo: URL get parsed properly. Thanks. release Builds updated.

[justinormont]

You're going to have an issue with shortnames with a space, among other cases.

The space will break your new regex, and other items like shortName = "<')<" or ">))>" (my poor attempt at a four char ascii art fish), will break the Linkify URL parsing.

You're going to need URI encoding for the label:

Suggested change

	result = result.replace("%SNAME", shortName, ignoreCase = true)
	result = result.replace("%SNAME", Uri.encode(shortName), ignoreCase = true)

But this URI-encodes all uses of %SNAME.

Some options:

• Have a %SNAMEENC, which URI encodes
• Falling back to a %GEO token which directly get replaced with the full "geo:(${latitude),${longitude}(${Uri.encode(label)})"
  • Granted, I like the flexibility of independent replacement tokens, as I want to emit "geo:47.62148,-122.34814(FriendXYZ+@+2025-11-09+16:40)", which would be from hypothetical future tokens of "geo:%LAT,%LON(%LNAMEENC+@+$DATE+$TIME)" (timestamp is so folks don't confuse old map pins)
• Handeling on the receiver side -- from geo:47.62148,-122.34814, auto-append a label of who+when, if a label doesn't exist, before sending to Linkify

[suteny0r]

I applied your URI encoding change. (I can't believe I didn't think about that before)
I implemented %LNAME (but I did not add it to the template, I like the shorter label on maps)
The pin created is ephemeral (unlike waypoint pins) so adding date/timestamps seems unnecessary, as they only exist for the lifetime of the view session, and the messages they appear in already have a timestamp.

In the context of quick chat messages, it seems redundant to want to include an unencode version of the node name in the message, because every message will already have that (sender).

What sort of failure/fallback cases are you thinking about for the simpler %GEO message use?

[suteny0r]

Might I suggest %F0%9F%90%A0 for your fish? :)

[justinormont]

What sort of failure/fallback cases are you thinking about for the simpler %GEO message use?

No failure cases, just mentioning that you can use a %GEO token to produce the full message, and you wouldn't have to worry about when to encode %SNAME.

In your updated code, you're always encoding the %SNAME & the now added %LNAME too. This has the issue of URI encoding when not needed, like with a quick message of "Test message seen by %LNAME in SOMA"; sending %SNAME or %LNAME is useful as most nodes in my list don't have a name, so I assume others likewise don't know my node's name (even more likely for new nodes):

Web client view	Android client view
No names for most

I'm sure there's better use cases for node names that I'm not considering.

The pin created is ephemeral (unlike waypoint pins) so adding date/timestamps seems unnecessary, as they only exist for the lifetime of the view session, and the messages they appear in already have a timestamp.

The pins can be non-ephemeral once in the map apps, directly so if bookmarked, seen in search history, or used as a routing destination. I certainly have a ton of old bookmarked temporary locations.

Message timestamps are lost in store-and-forward; so if you're disconnected from the mesh when someone sends their location, you'll get the stored message automatically when you reconnect but it will have the current timestamp displayed on an hours old message, implying the sender is at that location now. Granted that should be fixed in store-and-forward.

Might I suggest %F0%9F%90%A0 for your fish? :)

I could make a case for spiky boi %F0%9F%90%A1.

[suteny0r]

I get it now. People may want to use the variable expansion in quick chat messages other than pin drops. Now I see why the *ENC variants would be useful.

I started out with this being a quick chat mod. currently the variable expansions only happen when quick chat messages are triggered. Should I expand it so that any manually typed messages in the message window can use variable expansions? I don't like making changes to areas outside of the scope of the enhancement, so I'm inclined not to do that.

I noticed that the other variables from your example, $date and $time don't actually work. Were they hypothetical or am I using them wrong?

I see now that it could be useful to ALSO provide a single %GEO expansion with the simple, non labeled version of the geo: URI

I'll go add that back in %GEO for single term expansion, in addition to the current set.

Do you think the URI encoding overhead is significant enough to warrant the complexity of only doing it when the variable is used?

[justinormont]

I started out with this being a quick chat mod. currently the variable expansions only happen when quick chat messages are triggered. Should I expand it so that any manually typed messages in the message window can use variable expansions? I don't like making changes to areas outside of the scope of the enhancement, so I'm inclined not to do that.

I don't have a feel for the Meshtastic repos, but it's likely easier to put in a MVP with a constrained set of tokens, like (%LAT, %LON) or %GEO, touching a minimal area of code, in the first PR. Letting users test the feature, and setting the basis for a discussion on what is useful and a followup of adding those tokens and further functionality.

Couple examples as precedent of a thought-though replacement token & operator scheme:

• Splunk uses a replacement token format of $token_name|u$ w/ the |u afterwards to indicate to URL encode the token value. In splunk, $env:user_realname|u$ would be the user's full username with URL encoding operator added.
  https://help.splunk.com/en/splunk-cloud-platform/create-dashboards-and-reports/simple-xml-dashboards/10.1.2507/drilldown-and-dashboard-interactivity/token-usage-in-dashboards#token-filters-0
• Mailchimp uses a *|FNAME|* for the user's firstname and *|URL:FNAME|* as an operator to URL encode the first name
  https://mailchimp.com/help/all-the-merge-tags-cheat-sheet

Takeaways from looking at replacement token implementations:

• All had a start AND end deliminator e.g #{TOKEN}# (Azure Pipelines), $TOKEN$ (splunk), *|FNAME|* (mailchimp)
• Most use namespaces, e.g. $server.serverName$ (splunk), *|USER:COMPANY|* (Mailchimp)
• Most have operators built-into the token to do things like lowercase, url encode, etc:
  • Terse: Most are short and combined w/ the token directly $token_name|u$ (splunk), and *|URL:FNAME|* (Mailchimp)
  • Verbose: ArcGIS has vary verbose style like <dyn type="mapFrame" name="MapFrameName" property="lowerLeft.x" units="dd.deg" decimalPlaces="2" showDirections="True"/> to get the longitude of the left side of the map rounded to two decimal places "122.31"
  • None that I saw had free-form scripting language, like ROUND($LAT$, 2)) for its operators

I might recommend:

• Start/end deliminators
• Using the namespaces from the Meshtastic protobufs
• Terse operators

E.g. $POSITION:LATITUDE$ and $USER:LONGNAME|U$ for a URL encoded long name. Though something more terse is nice too, like $LNAME|U$.

I noticed that the other variables from your example, $date and $time don't actually work. Were they hypothetical or am I using them wrong?

Hypothetical future tokens.

Do you think the URI encoding overhead is significant enough to warrant the complexity of only doing it when the variable is used?

Not sure what you're asking.