You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 22, 2024. It is now read-only.
Something I plan to do hopefully sometime in 2024 is a graphic user interface.
Currently, the sketch editing that's needed now has always been somewhat of a stopgap until I worked my way around something better. But since enough people have apparently been paying attention, I think some streamlining would be in order.
Part 1 would necessitate moving from hard-coded preprocessor defines and statements to variables (which should be okay since we aren't supporting the 32u4 devices, which was the original intention) as well as moving things like pin configuration, enabling/disabling features, and etc. from the sketch into the EEPROM/Flash. Essentially, this would be getting it to a state where we can distribute just a .uf2 bootable file like GP2040-CE does (but preferably for all supported boards). The ideal is a single file, but because of the scope of supporting multiple boards we would have to provide multiple files depending on the board.
Alternatively, we COULD make a graphical user interface that runs on the PC and wraps around arduino-cli, meaning the user still has to build locally but we could just provide a single archive that has everything they need. And so we don't fall into the same trap as... other gun systems, this would have to be cross-platform: at minimum, supporting any-arch Linux (preferably a native toolkit, i.e. QT) and Windows.
Part 2 would be allowing more gun configuration from the PC side - since the pause mode workflow, while handy, isn't super flexible for anything that isn't GunCon 2-spec in terms of buttons/layout. Again, following GP2040's lead on this, having everything be configurable at runtime would be ideal over re-flashing. If we go the PC GUI route, we could use that to facilitate configuration all in one app - whereas if we're doing distributable booter files, it would have to be either a dedicated configuration app (assuming we don't go the former route) or making some kind of integrated webUI via RNDIS (if anyone has examples of that, please do let me know!).
To clarify, this will only happen after I finish the pending feature requests (so only after I get analog sticks support [#5], analog output support [no issue yet, but pending], and finish everything related to RGB [#9]), since it'll be much easier to make the transition when the featureset is set in stone rather than having to implement new features alongside a massive code refactoring and UX shift.
Looking forward to hearing thoughts on what people would prefer.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Something I plan to do hopefully sometime in 2024 is a graphic user interface.
Currently, the sketch editing that's needed now has always been somewhat of a stopgap until I worked my way around something better. But since enough people have apparently been paying attention, I think some streamlining would be in order.
Part 1 would necessitate moving from hard-coded preprocessor defines and statements to variables (which should be okay since we aren't supporting the 32u4 devices, which was the original intention) as well as moving things like pin configuration, enabling/disabling features, and etc. from the sketch into the EEPROM/Flash. Essentially, this would be getting it to a state where we can distribute just a .uf2 bootable file like GP2040-CE does (but preferably for all supported boards). The ideal is a single file, but because of the scope of supporting multiple boards we would have to provide multiple files depending on the board.
Alternatively, we COULD make a graphical user interface that runs on the PC and wraps around arduino-cli, meaning the user still has to build locally but we could just provide a single archive that has everything they need. And so we don't fall into the same trap as... other gun systems, this would have to be cross-platform: at minimum, supporting any-arch Linux (preferably a native toolkit, i.e. QT) and Windows.
Part 2 would be allowing more gun configuration from the PC side - since the pause mode workflow, while handy, isn't super flexible for anything that isn't GunCon 2-spec in terms of buttons/layout. Again, following GP2040's lead on this, having everything be configurable at runtime would be ideal over re-flashing. If we go the PC GUI route, we could use that to facilitate configuration all in one app - whereas if we're doing distributable booter files, it would have to be either a dedicated configuration app (assuming we don't go the former route) or making some kind of integrated webUI via RNDIS (if anyone has examples of that, please do let me know!).
To clarify, this will only happen after I finish the pending feature requests (so only after I get analog sticks support [#5], analog output support [no issue yet, but pending], and finish everything related to RGB [#9]), since it'll be much easier to make the transition when the featureset is set in stone rather than having to implement new features alongside a massive code refactoring and UX shift.
Looking forward to hearing thoughts on what people would prefer.
Beta Was this translation helpful? Give feedback.
All reactions