Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow logging data from very generic indicator #913

Conversation

ArturoManzoli
Copy link
Contributor

  • Allow logging of any variable the vehicle offers;
  • Custom VeryGenericIndicators now must have a Name and a variable to be accepted;
  • Unique Display Name for VeryGenericIndicators from now on. They can monitor the same variable, but with different display names. This is the reference for logging.

Closes #600

Comment on lines 120 to 128

const handleDeleteWidget = (event: DraggableEvent): void => {
const widgetData = container.value.widgets.find((w) => w.hash === event.item.dataset.widgetHash)

// Remove VeryGenericIndicator from Logged variables list
if (widgetData?.component === 'VeryGenericIndicator') {
CurrentlyLoggedVariables.removeVariable(widgetData.options.displayName)
}

trashList.value = []
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking on a system-architecture point of view, we are adding a child-specific handler here on the parent.
What if we pass an event to the widget that is being deleted and ask him to deal with it? This way we keep the parent without child-specific code and also allow any mini-widget to decide what to do when it is removed.

@rafaellehmkuhl
Copy link
Member

I think the situation where the user is already logging from a VGI will be very common, as there are default VGIs that the user will probably add to several views.

What if we put a "log that" checkbox in the VGI, and if the user clicks it and there's another one already, it offers to ovewrite the previous or change the name of this VGI?

@ArturoManzoli
Copy link
Contributor Author

I think the situation where the user is already logging from a VGI will be very common, as there are default VGIs that the user will probably add to several views.

What if we put a "log that" checkbox in the VGI, and if the user clicks it and there's another one already, it offers to ovewrite the previous or change the name of this VGI?

I agree that we must differentiate VGIs from different views.
The log configuration page already have the ability to switch them on and off. Maybe a cleaner idea would be to add, only on the logs configurations page, the view that the VGI is from. This way the user can decide over there to log them or not (check image below).
This solution anyway is kind of temporary since we are rethinking the way the user set the telemetry logs (#621 #875).

image

@rafaellehmkuhl
Copy link
Member

Will be discussing more about how to do it next week.

@ArturoManzoli ArturoManzoli force-pushed the 600-Allow-logging-data-from-VeryGenericIndicator branch from 5f6d4b6 to 6f5f88e Compare April 29, 2024 13:37
…gging lib

Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
@ArturoManzoli ArturoManzoli force-pushed the 600-Allow-logging-data-from-VeryGenericIndicator branch from 6f5f88e to dda6816 Compare April 29, 2024 13:55
@rafaellehmkuhl
Copy link
Member

rafaellehmkuhl commented Apr 30, 2024

From our discussion today:

Problem: The mini-widgets are being loaded/unloaded from the screen when the view is changed, which would make the logs specific to each view (not desirable).

Solution: We agreed to change the current code on the top/bottom bar to stop reloading then when views are changed, and instead render them all, showing only the one for the current view, as we are doing with the widgets themselves.

This makes the log configuration Profile specific, as desirable. This also fixes the undesirable behavior of having all the mini-widgets being visually reloaded when the view is changed, which differs from the widgets' behavior, which are pre-rendered and cause a much better experience for the user.

@rafaellehmkuhl rafaellehmkuhl marked this pull request as draft May 3, 2024 20:25
@ArturoManzoli ArturoManzoli force-pushed the 600-Allow-logging-data-from-VeryGenericIndicator branch from dda6816 to 659060c Compare May 6, 2024 17:49
@ArturoManzoli ArturoManzoli marked this pull request as ready for review May 7, 2024 14:04
<div class="flex w-[60%] flex-wrap">
<v-checkbox
v-for="variable in DatalogVariable"
v-for="variable in loggedVariables"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to have the items to be organized alphabetically, otherwise it's kind of hard to predict where it is.

Copy link
Member

@rafaellehmkuhl rafaellehmkuhl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't look at the code yet, but regarding usage, as mentioned in private, there are some bugs that appear to be related to reactivity:

  • Adding a new VGI makes the old ones disappear from the configuration list
  • Acessing the configuration of an already added VGI that appears with the same name in two views of the profile forces you to rename it
  • When the previous situation happens, sometimes the first VGI (the one that keeps the original name) does not appear in the configuration list

Refreshing the page seems the first and last items.


this.currentCockpitLog.push({
const logPoint: CockpitStandardLogPoint = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change can also be accomplished with this.currentCockpitLog.push({...} as CockpitStandardLogPoint).

No need to change, just a tip.

Comment on lines +420 to +422

// Remove miniWidget variable from the list of currently logged variables
CurrentlyLoggedVariables.removeVariable(miniWidget.options.displayName)
Copy link
Member

@rafaellehmkuhl rafaellehmkuhl May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I feel like this does not belong here. This is the widget store, but here we are coupling it with the logging system.

Can't we do this on the unmount of the widget itself?

@patrickelectric your input here would be good.

Copy link
Member

@rafaellehmkuhl rafaellehmkuhl May 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the time, so we do not hurt the roadmap, we decide to let this coupling how it is and open an issue to track a future improvement on it.

One of the ideas to solve this is to allow register of add/remove callbacks on the widget manager, so those interested can react to changes there.

Comment on lines +120 to 129

const handleDeleteWidget = (event: DraggableEvent): void => {
const widgetData = container.value.widgets.find((w) => w.hash === event.item.dataset.widgetHash)
if (widgetData) {
// Remove miniWidget variableName from Logged variables list
CurrentlyLoggedVariables.removeVariable(widgetData.options.displayName)
}
trashList.value = []
}
</script>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here as the last commit. This is specific to the VGI widget, but we are coupling it with the MiniWidget instantiation system.

Copy link
Member

@rafaellehmkuhl rafaellehmkuhl May 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the time, so we do not hurt the roadmap, we decide to let this coupling how it is and open an issue to track a future improvement on it.

One of the ideas to solve this is to allow register of add/remove callbacks on the widget manager, so those interested can react to changes there.

@ArturoManzoli ArturoManzoli force-pushed the 600-Allow-logging-data-from-VeryGenericIndicator branch from 659060c to 5e49b85 Compare May 7, 2024 17:56
Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
Copy link
Member

@rafaellehmkuhl rafaellehmkuhl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed outside here, the bug of changing a mini-widget name causing the others with the same name to disappear persists.

We agreed to use the widget hash instead of the displayName for tracking of each one, which will fix the bugs and UX problem.

Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
…s on delete

Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
…ing on drag-to-trash

Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
…ic for multiple views logging

Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
@ArturoManzoli ArturoManzoli force-pushed the 600-Allow-logging-data-from-VeryGenericIndicator branch from 96b39b2 to 570241a Compare May 9, 2024 17:24
@ArturoManzoli
Copy link
Contributor Author

As discussed outside here, the bug of changing a mini-widget name causing the others with the same name to disappear persists.

We agreed to use the widget hash instead of the displayName for tracking of each one, which will fix the bugs and UX problem.

The problems with multiple instances of mini-widgets were solved using an instance count. Since we don't need unique instances of the mini-widgets, and there is a 'refreshWidgetsHashs' method inside the 'miniWidgetContainer' which makes the VGI hashes mutable, the solution that treats all mini-widget instances as generic instances is simpler and more reliable.

Copy link
Member

@rafaellehmkuhl rafaellehmkuhl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything appears to be working fine now!

@rafaellehmkuhl rafaellehmkuhl merged commit 45c7171 into bluerobotics:master May 9, 2024
8 checks passed
@ArturoManzoli ArturoManzoli deleted the 600-Allow-logging-data-from-VeryGenericIndicator branch May 24, 2024 10:00
@ES-Alexander ES-Alexander added the docs-needed Change needs to be documented label Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs-needed Change needs to be documented
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow logging data from the VeryGenericIndicator
4 participants