Improve RioLog UI

[ThadHouse]

Currently, the RioLog viewer UI is really basic, and kind of not great looking, If somebody is better at UI's, some help here would be greatly appriciated.

[pgfisico]

See also #22

[pgfisico]

For reference, here is the current UI:

[pgfisico]

These are the buttons at the bottom of the current UI, and what I would propose doing with them:

Pause - Remove functionality
Discard - Remove functionality
Clear - Keep

Pause and discard overlap with other functionality. You can discard by disconnecting. You can achieve a pause effect by allowing autoscroll to be disabled (or disabling it intelligently when the user scrolls). Pause and Discard are confusing and unclear.

Don't Show Prints - Replace with log level selector
Don't Show Warnings - Replace with log level selector

Use a selector to select log levels of "Error", "Warning", and "Print". Showing one level implies showing all higher levels (e.g. "Warning" implies "Error" is also visible). The selector should act as a display filter only, and not cause log messages to disappear permanently from the interface.

Disconnect - Keep
Don't Show Timestamps - Keep
Set Team Number - Keep

Switch to Viewer - Remove functionality
Save Log - Remove functionality

I think it's possible to build RioLog without save/load functionality. If you want to save the log, you copy and paste it into a file. The markup should always allow a copy/paste to work without messing up the log. Removing this functionality makes RioLog much simpler.

I realize removing this function is a significant change. As an intermediate option, consider only supporting a save option. The log would be saved as a text file and not in JSON. The saved log would match the current display in the UI (e.g. it respects the log level, show timestamps, etc. but excludes any colouring).

[pgfisico]

Here's a quick idea for a new UI I've put together

In the new UI I would propose:

All controls remain sticky at the top
This is because as log messages come in, they appear at the bottom. Keeping all controls at the top leaves them out of sight when you are watching logs, but still keeps them accessible. Putting the controls on the side could cause annoyance when logs reflow as menus expand/contract.

The top bar provides quick access controls. Right now I'm thinking it would have:

• Log level setting
• Clear button
• Autoscroll/jump to end button (Autoscroll gets disabled when user scrolls away and the button chnanges to a jump. When you jump or scroll to the end, autoscroll turns back on)
• Disconnect/Connect Button
• Connection status light

There would also be a menu button that is always visible. Clicking it expands the top bar to provide the secondary controls including:

• Team Number setting
• Show Timestamps setting
• Auto reconnect setting
• Scrollback setting (maximum number of log entries)

Always expand stacktraces
Right now the stack trace is automatically hidden. There is no visual indication that you can click to change visibility. I think this functionality is unnecessary.

Option to display log level with message
The colouring is nice, but won't be always be preserved with copy and paste and is definitely lost in a plain text file. I think the UI should either always include a prefix indicating message type (e.g. ERROR/WARN/PRINT), or have an option to show it. If a text file save is used. It should probably always appear in the file.

Use well known icons where possible
For example use a hamburger icon to expand the menu.

Nice to have

• Respect the current VS Code theme and adjust colours accordingly

[ThadHouse]

One thing to note is the viewer is a webpage, and none of us developers have any html or web development experience. So any development in this area would have to be done by an outside contributor.

Also, we would like to keep as few dependencies as possible in order to make building and maintaining easier on our side.

That being said, we are pretty much happy to review any ideas, and I like the concept posted by you. If you can translate that into code it's definitely on the track we are looking at.

[pgfisico]

I have a few questions about the current implementation/functionality:

• ErrorMessages have several other fields such as numOccur, flags, or errorCode. Are these unused? Are they important to display somewhere?
• The current implementation doesn't ensure messages are arranged by sequence number. Are messages always emitted from the roboRIO (I believe they are coming out of FRC_NetComm somehow) always going to be in order? For example, say two messages have the same timestamp. I would assume the one with the lower sequence number should be displayed first.
• There seems to be a convention around location and callsStack in an error message. Is the call stack always separated with newlines? Can the newline vary (e.g. <CR><LF> vs <LF>)? Do you always have both location and callStack? Might one language just give a callStack without location?
• What are the timestamps? Right now they are fixed to three decimal places. Would that ever need to be configurable?

[ThadHouse]

They're not super important to display them to general users. I don't think the ds console displays them.

Messages do come from netcomm in order, so we just need to display them in the order they come in.

I believe the new line can vary based on the language it comes from, and also it's possible to have either or both of the call stack and location fields empty. The API on the robot side accepts them as separate strings, and a user if they wanted could pass anything to them.