Nodelist with Playa addresses for burningmesh

[tschundler]

• move the heading list on oled devices from its own page to the carousel
• new "BRC" page in the UI, a single-column nodelist like this:
  

real address will have less text like "4:40&C-30" (30 ft towards the man from C)

---

this has more copy-paste than I'd normally be comfortable with, but I think more refactor to reduce duplication will make upstream merges more difficult. The refactors (eg single function to display time with units) should be in the main branch.

---

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • LilyGo T-Deck
  • LilyGo T-Beam
  • RAK WisBlock 4631
  • Seeed Studio T-1000E tracker card
  • Other: t-lora v2

IMPORTANT: This is more likely to introduce bad UI than #7252

[tschundler]

...something is wrong with this that is shows commits already in the repo with different IDs

[tschundler]

rebased - now the commits are correct.

[tschundler]

I noticed it includes nodes with no location at 12:49&407101ft
So I should fix the list to exclude those (maybe an update tomorrow night?)

Please do review, but don't commit yet. (fixed in 17-July commits)

[Xaositek]

I've looked through the code and flashed it to a RAK4631 and ThinkNode M1; in my opinion, it would be vastly easier to support long term, if we created a standalone frame for all the BRC navigational points that we called on demand.

The way its implemented at the moment results in menu systems unintentionally being available and functionality being moved differently from production code.

[tschundler]

if we created a standalone frame for all the BRC navigational points that we called on demand.

I'm not sure what you mean. What do you mean by "frame" (page/screen something else?), "navigational points" (your friends' locations on playa?) and "on demand"

There's a new page in the list of available screens. How would you get to it other than stepping through the list of screens?

results in menu systems unintentionally being available

Long-press opens the node favorite menu, which was intended - it's a variant on the node list, so that made sense. Or did you mean some other menu?

---

I'd be inclined to make the screen classes and not have separate places for icon vs menu vs title vs render - all just class methods, etc. It would be just a new class added to a list building up the available screens. But that's a bigger refactor for the main branch someday not by me.

Who knows where the code will actually go. (maybe you do?)

I suspect next year it would be likely re-integrated from scratch - that's why BRC.h/cpp is separate - I expect that will still be valid next year, but not the rest. And the rest I took the approach I did hoping it would be likely to easily merge the next months' changes without getting in the way. But I don't really know what is in the pipeline..

[Xaositek]

Looking at the code, I think we're really close; I would leave the bearings where it currently is and overall just add:
fsi.positions.nodelist_brc = numframes; normalFrames[numframes++] = graphics::NodeListRenderer::drawBRCList; indicatorIcons.push_back(icon_bm);

I would also remove this line as the Node Action frame doesn't apply to the BRC bits (the contents of the menu wouldn't affect the BRC screen).
|| this->ui->getUiState()->currentFrame == framesetInfo.positions.nodelist_brc

[ews]

Hi @tschundler and @Xaositek, I've implemented the "additive" fix that was discussed. The changes are in this single commit:

ews@9b257e8

I've also created a PR to your fork : tschundler#3

This restores the separate Bearings screen and adds the BRC screen without modifying core functionality. I am absolutely not familiar with this code, so please take a look and suggest changes if needed.

[tschundler]

So you find that a better user experience?

Moving the bearings to the rotating pages was a choice for a better UX with fewer pages to step through on a 1-button interface, and less to visually scan in the tabs at the bottom of the screen.

But if others think it's really better with the extra screen to click through, let's use ews' version.

[Xaositek]

So you find that a better user experience?

Moving the bearings to the rotating pages was a choice for a better UX with fewer pages to step through on a 1-button interface, and less to visually scan in the tabs at the bottom of the screen.

But if others think it's really better with the extra screen to click through, let's use ews' version.

The goal here was to ensure the long term simplification of the BRC additions to the firmware. That way next year, if we have merge conflicts or other issues, we have decent parity with the firmware itself and only managing a couple changes directly within the BRC frame.