@odevices need some advice. I was planning to use the following key combinations for this paged view UI:
SHIFT + FOCUS : Next Page
SHIFT + UP : Previous Page
SHIFT + HOME : First Page
Do you think this would ever conflict with future er-301 plans/development? Also maybe there’s a good reason you decided not to add paging like this in the past. Any thoughts?
SHIFT+FOCUS at least is probably going to be used for other things. SHIFT+HOME is COMMIT so I would avoid that one.
Are you sure it is a good idea to have a special set of key combos that work just for your units? If I had to suggest a place to put access to alternate unit views/pages, then I would add them to the long-push menus like they already are for the existing views:
Long-push menu on unit header contains:
Long-push menu on a unit control contains:
So you would have the option of adding more views to the unit via the header menu and more control-specific views via the control’s menu.
Also, pressing ENTER on the header cycles through a unit’s views/pages while pressing ENTER on a control cycles through the control’s views/pages. That is the design intention but the current implementation is only aware of the above views and does not take into account custom views/pages. That should probably change.
Oops SHIFT + HOME is actually zero, so that’s certainly out of the question. SHIFT + ENTER is COMMIT. (Btw what is COMMIT for exactly? I don’t think I’ve used it before.)
I’m thinking more seriously about this long-press approach now… if I could tell which item the long-press scroll is hovering I could toggle the sub-screen views in real time.
I think there’s certain times when using the control sub-view is ideal, like showing the scope or a couple of related controls. But going forward there’s going to be times where the number of secondary controls you want to provide looks cluttered there, especially for non-modulatable parameters / options.
For a lot of my custom controls I’ve been gravitating towards the sub-screen to keep lesser used features out of the way but still immediately accessible. This is especially practical, I think, when trying to constrain the number of top screen controls to just 6 ply.
Edit: Oh hm here’s another wild idea: put multiple “spot” descriptors in a single ply so that one naturally scrolls over it with the encoder. Maybe kind of inconvenient though.
Ooops here too. That’s right. COMMIT is used in the multi-selection of files and in the hold view for example.
I also forgot to mention that long-push-and-release also cycles through the views. Basically, whenever you open the long-push menu, the next view is already highlighted.
I thought having the selected item in full WHITE and it’s z-order the largest (all other items are behind) would be enough? Here ‘collapse’ is selected:
I had tried it once years ago. I ended up not going that route because having a spot only accessible via the encoder and not the Mx buttons was (to me) potentially confusing. Still, maybe there are some special cases where it could make sense?
Ha sorry by “tell which item the long-press scroll is hovering” I meant programmatically. So I could use the index to modify the sub-screen view to show what that view will be if the Mx button is released.
Makes sense, yea it would be kind of confusing. A lot of my ideas seem to break the “simplicity first” rules of the existing UX
Ah! I see. I guess I could provide events? Something like onFloatingMenuEnter, onFloatingMenuCancel, onFloatingMenuChange, etc.
Currently there is only onFloatingMenuSelection which is generated after a selection is made.
That would be pretty excellent, I see that the floatingMenu object in the lua is global but never exposed so there doesn’t seem to be a hacky way to access its internal index.
Edit: hm that statement is misguided, I’m still reading the Overlay code and jumped to conclusions as always
No, you are right. The only officially available methods for the floating menu are currently:
-- shows the floating menu for the given UI object
Overlay.startFloatingMenu(o)
-- selects an item in the floating menu
Overlay.selectFloatingMenu(choice)
-- closes the floating menu and returns the current choice index
Overlay.endFloatingMenu()
So it looks like extending Observable in Overlay would allow the event pattern… I wouldn’t mind throwing that together real quick 
Well the encoder action is in C++ so definitely not as simple as I think it is 
Sure😉
FYI, I don’t think you need the Observable pattern here because the only object that needs those events is the object handed to Ovelay.startFloatingMenu.
You definitely do not need to touch C++ to do this. MenuArc::encoder(…) returns true if the selection has changed.
Read my mind
WIP will need to revisit for more complete testing later,
@odevices This does look pretty cool with the menu arc:
Perhaps kind of annoying if you want to set the gate for each one, one after another though. Maybe I could go to the next view on SHIFT + MX?
Edit: That does work out nicely, but the Section code has to be updated to honor the result of spotPressed to prevent opening the menu overlay:
-- SpottedStrip/Section.lua
function Section:spotPressed(viewName, spotHandle, shifted, isFocusedPress)
local view = self.views[viewName]
if view then
local spot = view:getSpotByHandle(spotHandle)
if spot then
local control = spot:getControl()
local index = spot:getPositionOnControl()
local handled = control:spotPressed(index, shifted, isFocusedPress)
-- Don't start the menu if the control handled the press.
if not handled and control.getFloatingMenuItems then
Overlay.startFloatingMenu(control)
end
end
end
end
-- polygon/PagedViewControl.lua
function PagedViewControl:getFloatingMenuItems()
return self.menuItems
end
function PagedViewControl:onFloatingMenuEnter()
self.subGraphic:setPage(0)
end
function PagedViewControl:onFloatingMenuChange(change, index)
-- The first index is always cancel
if index > 0 then
self.subGraphic:setPage(index - 1)
end
end
function PagedViewControl:spotPressed(spotIndex, shifted, isFocusedPress)
if shifted then return true end
return ViewControl.spotPressed(self, spotIndex, shifted, isFocusedPress)
end
function PagedViewControl:spotReleased(spotIndex, shifted)
if shifted then
self.subGraphic:switchPage()
return true
end
return ViewControl.spotReleased(self, spotIndex, shifted)
end
Why have you moved the original handling code out of Section? 
The idea was that the Overlay should trigger all the floating menu events instead of just the change/enter ones.
By keeping it in Section, Section would trigger the the “select” event and Overlay would trigger the “change” and “enter” events which isn’t very encapsulated.
Edit: of course I can just change it back, I don’t feel strongly about it. Just thought it was the right way to go
Not feeling strongly about it either 
I just have this sneaky feeling that it was there for a reason which I can’t remember now…
Conflicts with QUICKSAVE?
Ugh… yea. Maybe “isFocusedPress” will save me…
It was there because the control reference was Nil’d out in Overlay after the menu came up. I removed that line so Overlay has the control ref now