Unit Tests

To test various functionality automatically, particularly regarding save/load systems and widgets.

Eventually, multiple windows with shared stores and subscriptions should be allowed, but for now, all that's really needed is a simple guard.

TopicStore has kind of become a mess. To better support Sendables, non-topic widgets, etc. some overhauls are needed.

• Each subscribed topic must be given a label.
  • When setValue is called on the subscriber, it should only update values based on the label.
  • Single-topic widgets can ignore the label entirely.
  • Write-only topics can ignore the label entirely.
• Sane type-checking within TopicStore directly.
  • Widgets must pass a desired type with the label when subscribing.
  • If the value's type and the widget's desired type don't match, print an error to the console and refuse to update.
• Blank topics should not have listeners allocated.
  • No real purpose outside of memory issues.
• Single, all-encompassing subscribe method.
  • No need for all those different overloads and whatnot.

This will be a big change but will improve reliability in the long run.

https://www.chiefdelphi.com/t/qfrcdashboard-a-simple-high-performance-reliable-shuffleboard-alternative/445256/22

Should show air pressure, enabled status, and full status

waaah waah

https://www.chiefdelphi.com/t/qfrcdashboard-a-simple-high-performance-reliable-shuffleboard-alternative/445256/22

The key should be configurable in the settings and be saved to the JSON file.

TopicStore should not propagate changes to widgets that are not in the current tab as well.

Implement WPILib's cscore to search the CameraServer, and create a CameraViewWidget based on the url/port of that camera.

Implement the FMSInfo widget that exists within WPILib.

.

Register NT types in Filter Store, primitives and Sendables alike.

Goes with #17

FilterStore should be static, register ".type" values into Sendable topic types, NT topic types into primitive topic types. FilterStore does all the filtering currently in main.cpp, stores a filtered NT topics list.

Activate commands through button clicks (runOnce) or checkboxes (run)

On certain Windows machines--specifically stock Windows 10 builds--the Release builds crash immediately. Untested on Windows 11, but Ghost Spectre 22H2 and WINE both work fine. The setup executable is not affected, but the actual dashboard executable is.

Current workaround is to go to the debug build in the Actions tab.

Snap to the grid via drag and drop.

For new widgets, create a default constructed widget, and open the dialog after drop.

Otherwise, allow for resizing and dragging.

Rather than relying on manual registration of different widget types for different topic types, each widget will be required to register to a specific topic type (or multiple), specifying their "display name" and whatnot.

https://www.chiefdelphi.com/t/qfrcdashboard-a-simple-high-performance-reliable-shuffleboard-alternative/445256/22

Similar to the dial widget but not editable, default to 360 degrees, have 0 at the top, and add marking lines

Register values in the WidgetTypes enum at runtime.

Add the ability to pass any generic MetaObject and have BaseWidget construct a default and/or json-read copy.

e

and working windows builds

QDial is very limited, implement my own

Should have 360 degree range and a configurable starting point. (algebraic plane vs. top vs. bottom)

Will need a big red triangle pointing to the right direction

Currently effectively a no-op, need to implement load/save for NT server settings.

Allow for several shapes for Enum and Color Display widgets; including:

• Triangle
• Circle
• Square
• Hexagon (like FTC pixels)

And possibly more depending on game piece shapes and other factors.

Take an AdvantageKit-like double array and display swervy boys

Given the current rules, it's probably safe to assume that everyone's going for 4-wheel swerve. But if somebody asks for it the implementation must be adaptable to support custom layouts

Changes to topic values should propagate entirely from TopicStore, calling a setValue function of the widget.

Additionally, updates should ONLY be made if the value is updated.

These two changes should drastically improve performance

Save/load metaproperties directly, eliminating the need to manually implement fromJson and saveObject methods.

This will require a default constructor for every widget.

Individual fromJson method for each class.

Move some stuff to BaseWidget that happens to be common

Allow for multiple windows with shared topics and subscriptions.

use makemsix

depends on #60

Separate Double and Integer displays, I don't think NT likes them together.

Implementation of graphs.

Configurable settings:

• Timescale (or auto)
• X- and Y-axes (time available for X axis)
• multiple lines per graph
• Hover to see a value at a certain point
• export to CSV

Exactly as in Shuffleboard.

Should be much clearer where the robot is, with a dot at the center, configurable robot dimensions, and an arrow pointing out in the direction it's facing.

Similar to topic type registration.

Sendable-based widgets must register their topic type to the topic filtering store.

Depends-On: #7

Add a metaproperty to the checkbox widget to scale the checkbox size (1-50x?)

Use smart pointers because all this deletion stuff is kind of cancer

When doing certain drag and drop operations, the Field2d widget occasionally will shrink to an extremely small size or disappear entirely with a null pixmap.

This will require two changes:

• Ensure widgets are properly marginalized in the TabWidget layout
• Reimplement the pixmap drawing within the field image label

Generic types for primitives like strings, ints, doubles, bools, etc.

Generic types for widgets that display a color.

Generic types for widgets that display editable text.

Generic types for Sendable widgets.

More keyboard shortcuts, "what's up" guide, usage guide, about, etc.

Default to the bottom-level topic name for the title and don't open the properties automatically.

Sendable types, WidgetTypes, TopicTypes

Implement GitHub actions for automated building and testing, as well as prebuilt binaries.

100% need binaries in AppImage form and possibly Linux-System, as well as Windows. MacOS would be great as well but lower priority.

like Shuffleboard

https://www.chiefdelphi.com/t/qfrcdashboard-a-simple-high-performance-reliable-shuffleboard-alternative/445256/22