improve usability of other-team traffic while subject-located / clue forms remain open

[caver456]

Noticed during group debrief from full team training / MRA mock on 9/9/23. Subject located dialog prompts the operator to ask three questions, and can't be closed until something is typed in for each of the three fields:

• location
• condition
• resources needed

It's likely that the calling team will not have immediate answers to all of these questions, so, the dialog may stay open for a minute or two.

It's true that it would be good to have a radiolog entry right away. The system already does this to some extent: as soon as the SUBJECT LOCATED button is clicked, an entry is created (and accepted) that says the button has been clicked and the operator is gathering details.

So - what about traffic that may come in from other teams while the subject located dialog is still open? Similar issues for a clue dialog.

The system already provides for this to some extent, but, it could be made more user-friendly. These enhancements could be broken out into one-issue-per-enhancement, but for now they are just collected here:

• [x] blink (every second) the finger tab (in the NED) of the callsign/entry that has the pending subject located / clue dialog
• [x] on click (or other activation) of a finger tab that has a pending subject located / clue dialog, raise that pending dialog
• [x] incoming fleetsync traffic of a different team should still raise the new entry window, and that new call's entry widget - this should be the normal behavior, but currently the code blocks this behavior to keep the entry widget of the 'pending' call on top, which probably isn't the right way to go (unless it's during the continue-time, as usual)
• [x] respect hold time of clue/subject dialog before deciding to raise the NEW of a different-team incoming call
• [x] don't try to auto-cleanup new entry widgets that have child dialog(s) - debatably its own issue, since this would result in a loop
• [x] throb the child dialog (maybe a half second after raising) when its parent new entry widget is activated
• [x] throb child dialog when raised from message during new entry close attempt
• [x] send focus to child dialog after raising
• [x] create entries right away for whatever subject located fields are completed, e.g. 'SUBJECT LOCATED form: LOCATION = under a tree; data still being collected' or such
• [x] #686
• [ ] blink background/banner of child dialogs that are not currently raised to top
  • other indicators should be sufficient
• [x] add a prominent indication / flashing button on main window, or a small flashing movable stays-on-top window with a single button, when there is any pending message, i.e. when new entry window is hidden by a full-screen main window, since newEntryWindow and child dialogs no longer use StaysOnTop
• [x] test all of this when the main window takes up the full screen, since that's how it's normally used

Maybe:

• [ ] different blinking or other appearance change for team tab (in the main window) that has pending form/s
  • the other indicators so far should be sufficient, and this one might include some complexity
• [ ] beeping
  • the other indicators should be sufficient, an this one could become more annoying than helpful

[marcihenscheid]

I think the blinking would help to let the operator know that the open dialog is still pending a resolution. Is there a tone that could be added which may also help since other tabs blink as well?

[caver456]

I was thinking of blinking the message stack finger tabs, rather than the team tabs, but I didn't really define those.

Finger tabs:

Team tabs:

But now that you mention it, modifying the appearance of the team tab that has a pending form might be good too. Maybe just picking a blink color that isn't used yet, or doing something with the border of the tab, or the background of the team table. Will ponder, after taking care of the existing items on the checklist.

Not sure about the potentially confusing user experience of beeping - will work on the other items first and then we can see if we feel it's sufficient.

[caver456]

Right now, if there are two finger tabs, and one of them has a pending clue report, the clue report always stays on top of the new entry window. This should be changed so the new entry window can be on top, so that the other-team traffic can be entered as if there were no pending clue report. Example:

• there are two teams, 101 and 102
• new entry for 101: click 'LOCATED A CLUE' --> clue report opens, and is raised on top of the new entry window
• new incoming call from 102 --> 102 finger tab is added to the top of the message stack, and:
  • current behavior: the pending clue report for 101 stays on top of the new entry window
  • desired behavior: new entry window is raised on top when 102 is active; clue dialog is raised on top when 101 is active

[caver456]

This could get a bit simpler if we are ok with never setting the StaysOnTop hint for the clue report, but instead just raise it to the top actively from more places in the code. Raise it to the top when its finger tab is activated, but also when its team tab is activated; also raise it whenever anything in its parent new entry widget is activated / clicked. Combined with the visual indication of a pending clue report, this might make sense. Worst case scenario: the clue report dialog is completely covered by the main window or by the new entry window or by some other window. Can we sufficiently account for this case with the raise-from-more-places-in-code idea?

[caver456]

newEntryWidget.updateTimers() pauses all timers if there are any clue or subject dialogs open. So, respecting 'hold time' (to raise NEW for other-team calls if the hold time has passed while clue/subj dialog is open) won't work that way. Should updateTimers be changed to increment a separate hold timer for the clue/subj dialog, or something like that?

[caver456]

found a bug in passing; the fix is more than a one-liner and could have other side effects, so, solving it in a separate issue on master, to be merged back here:

if changeCallsignDialog is canceled rather than accepted, changeCallsignDialog.openDialogCount remains at 1, therefore newEntryWidget.updateTimer never advances the timer for that widget, and the timer stays at -1. Clue and subject dialog openDialogCount vars correctly decrement when those forms are canceled rather than accepted, because the decrement is done in closeEvent rather than accept. changeCallsignDialog currently does the decrement in accept. Moving it to closeEvent should do the trick. See if there are additional things that should be done in closeEvent rather than accept.

[caver456]

The 'add a prominent indication...' checklist item turned out to be pretty involved, with many sub-features wrapped into that one item. That entire item is complete in recent commit 9cc8444. Should probably back-annotate to create an indented checklist, as a record of all the features wrapped into that one item.

[caver456]

blinking the finger tab has turned out to be challenging. Basically, because each fingertab has a stylesheet (set in newEntryWindow.init at self.ui.tabWidget.setStyleSheet), setting the background color without affecting other stylesheet entries is tricky. Looking at the different options to set the background color:

• html for the tab text - this seems to work but doesn't look that great
• set the entire stylesheet on each blink - haven't tried yet - this should probably work but seems like the nookyular option
• palette - this doesn't look great either since the background goes all the way to the left edge, clobbering the border

[caver456]

Blinking the text only, between red-bold and lightgray-bold, looks pretty good and very attention-getting. This can be done with html-only, and doesn't affect the stylesheet:

...
w=tb.layout().itemAt(1).widget()
n=self.newEntryWidget.instances[i-1]
t=time.strftime("%H%M")+" "+n.ui.to_fromField.currentText()+" "+n.ui.teamField.text()
...
w.setText('<font color="red"><b>'+t+'</b></font>')
...
w.setText('<font color="#ccc"><b>'+t+'</b></font>')

still need to write up the timing and logic, inside updateTeamTimers, but this should be a good solution to the blinking-fingertab portion of the issue.

[caver456]

next problem: getting a consistent font size on the blinking fingertabs.

The first fingertab to blink has the same font size as when it was non-blinking.

Subsequent fingertabs fonts get bigger when set to blink.

• setting in the blink html has no effect (same value as in newEntryWindow.addTab)
• adding font-size:9pt; to all fingertab stylesheet entries in newEntryWindow.init has no effect
• behavior and sizes are unaffected by changing globalStyleSheet font-size
• subsequent fingertab font sizes stay at 9pt correctly as specified in newEntryWindow.addTab
• larger-blink fingertabs return to 9pt when child is removed / when blink stops
• setting in the blink html has no effect

This might be related to the consistent problem of the first entry font in the newEntryWidget being smaller and all subsequent entry fonts being larger. Maybe a global font size (stylesheet?) is getting overridden after the first entry is created.

[caver456]

Noticed that the font size difference exists on the 1920x1080 external display at home, but, not on the laptop display. The font sizes stay the same on the laptop.

This post looks interesting, regarding font sizes on different resolution displays: https://stackoverflow.com/questions/75960018

[caver456]

This one indicates that just upgrading to pyqt6 does the trick. Probably worth a shot. https://stackoverflow.com/a/76257081/3577105

[caver456]

for a few reasons, it's probably best to consider the fingertab blink item 'done', i.e. don't worry about the font sizes for now, and move on, and make a separate issue for upgrading to pyqt6:

• there's good indication from the stackoverflow post above that upgrading to pyqt6 will resolve the first-time-font-size issues
• there's no other obvious solution, after looking through all references to font-size and setPointSize in the code (though I didn't actually try setting the widget font with .setFont on each blink)
• the problem doesn't happen on the laptop display - only on the lower-res external display
• if pyqt6 fixes this font size issue, it may also fix some other font size related issues
• pyqt6 came out in Jan 2021. It's time.

Add the pyqt6 upgrade issue to the v4 roadmap, for now - but move on to continue other work on this issue so it can be closed and merged before pyqt6 upgrade.

[caver456]

On to the 'create entries right away' item. Some ideas:

Add a label in the subject located dialog, that shows a countdown something like this: 'RadioLog entry with progress on this form so far will automatically be saved in 15 seconds'. Maybe with a reminder that it's OK to leave the form open until all fields are populated with initially-known data. Rules for the label:

• hidden if the form fields are blank, or if the field values are unchanged since the last automatic entry
• countdown resets to max (15 sec?) (and displays if previously hidden) on textChanged in any field (per keystroke; don't wait for tab-out)

the auto-generated entry should say something like 'data still being collected'.

[caver456]

auto-generated entry flow is working nicely, that task is finished in the previous commit. Noticed that it may not be appropriate to delete the entire message body after auto-opening the subject located dialog due to keywords.

Compare these two entries.

Auto-opened from keywords:

SUBJECT LOCATED form completed: TIME: 0737; LOCATION: asdflkj; CONDITION: asdfkj; RESOURCES NEEDED: sdf; OTHER: [SUBJECT LOCATED form opened automatically, based on words previously typed by the operator: "searcher foot broken and located subject"]

Opened by clicking the SUBJECT LOCATED button after typing 'searcher foot broken':

searcher foot broken; SUBJECT LOCATED form completed: TIME: 0738; LOCATION: sgf; CONDITION: dsg; RESOURCES NEEDED: sdfg

The second one seems much safer. If there was important info typed before the keyword(s), they should probably appear at the start of the message, rather than in the brackets at the end of the message.

Pondering...

[caver456]

options:

1. don't change the current functionality: keywords and anything typed before them appear only in brackets at the end of the entry: "SLF completed: \<data> [SLF opened automatically, based on 'searcher foot broken and located subject']"
2. keep all initial typing verbatim, including keywords, and also in brackets at the end: "searcher foot broken and located subject; SLF completed: \<data> [SLF opened automatically, based on 'searcher foot broken and located subject']"
3. keep all initial typing verbatim, but omit from brackets at the end: "searcher foot broken and located subject; SLF completed: \<data> [SLF opened automatically, based on typed keywords]"
4. if the triggering keywords are adjacent, delete them from the message, but if they are not adjacent (there may be important typing between the keywords), leave all initial typing in the message; omit initial typing from brackets: "searcher foot broken and; SLF completed: \<data> [SLF opened automatically, based on keywords]" or "searcher foot broken and subject Paul located; SLF completed: \<data> [SLF opened automatically, based on keywords]"
5. others?

[caver456]

Thinking option 3 is best. It's complete, it gives readable entries, and it doesn't involve any intrusive changes.

The initial typing should also show up as an entry when the subject located form is automatically opened. Example: currently, when 'searcher foot broken and subject Paul located' is typed, the SLF opens and this entry is automatically created:

RADIO LOG SOFTWARE: 'SUBJECT LOCATED' form opened; radio operator is gathering details

no mention of searcher foot broken happens until the automatically generated entry - and the foot wording is buried in brackets at the end (or until the SLF is accepted, which is what option 3 refers to)

RADIO LOG SOFTWARE: radio operator is still collecting data for the 'SUBJECT LOCATED' form; values so far: OTHER: [SUBJECT LOCATED form opened automatically, based on words previously typed by the operator: "searcher foot broken and subject paul located"]

Maybe that first entry should say something like 'searcher foot broken and subject Paul located ['SUBJECT LOCATED' form opened; radio operator is gathering details]

This question is getting a bit convoluted. Breaking it down, there are three entries to consider when the SLF is opened from typed keywords:

• [x] initial automatic entry

  • RADIO LOG SOFTWARE: 'SUBJECT LOCATED' form opened; radio operator is gathering details
  • improve this to include initial typing, as mentioned in the lines above

• [ ] pending automatic entries due to countdown while SLF is still open

  • RADIO LOG SOFTWARE: radio operator is still collecting data for the 'SUBJECT LOCATED' form; values so far: LOCATION: sdf; OTHER: [SUBJECT LOCATED form opened automatically, based on words previously typed by the operator: "searcher foot broken and subject paul located"]
  • should the initial typing appear on each intermediate entry? probably not

• [ ] final entry when SLF is accepted

  • SUBJECT LOCATED form completed: TIME: 0647; LOCATION: sdf; CONDITION: sdfg; RESOURCES NEEDED: df; OTHER: [SUBJECT LOCATED form opened automatically, based on words previously typed by the operator: "searcher foot broken and subject paul located"]
  • improve per option 3 above

As long as the initial typing appears at the start of the initial automatic entry, there's probably no need to turn the initial typing into its own entry - that would be redundant.

[caver456]

After incorporating the first checklist item from the previous comment (keeping the initial entry as typed, appending the note about automatic SLF), the second and third checklist items seem unnecessary.

Here's the three-message sequence after incorporating the first item (from a manual [non-fleetsync] entry, using keywords rather than clicking the SUBJECT LOCATED button or pressing its hotkey):

• searcher foot broken and subject paul located [RADIO LOG SOFTWARE: 'SUBJECT LOCATED' form opened automatically; radio operator is gathering details]
• RADIO LOG SOFTWARE: radio operator is still collecting data for the 'SUBJECT LOCATED' form; values so far: LOCATION: place; OTHER: [SUBJECT LOCATED form opened automatically, based on words previously typed by the operator: "searcher foot broken and subject paul located"]
• SUBJECT LOCATED form completed: TIME: 0602; LOCATION: place; CONDITION: ok; RESOURCES NEEDED: things; OTHER: [SUBJECT LOCATED form opened automatically, based on words previously typed by the operator: "searcher foot broken and subject paul located"]

Manual entry using the SUBJECT LOCATED button rather than keywords:

• RADIO LOG SOFTWARE: 'SUBJECT LOCATED' form opened; radio operator is gathering details
• RADIO LOG SOFTWARE: radio operator is still collecting data for the 'SUBJECT LOCATED' form; values so far: LOCATION: place
• SUBJECT LOCATED form completed: TIME: 0607; LOCATION: place; CONDITION: ok; RESOURCES NEEDED: stuff

confirmed that the sequences are the same as above for fleetsync and nexedge calls.

Odd detail: for a fleetsync call, if SLF is opened from keywords, there is a newline after easting in radio location, but, not when SLF is opened by clicking the SUBJECT LOCATED button. Should be easy to track down...

[caver456]

Removed the newline in a small commit. This part of the issue is complete.

Discovered an unrelated bug in updateTeamTimers when there is a spacer (two teams in different groups) - to be filed separately.

[caver456]

fixed #686 on this branch; closing this issue and merging to master, though some careful beta testing should be done, as this whole feature could be fairly confusing for the operator