containers
Different colour header on top of modal for push images
Bug description
If you go to push an image, there is some odd colouring happening at the top?
Operating system
mac m1
Installation Method
None
Version
1.10.2
Steps to reproduce
Push any image
Relevant log output
No response
Additional context
No response
All modals bellow are using the --pd-modal-header-bg variable which is black or gray depending on the theme
https://github.com/containers/podman-desktop/blob/88907772c08058ac7bb91a79e9afec367f43ca75/packages/main/src/plugin/color-registry.ts#L808
| Modal | Screenshot |
|---|---|
Install Extension from OCI image |
|
Create a new container |
|
Share your feedback |
|
Push image |
|
Edit Image |
|
PreferencesProviderInstallationModal.svelte |
N/A |
TroubleshootingPageStoreDetails.svelte |
⚠️ The modal in TroubleshootingPageStoreDetails.svelte is very buggy
Some of the modal have a purple line between the header and the body. We probably need to define some guideline to choose a consistent style for the modals, as for the majority we are not using some specific color for the header.
Is there a way we could get rid of the black header and the purple line? It's an older iteration of the modal dialog. I dont think there's a need to have them there anymore. The spacing between the header and the body text would have to be adjusted too probably.
They should all match this one:
Just commenting a mock-up I have for the modal dialogs:
Elements like the input field and dropdown are to follow the guidelines we have already.
Will I log a ticket for the implementation of removing the headers and following the layout above?
@ekidneyrh just to confirm - action buttons should always be at the bottom and aligned to the right?
All of these dialogs were created when we had a different design, especially the ones with a purple underline are at least '2 generations' out of date.
TBH I thought Charlie was opening this up for implementation/fix more than confirming the design. I agree we should either create a new issue with the list of dialogs above and knock them off, or just add the list to the description here and reassign.
From an implementation perspective, I think we should add title/close action as optional properties of Modal to ensure consistency, also in case we ever have another design iteration. Right-aligned slot for buttons as well. Or, we create a Dialog subclass that does this.
From an implementation perspective, I think we should add title/close action as optional properties of Modal to ensure consistency
I think Modal should stay generic, so it can be used for the Quickpick and other Modal. A component with some utility properties could be made, but should be name differently and not included in the Modal component.
I think having the modal follow the format, and as Tim said, make the Title and X button optional.
And just add the content in like you would on a page. Maybe just limit to input fields, dropdowns and file uploads.
The styling of the 'content' text (anything other than the header and actions) should just be normal, no bold or heavyweight.
I took a look at creating a reusable Dialog that has a standard header/content area/button bar, but I ran into two design questions @ekidneyrh :
- The last design (and hence most of the dialogs today) used the 'link' style button for Cancel (purple text with hover), but in the design above it is 'secondary' (grey text + outline). Is this an intentional switch?
- The feedback form uses the space to the left of the buttons for validation, e.g. 'Please select a smiley'. Is this a good pattern to keep/allow other dialogs to use, or should it be 'up' in the content area?
I had feedback on the standup that the (optional) validation area is useful, and button style can easily be changed later, so I went ahead and put up a PR for a basic Dialog component.
* The last design (and hence most of the dialogs today) used the 'link' style button for Cancel (purple text with hover), but in the design above it is 'secondary' (grey text + outline). Is this an intentional switch?
That was from me playing around with the primary and secondary buttons, so it can be ignored for now. Apologies for that.
The work on the PR is great and fixes the issue :) Thanks!