-
Notifications
You must be signed in to change notification settings - Fork 20
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
Cockpit should have a tutorial #1286
Cockpit should have a tutorial #1286
Conversation
Will review it right now. Sorry for the delay. |
src/App.vue
Outdated
<div | ||
v-if=" | ||
!widgetStore.editingMode && | ||
!interfaceStore.showMainMenu && | ||
interfaceStore.mainMenuStyleTrigger === 'center-left' | ||
" | ||
> |
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.
We did raise the eslint
rule for line chars right? Is it still giving us trouble?
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.
We did, but it seems to be an issue between code formatters. It will be addressed in a future task.
src/stores/appInterface.ts
Outdated
setHighlightedComponent(component: string) { | ||
this.componentToHighlight = component | ||
}, | ||
setMainMenuVisibility(value: boolean) { | ||
this.mainMenuVisibility = value | ||
}, | ||
setMainMenuStep(step: number) { | ||
this.mainMenuCurrentStep = step | ||
}, | ||
setCurrentConfigComponent(componentIndex: number) { | ||
this.configComponent = componentIndex | ||
}, | ||
setKeepGlassModalAlwaysOnTop(value: boolean) { | ||
this.isGlassModalAlwaysOnTop = value | ||
}, | ||
setTutorialVisibility(value: boolean) { | ||
this.isTutorialVisible = 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.
Are those methods needed?
One of Pinia's advantages is that it doesn't need mutation methods, and one can easily set the values from both inside and outside the store directly.
Unless we need the methods to create side-effects (like we do when we set the widgets view index for example, where we need to confirm if the index is valid), I think we can get rid of them.
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.
You are correct.
Those methods should exist in Pinia, only when some extra logic has to be applied on a state change.
Changing that..
@@ -182,7 +204,7 @@ | |||
:selected="false" | |||
@click=" | |||
() => { | |||
mainMenuStep = 1 |
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 seems to me that the wizard logic got very coupled with the main-menu logic, inside this component file, specially with the currentConfigMenuComponent
variable.
We can follow with this for now, but it would be important for the future to uncouple than, specially since the wizard will also be used for other parts of the application, like the edit mode and the toolbars.
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 agree with you.
The idea is to design easy to reuse (but not yet completely generic) components until they need to be reused. This way we save coding time until the component has an real need to be re-instantiated along the app.
Once the wizard is in fact reused, its code will change a bit to be more generic and this coupling will no longer exists.
src/views/ConfigurationUIView.vue
Outdated
@@ -152,4 +156,8 @@ const interfaceStore = useAppInterfaceStore() | |||
const updateOpacity = (value: number): void => { | |||
interfaceStore.setBgOpacity(value) | |||
} | |||
|
|||
const resetColorsToDefault = (): void => { | |||
interfaceStore.setUIGlassEffect(0.8, '#4F4F4F1A', '#FFFFFF', 25) |
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 good to interesting to concentrate those default values in the defaults.ts
file, so it gets easy to find and anyone can import from there if needed.
Oooo it makes sense! My bad! |
It was actually intentional, to differentiate the connected and disconnected state of the vehicle. But I agree with you. Changing the Cockpit logo color that dramatically wasn't right. We indeed should keep a branding consistency. I reverted the color to the original green, but made it a little bit darker when the vehicle isn't connected: |
c6cabdc
to
b8ea328
Compare
Didn't click the "don't show again" button, but even so, the problem is the opposite (it keeps showing again on every boot). tutorial-bug.mp4 |
b8ea328
to
3cf00ad
Compare
I see now what was causing the confusion. |
Nice! I actually think that the variable should be changed as soon as this last step is reached, so even if the user closes the dialog in any other way, or even refresh the application (?), the tutorial is seen already and won't re-appear. |
Signed-off-by: Arturo Manzoli <[email protected]>
Signed-off-by: Arturo Manzoli <[email protected]>
3cf00ad
to
f656a94
Compare
Done |
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.
All good now!
Great addition!
When testing, start with the vehicle disconnected, with a wrong IP for example.
Fix #1012