rethink automatic callsign prefixes - 'Team ' doesn't always make sense

[caver456]

From the top, when typing to open a NEW, typing '1p42' will open a NEW for 'Team 1p42'. In this case, the callsign should be '1p42' instead of 'Team 1p42'. It would be nice if, while typing the callsign, the 'Team ' prefix could be removed as soon as a non-'Team' callsign syntax is recognized. This could also be applied during typing in CCD.
Think about whether this is suitable for all teams. Maybe build that syntax test based on tabGroups or such?

[RadiosPRN]

It would be nice if this was easily customizable. For our use case I would prefer not to prefix Team at all. We frequently use other assets like boats, drones etc as well as individual unit numbers that apply to a person instead of a team.

[caver456]

Good point. I'll probably broaden the scope of the issue to reinvestigate the whole idea of team name prefixes and such - it makes sense that 'Team ' shouldn't necessarily be a universal default assumption. If there's a way to make it more universal without needing an option setting, that will win. I could see something like "don't prepend 'Team ' until enough typing happens to determine that it is a 'Team'". Since there are already callbacks happening on each keystroke in the callsign field, and again when the field loses focus, then something can probably be figured out.

…

On Thu, Sep 26, 2024 at 9:18 AM RadiosPRN ***@***.***> wrote: It would be nice if this was easily customizable. For our use case I would prefer not to prefix Team at all. We frequently use other assets like boats, drones etc as well as individual unit numbers that apply to a person instead of a team. — Reply to this email directly, view it on GitHub <#768 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEPCEZXIC5JMFOI2UCW4JIDZYQXT3AVCNFSM6AAAAABOXNYUQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGQYDMMZQGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[caver456]

Here's one idea:

• if the first typed character is a number, prepend 'Team ' [the current behavior]
• on each subsequent keystroke, check against all expressions in tabGroups; if there is any match, and the group expression doesn't start with 'Team ', remove the prepended 'Team '
• on loss of focus / editing finished, if the typed callsign is a full word in the phonetic alphabet, prepend 'Team '

So, you could expect this:

1. typed '1' --> callsign field is populated with 'Team 1' (this is what happens now)
2. then type 'p' --> callsign field has 'Team ' removed, and becomes '1p' (for us, a tabGroup expression is "^1[tpndovg]0-9]+" such as '1p42')

another example:

1. typed 'a' [after 'f', since 'a' is a hotkey with a different function, but 'f' brings up a new message dialog ready to type a callsign] --> callsign field remains 'a'
2. editing finished after typing 'alpha' --> callsign field becomes 'Team alpha'

In the case of phonetics, note that autocomplete will already allow the operator to select 'Team Alpha' after just typing 'a'.

After trying the above plan, if needed, an optional setting could be added 'prependTeamBehavior' or such: 'standard' or 'never'.

[caver456]

The main trick with checking per keystroke is the matching of the text typed so far against the first part of the expression. Posted a stackoverflow question.

Also noted this piece of the current code:

	def teamFieldTextChanged(self):
		pass # no longer needed due to better post-edit checking

The only issue with post-modification-only would be that operators used to seeing 'Team ' as soon as they type '1' would no longer see 'Team ' until they tab out of the field. They might think this is odd before tabbing out, and then end up taking the time to move the cursor to the left and type in 'Team ' by hand - so it could become a net time-waster. Need to ponder how big of a concern this is.

[caver456]

Got some signs of life, based on responses to the stackoverflow question: use the regex module instead of re, since its methods have an argument 'partial=True' that does exactly what we're looking for. And, it seems quick enough to walk through all the tabGroups and check for a partial match on every keystroke.

import regex
p=r'^1[tpndovg][0-9]+'
regex.match(p,'1p',partial=True)
<regex.Match object; span=(0, 2), match='1p', partial=True>

The question now is whether these automatic-changes-during-typing can be kept reasonably clear and consistent. If these changes cause potential confusion during typing, the idea should be reconsidered.

[caver456]

How bout this in teamFieldTextChanged (the per-keystroke callback) - it's stateless, and prefix-agnostic (if it works) - will try coding it up later:

#768 - should the callsign as typed so far be prepended by a prefix such as 'Team '?
#   to answer this question, look at each tabGroup's expression; if it has a prefix, then,
#   callsigns matching the remainder of the pattern should also have that prefix:
#   for the pattern '^Team [0-9]+', callsigns partially matching '[0-9]+' should have 'Team ' as a prefix.  
#  if yes, then prepend the prefix if not already there;
#  if no, then remove the prefix if it exists;
#  if unsure (partial match for multiple tabGroup expressions), make no change to existing callsign

Not sure about this, since the 'if no' clause assumes we know what prefix to remove. Maybe build a list of possible prefixes by looking at all tabGroup expressions.

[caver456]

@RadiosPRN I started a spreadsheet to keep track of what-is-and-what-should-be; can you share your tabGroups from your config file (if any) so I can try some more scenarios out?

[caver456]

@RadiosPRN also, more importantly, can you share some examples of callsigns that you use, and if any of them have standardized prefix words? (Team, Rescue, Truck, etc)

[RadiosPRN]

I have not set up tabgroups. It normally sorts appropriately for what we do so I haven't messed with it. Our more common prefixes would be Boat and Drone. We also occasionally use an individual's unit number which is typically 3 numbers and would not have a prefix for Incident Command members that may be away from staging/command and have occasional radio traffic.