-
Notifications
You must be signed in to change notification settings - Fork 22
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
Allow logging data from very generic indicator #913
Conversation
|
||
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 = [] | ||
} |
There was a problem hiding this comment.
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.
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. |
Will be discussing more about how to do it next week. |
5f6d4b6
to
6f5f88e
Compare
…gging lib Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
6f5f88e
to
dda6816
Compare
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. |
dda6816
to
659060c
Compare
src/views/ConfigurationLogsView.vue
Outdated
<div class="flex w-[60%] flex-wrap"> | ||
<v-checkbox | ||
v-for="variable in DatalogVariable" | ||
v-for="variable in loggedVariables" |
There was a problem hiding this comment.
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.
There was a problem hiding this 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 = { |
There was a problem hiding this comment.
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.
|
||
// Remove miniWidget variable from the list of currently logged variables | ||
CurrentlyLoggedVariables.removeVariable(miniWidget.options.displayName) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
||
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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
659060c
to
5e49b85
Compare
Signed-off-by: Arturo Manzoli <arturomanzoli@gmail.com>
5e49b85
to
96b39b2
Compare
There was a problem hiding this 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>
96b39b2
to
570241a
Compare
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. |
There was a problem hiding this 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!
Closes #600