New Calibration User Interface (and general overhaul) #32
Conversation
…ional! As well as adding some futureproofing against mismatched amounts of settings/pin function types/etc. Though the biggest benefit is that the board drawing routines are now entirely automated using information from OpenFIREshared.h - should make life significantly easier for people looking to add new boards to the project! Also cleaned up and reduced some redundant variables, the beginnings & majority of code plumbing, and prepping for migrating serial-related subroutines to its own methods. Only bug I noticed so far is that toggling custom pins over and again will cause some toggles to get unset.
…yways And a bunch of other small cleanups and minor fixes that I honestly forgot about...
Currently the cali version of the fullscreen cali window only applies to profile button 1, as I plan to make the "profile x buttons" dynamically allocated rather than fixed size arrays of elements.
…ion system over Debugging the highlight copy method specifically took way longer than I'd like to admit... the descriptive texts also don't cover the profiles screen yet. Pin highlighting requires that each board vector be modified to add glow elements with specific IDs, with formatting also needing to be manually tweaked in a text editor. BUT, it works dammit.
This uses a basic 8x8 tileset that's in use in quite a few Sega Dreamcast/Naomi-era titles for debug purposes, and is commonly seen in arcade Test Mode screens. It felt appropriate to recreate that feeling in our new fullscreen areas that resemble the function of arcade test menus anyways. Bitmaps were split from its original 128*128 spritesheet, and then renamed to their appropriate ASCII value. On a sidenote, the spritesheet seemed to have been organized in such a way that it's a near exact match for the ASCII characterset, down to the accented glpyhs in the upper 128 area, but since we don't use these they have been omitted from the upload. A new function, GenerateText, takes lists of Strings and interprets it by character, pasting the matching character code from the bitmap folder into a buffer pixmap long enough to store the intended text - one pixmap for each line - and then all bitmaps are merged to create a complete Pixmap that can then be assigned to an intended graphics pixmap item. Currently, only some of header text (mostly regarding the calibration heading strings) has been replaced with this bitmap method, though I intend to use this throughout all permutations of the cali window presentation. The original items will remain, but will be commented out in the end for simplicity; these could be reinstated if, for instance, multi language support is needed, as the bitmap only covers basic English Latin characters. And yes, this was deemed to be much easier than making a TTF to bundle with the app and simply loading it as a normal font instead, as these bitmaps are technically colored (namely the embedded shadow) which seems nearly IMPOSSIBLE to create without some expensive, proprietary font creation software or a degree in FontForge--neither of which I was keen on doing. So I made this instead. Stubbornness for the win...?
- Tab switching will reset the text of descriptive boxes corresponding to the tab being switched. - Resolve layout snafu and reinstated board vector widget flags that will let boards without center/beneath pins be visible again. Currently, there is a known issue that loading two consecutive boards with custom pins enabled will cause the second board's input map to have some entries be erroneously unmapped.
…PI-aware scaling, internal option for using font text instead. Bitmaps will now be used by default, with the original font-based text currently left intact but hidden behind a toggle that determines whether elements will be drawn with generated pixmaps or system monospace. There is no user-visible toggle for this though, but could be exposed somewhere down the line if necessary - could still serve as a build-time toggle. There is now a set of preset sizes that texts (both bitmap/system font) will pull from programmatically, currently based simply on scene resolution. The level of scaling needed is only calculated once for potential speed/mem benefits. Each call to a font size/scale set will now pull from this calculated value provided by GetTextScale.
…ough the output sent to the board is still in decimal, as that's what it natively uses) Added an iterator-style validator that checks for invalid (read: not 8-bit ASCII) characters in the Product Name textbox, and rejects the input with a red coloring to indicate this. Other small tweaks and fixes to enhance the user experience.
|
As formerly in #33 (since it applies to this, not in current master): Describe the bug To Reproduce Expected behavior System Info Additional context RE: I guess there's some duplication nonsense going on that I missed when I cleaned up some of the inputs map framework. Oops. |
|
If you start the calibration from the app, it would be useful to be able to have a way to cancel/exit the calibration routine from the app. Maybe use the escape key, similar to the IR test screen? |
- Cali Window: Added receiving and rendering of in-progress calibration stats, and allow the window object to carry its sender's slot so it can print the results back to the main app window. - This in part deprecates the old style "UpdatedProf:" all-in-one method of updating profile stats after the fact, as this is much more stable and safer (and allows for providing a better user experience overall). - Main Window (serial): Fixed reading of button tester state updates to check whether it's in-bounds or not. Fixes potential crashes from earlier in-dev firmwares.
…at didn't actually work despite having a perfectly working example of the exact same behavior a couple of lines above
|
8ad9898 resolves what I originally thought was overzealous pinbox deduplication, but was instead just some redundant code and a bad path on my end. Oops. @SawdustMaker This can be done, but will require at least firmware from the refactoring in TeamOpenFIRE/OpenFIRE-Firmware#47 for the board to be able to see and respect the cancellation request from the desktop. |
|
Testing builds updated:
Aside from the above fixed bug and the small request, I think everything looks good here! |
|
Escape to exit calibration added in 4279a3d (again, only when using the latest firmware from the Refactor branch/PR - it isn't documented on the screen but should be fine as the functionality is consistent with every other fullscreen window's exit functionality) |
…tsmap before updating test labels
IR and Centre points scale with screen res.
|
When using a mouse wheel to scroll, it is easy for a pin assignment to be unintentionally changed. Is it possible to require the user to click on a pin assignment dropdown before allowing the value to be changed? I don't recall if older versions of the OF app had this same behavior, if so I may not have noticed since the pin assignment tab previously showed the full height of the PCB by default and scrolling was not necessary. |
|
That's just a side effect of having scroll areas to make the application visible on narrower displays - previously there wasn't any area to scroll in for it to be a problem. Either way, 6ea4780 doneso. |
|
Anyways, I think functionally this new source should be doing the job fine to supersede the current one, and we'll get feature creep by holding this up any longer. LGTM. |
3 participants
TL;DR: Windows Builds for testing here (OpenFIREapp_dev.zip) (updated: 3/4/2025 @ 8:08PM EST)
You might notice the two different types of builds attached in the zip: Qt6(.8.2) is the NEW framework that has Windows dark mode awareness and is generally more efficient, while Qt5(.15.2) is the same framework that current App releases are built on, but lacks dark mode awareness.
Qt6 does run only on Windows 10 as a minimum, but the RP2040 drivers only officially function on that as a requirement anyways. Qt6 is planned to be the minimum going forward, but Qt5 will remain an option if the user invokes
-DOFAPP_QT_VERSIONS=Qt5as a CMake flag at build time.True to the title, the main benefit of this PR is to replace the clunky original calibration "system" (which really just pulled up a basic message box, which was far from intuitive and revealed things like the occasional Windows-only cursor wraparound bug) with an initial fullscreen calibration interface. This UI relies on information that's discretely sent in FW 5.x to signal to the app what stage of the calibration it's at, and to pull up the correct information.
The text for this window is inspired by a Sega debug font that's used in a number of their Dreamcast/Naomi titles - specifically meant to replicate the gun sight screens of an arcade game's test mode of the era, only less terse and more user friendly.
The same fullscreen window framework is made to be reusable; one such example is replacing the really short "test mode window" with an actual test screen, including an explanation of how test mode works.
Finally, from the File dropdown menu, there is a new IR Emitter Alignment Assistant utility - this replicates the functionality of the diylightguns' alignment page locally within the OF Desktop App, to help users align their sensors to the display. This screen scales the "Square Layout" boxes accordingly to be (hopefully) roughly the same distance on any aspect ratio display.
On a side note, the fullscreen interface
AppCalidoes reference the resolution of the primary display to scale the contents of these screens, to the best of its ability; notice how the alignment screenshot above is 720p, while the others are 1440p.Aside from this, the PR also updates some other aspects of the main interface, addressing feedback received over the current shipping interface (App v2.2, circa Nov 2024):
*.oflfiles, and imported back into the application! These files are each tagged with the board that it's exporting of, so that only files corresponding to the particular board can be imported back in.on_comPort_indexChangedmethod with hardcoded everything), and making the profiles area and elements not arbitrarily limited to the current firmwares' four profile limit (meaning it can theoretically support as many profiles as possible, though four will remain the publicly shipped cap).To comment on how the board highlights were made, as well as the refactoring done; this was due in part to breaking apart all the constants used across the OpenFIRE project into an external submodule, TeamOpenFIRE/OpenFIRE-Boards. This facilitates a couple of things with the end goal to make developing the project as a whole more seamless:
OpenFIREshared.h- this allows the app to be aware of new settings types that should be supported, just by updating the submodule.OpenFIREshared.h, so you don't even need the app itself pulled to add a new board or change aspects of supported boards.This info will at some point be provided within the OF-Boards repo's readme itself, but each board vector had to be manually modified to support pin highlights. Any existing (and valid) board vector can still be used with the app, but interactive pin highlights need to be added as such:
OF--and create a series of ellipses or closed paths for each pin. Each object's ID has to be individually titledOF_pinX, where X is the GPIO number corresponding to the pin it goes with. Make sure the ID specifically is changed, not just the display name!#ebe713ff, meaning its fill opacity is 100/max - then set the Object Opacity to 0.0, meaning it should be invisible.<path> object corresponding to anOF_pinXpath, make sure that it's laid out with the ID as the first line, and then thestylelaid out beneath **without prepended space**. The first object in thestyle=line should be"opacity:0;`. Refer to the below code snippet for visual reference for what these two lines should look like:OpenFIRE-Boards/boardPics/vectors.qrc- the file can be named whatever, but make sure that it has an alias that is named exactly what the identifying board string is inOpenFIREshared.h. Now, rebuild the app and test to make sure the new/replacement file works as a resource when loading the board in the Desktop App and test if the highlights appear when hovering over the pinboxes.That's a lot to go through, but this PR ended up being much bigger than originally intended.
EDIT: Custom layouts feature closes #15