Redesign OSTree page (to fix "change repository" modal)

[garrett]

The modal currently looks like this:

Instead, it should probably be using:

• data list: https://www.patternfly.org/v4/components/data-list
• inline editing: https://www.patternfly.org/v4/components/inline-edit

Or a table with editable rows: https://www.patternfly.org/v4/components/table#editable-rows

Since there's a lot of interaction inside the dialog with different states, we might even want to reconsider using a sub-page instead of a modal.

---

Redesign mockups start @ #176 (comment)

Everything above that comment is a WIP on the path to the mockup. (Which is probably still interesting to see the thought behind things.)

[garrett]

Problems with the dialog:

1. Add new repository is a link, but should be a button. However, then it would clash with the other buttons in the dialog.
2. The inline editing is very weird and adds too much functionality in this dialog.
3. Adding a new repository closes this dialog and brings forth another... and dialogs should never ever call another one.
4. There's selection in the lists in the new PR, but this has nothing to do with selection... it has to do with which is active, not selected... selection is a temporary state to do something with an item, whereas active is a semi-permanent state.

However, redesigning this means we need to redesign the page itself so that it fits in properly too.

Here's a first start at that:

I'm not very happy with the repository part yet, but this is better than what we have. There's probably a better set of widgets for it. Perhaps we really want to make it show only the current repository and make the editing behind some sort of disclosure widget or inline editing. I don't know. But the goal is to split apart the current repo dialog, so editing and adding can be their own separate dialogs, while the main part is not in a modal.

We could probably drop architecture from being visible and filter the branch to be the only arch (or arches if there is more than one) avaialble. But we don't have to worry about the i386/x86_64 split. Would we need to worry about an ARM HFP / AArch64 split though?

As for the … menus, the repository actions would be:

• Edit, Set active, Delete

And the deployment actions would be:

• Pin, Deploy, Delete
• Unpin, Deploy, Delete

(In addition to the main action of update + reboot / roll back + reboot.)

We currently do not have pinning or unpinning capability in cockpit-ostree. This is how I think it would work, but it can be ignored and implemented later.

[garrett]

There are definitely some issues with the above mockup. The one that sticks out at me is that changing the branch probably would cause stuff to happen, so you'd have to confirm it somehow.

So, I think it is probably better if we just show informational stuff in the "OSTree source" card (or whatever we call it) and then go into a special inline edit mode for the entire card. Then you'd have to save it for it to be active. I guess. We'll have to spend more time on it. I wanted to communicate early thoughts on the design and the ideas behind it, even if it's not quite ready it.

But the rest should be pretty self-explanitory. The content of the expanded list should be the content of our current cards, even with the tabs, I guess. A big change is the information we bubble up to the list and using badges for marking things like new, active, pinned.

[garrett]

Here's how it would look like within Cockpit, using a PF4-like full page editing pattern (but with the editing action in the top-right, consistent with the rest of our card usage).

We aren't really editing things like this inline elsewhere in Cockpit, but it is a normal PF4 pattern.

Also, this is something that will not be changed often. And when it does, I think the OSTree list below needs to be refreshed, at least for the latest available item.

Default view mode

Editing "OSTree souce"

This makes it kind of modal-like without having to dive into another page. And then the actual modals (to add and to edit) will pop up over this like normal dialogs.

[garrett]

I just realized that the list has to be more than just deployments if we're going to have the latest available there as well. Deployments are what's on the disk. The new one is something that's available but not deployed yet.

Perhaps "Deployments & updates"? And have only newer versions than what is deployed available? Or consider an update to an available deployment? Or is there better terminology for this?

If so, we it could look like this:

[garrett]

Retrofit

Since having the status makes sense... why not retrofit this into something that resembles the PackageKit software updates?

Editing source

And editing the OSTree source would look like this:

[garrett]

Finally looping back around to dialogs, as this is all so we can detangle the odd dialog. 😆

Add repo

Edit repo

[marusak]

@garrett What about these errors? How should we handle those?

[garrett]

I guess an error would go in the status area, unless it's contextual based on an action.

Regarding this error specifically:

• Will updating still work with this error?
• Is there a way to fix it?
• Is there a way to ignore it?

[garrett]

Here's a higher def version I made in Penpot.

• I've reordered things, in order of uniqueness and importance.
• It now has headings, as it should.
• I dropped the "and reboot" as it's necessary and redundant. We'll have a confirmation modal that opens and we can message about rebooting in there.
• I split the version and bolded the first part, as it's the major release version.

[garrett]

Deployments and updates menu would have (at least) two items, clean up and reset:

Clean up action would have a modal with things to clean up, with non-interferring items (basically just cache) pre-checked:

Reset is kind of "destructive", as it changes what you have installed, but gets you back to a pristine deployment. You can remove packages added after the fact and those that have been swapped out (if someone was testing an alternate or adding an RPM as a one-off). But it's not fully dangerous (unless you expect those packages to be installed), hence a it's a warning and not a danger level. And items are not pre-selected. (The reset to original state would actually be disabled until something is checked.):

Kebab menu for individual items would have pin (or unpin, if something is pinned) and delete: