Cockpit Files mockups

[garrett]

As I've been busy juggling multiple projects, I've been doing design work for Cockpit Files off and on, focusing on parts when I was asked about those parts and sharing the current status overall for context of those parts along with the parts of the UI I was asked about.

It's been scattered all over the place as a result. (And there were also parts in an internal-only Google Document too.) Everything was always up-to-date in Penpot the whole time, however.

I'll use this post here to share exports of the current state. I'm going to use follow-up comments to talk about various parts of the UI.

Additionally, here's a current snapshot of the Penpot source:

• Files-2024-05-23.penpot.zip

Live view @ penpot: https://design.penpot.app/#/view/1479d94f-56c1-8021-8004-2a833bae1b04?page-id=440d3b0f-e2f3-81b6-8001-ffb20ff25ded&section=interactions&index=5&share-id=064214a4-70ce-8065-8004-6b0cdf45a8fe

[garrett]

General

The UI, with a standard left to right, top to bottom approach, where elements before others affect elements afterward:

Bookmarks is first, then edit-path-mode, the path, filtering, view changing, then actions. On the next row are the files and directories and the details, which show either the current folder (if nothing is selected) or the selected item.

Editing uses the "standard" PatternFly inline edit pattern. Note: There's no React component for inline editing however, only designs and HTML. It does build upon standard PatternFly widgets, at least.

When an item is selected, such as this Document.pdf file, its details show up in the details sidebar.

The icons are based on ForkAwesome, just like PatternFly's icon set is based on FontAwesome, so they share a common ancestor. However, we're using outline icons and have general mimetypes for classes of files. We'll implement just a standard folder and file icon first and add types later.

[jelly]

When nothing is selected we don't show anything in the sidebar currently, this is not how it was designed.

Comparing the file details to the current implementation:

Current

Design

I would like to discuss where we move the kebab with selected item actions and if we change the current layout.

[garrett]

1. Correct; it's supposed to show the current directory unless something is selected.
2. Yep, we should definitely spend some more time on the sidebar together. What's in my mockups was originally based on the quick mockup from a long long time ago, just forward ported a few times.
3. I need to revisit the menus based on your feedback above, and we should figure out where that should go. (It was never in the sidebar in any mockup — I just checked all the mockups, including the absolute oldest ones from 2022. I guess that was added on the first iteration and incorrectly stuck around... perhaps even being inherited from the original Cockpit-Navigator?)

[jelly]

We should also show the total directory size somewhere.

[jelly]

We should also include the SELinuxx file context optionally when availabe.

[garrett]

Menus

Here are all the content related menus:

1. File context menu. This shows up when you right-click (or long press on mobile) on a file.
2. Directory context menu. This shows up when you right-click (or long press on mobile) on a directory.
3. Current directory context menu. This shows up when you right-click (or long press on mobile) on the current directory space (when you're not on a file or directory).

These also show up in the context menu of the content area when you have nothing selected (# 3), or when a file (# 1) or directory (# 2) is selected.

---

Then there is the sorting menu.

It comes from the grid/details toggle button, which looks like this:

(It shows a details button to switch to the details view from the grid view.)

(This shows a grid icon when in the details view, to switch to the icon grid.)

If we're going to combine the hiddle file toggle with the view dropdown, then it would look like this:

---

Then is the bookmark menu, which is what would show up at the top-left of the app. Home is always there. Custom ones are added bookmarks. "Add bookmark" adds the current directory as a bookmark. When you're in a directory that has been bookmarked, it becomes "Remove bookmark".

---

Lastly, is the global menu, which has actions such as undo/redo (undoing a move or copy command), integrations with other pages, a hidden toggle, and a way to see the keyboard shortcuts.

[jelly]

There is a lot to do from these mockups. Some quick wins would be:

• Copy the full path into the clipboard Copy action should also copy the full path to clipboard #253
• Allow sorting on filesize Allow sorting on filesize as well #200
• Show hidden files under the sorting dropdown. Which means it is in two parts of the UI? Is that expected?

File / Directory menu

• This lacks download which is now the last entry
• Rename file is just Rename and I think we intentionally simplified it (same for deleting)
• Copy exists, cut is not implemented yet.
• Symlink support was removed, this would need a whole new separate discussion

[jelly]

Regarding sorting:

From the File size sorting PR:

But what about the filetype sorting? Do we replicate nautilus behavior of showing the biggest (or smallest) files first and then folders?

Sorting by type is:

1. Folders first (Type: Folder)
2. General type alphanumeric (Archive for zip, tgz, bz2, etc.; Document for PDF, ODT, etc.; Image for PNG, JPEG, etc.)
3. Extension sorting, A-Z
4. Base filename sorting, A-Z

That's what Nautilus does, and it makes sense.

Nautilus has the mapping of types @ https://gitlab.gnome.org/GNOME/nautilus/-/blob/main/src/nautilus-mime-actions.c#L100-259

Here's the same thing in a JSON object

{
    "Files": [
        "application/octet-stream",
        "text/plain",
        "text/markdown"
    ],
    "Folders": [
        "inode/directory"
    ],
    "Documents": [
        "application/rtf",
        "application/msword",
        "application/vnd.sun.xml.writer",
        "application/vnd.sun.xml.writer.global",
        "application/vnd.sun.xml.writer.template",
        "application/vnd.oasis.opendocument.text",
        "application/vnd.oasis.opendocument.text-template",
        "application/x-abiword",
        "application/x-applix-word",
        "application/x-mswrite",
        "application/docbook+xml",
        "application/x-kword",
        "application/x-kword-crypt",
        "application/x-lyx",
        "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
        "text/markdown"
    ],
    "Illustration": [
        "application/illustrator",
        "application/vnd.corel-draw",
        "application/vnd.stardivision.draw",
        "application/vnd.oasis.opendocument.graphics",
        "application/x-dia-diagram",
        "application/x-karbon",
        "application/x-killustrator",
        "application/x-kivio",
        "application/x-kontour",
        "application/x-wpg"
    ],
    "Music": [
        "application/ogg",
        "audio/x-vorbis+ogg",
        "audio/ac3",
        "audio/basic",
        "audio/midi",
        "audio/x-flac",
        "audio/mp4",
        "audio/mpeg",
        "audio/x-mpeg",
        "audio/x-ms-asx",
        "audio/x-pn-realaudio"
    ],
    "PDF / PostScript": [
        "application/pdf",
        "application/postscript",
        "application/x-dvi",
        "image/x-eps",
        "image/vnd.djvu+multipage"
    ],
    "Picture": [
        "application/vnd.oasis.opendocument.image",
        "application/x-krita",
        "image/bmp",
        "image/cgm",
        "image/gif",
        "image/jpeg",
        "image/jpeg2000",
        "image/png",
        "image/svg+xml",
        "image/tiff",
        "image/x-compressed-xcf",
        "image/x-pcx",
        "image/x-photo-cd",
        "image/x-psd",
        "image/x-tga",
        "image/x-xcf"
    ],
    "Presentation": [
        "application/vnd.ms-powerpoint",
        "application/vnd.sun.xml.impress",
        "application/vnd.oasis.opendocument.presentation",
        "application/x-magicpoint",
        "application/x-kpresenter",
        "application/vnd.openxmlformats-officedocument.presentationml.presentation"
    ],
    "Spreadsheet": [
        "application/vnd.lotus-1-2-3",
        "application/vnd.ms-excel",
        "application/vnd.stardivision.calc",
        "application/vnd.sun.xml.calc",
        "application/vnd.oasis.opendocument.spreadsheet",
        "application/x-applix-spreadsheet",
        "application/x-gnumeric",
        "application/x-kspread",
        "application/x-kspread-crypt",
        "application/x-quattropro",
        "application/x-sc",
        "application/x-siag",
        "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
    ],
    "Text File": [
        "text/plain",
        "text/markdown"
    ],
    "Video": [
        "video/mp4",
        "video/3gpp",
        "video/mpeg",
        "video/quicktime",
        "video/vivo",
        "video/x-avi",
        "video/x-mng",
        "video/x-ms-asf",
        "video/x-ms-wmv",
        "video/x-msvideo",
        "video/x-nsv",
        "video/x-real-video"
    ]
}

I think we can do better though. Many of the mimetypes make sense; we can probably abstract some by searching the beginning of the mimetype string; for example, these match

Picture: ^image/
Video: ^video/
Music: ^audio/

The easiest is probably just matching the first part of the mimetype in a first pass and extend it later.

[garrett]

Uploads

When uploading files, a spinner is shown and it's selectable (with a hover over and cursor change to show that it can be interacted with).

A dropdown appears!

Individual uploads are created with flex sizing as shown in this above wireframe.

---

Sizing should be an ideal size with a min and max width. Text should wrap when there isn't enough room. Truncation would remove necessary information to know which file is which, especially when multiple uploads may have very similar file names.

---

When there's a file conflict, it should show a modal dialog.

Multiple files should be supported too. It's nearly the same dialog, but with an opt-in.

File details that are necessary to determine which is which are laid out side-by-side and actions mirror the layout, so reinforce which file you're preferring.

[jelly]

Related issue to upload #453

[garrett]

Permissions

File properties have the filename in the title. The filetype shows up as text immediately under the title.

Directory permissions are exactly the same, except they're a "Directory" type and have an option to recursively change permissions for enclosed files.

[garrett]

The goal was to use what was specified in this dialog with the enclosed files, not have a dialog on top of a dialog.

I do see what you're talking about with Nautilus, but it feels like that feature wasn't intended and/or didn't get the polish it deserves. You can see that not just with how there's a dialog on a dialog, but also with the weird padding, spacing, and completely different style of UI than the rest of GNOME, Nautilus included. And most of that is already represented in the first dialog. (The difference is the split between files and directories within the folder itself.)

Isn't this really just a workaround for the folders needing +x to access and the files not wanting to have +x unless they're actually executable?

Isn't the proposal to not handle it like Nautilus? Specifically:

#192 (comment)

chmod also has a way to say +X which means "add executable permission if any other user has executable permissions". That usually does the "right thing" for both files and directories (and also includes files that are executable files).

If we dumb down the dialog a bit and make it about read/write permissions only, and use +X in the same places we allow read permissions, it might make even more sense than having the full-blown GNOME approach (which breaks existing executable files).

(I agree with this, where we don't do it like Nautilus, but instead, do the right thing by handling directory-specific access automatically as @allisonkarlitskaya suggests.)

[garrett]

For reference, here are mockups for GNOME Files, which do something quite different from what's currently implemented: https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/master/files/properties-dialog.png

(...but I still think GNOME Files is not right here, and @allisonkarlitskaya is.)

[jelly]

Those new GNOME Files designs confuse me a lot. I think this all boils down to:

If I wan to change the permissions of a directory, do we offer the option to set directory permissions and permissions from the underlying files and directories.

[jelly]

So the conclusion is:

New button Change enclosed files => u/g/o/a+rX.

So for tests:

• check that we keep the executable bit for dirs and executables.

[jelly]

Current state:

[garrett]

Editing and viewing

Editing a file is basically a text area (with wrapping) in a modal. Cockpit Files is not an IDE. We may eventually add in some light syntax highlighting, but that would be a nice-to-have feature in the future. The goal is to do very simple edits and is not intended to be a remote developer tool.

Viewing a file is a read-only subset of file editing. It has a "Read-only" bubble in the title and the text area is read-only. Additionally, the primary save button has been swapped out for a secondary Close button and there is no cancel button.

[jelly]

Editing

For Editing a filewe have a button in the context menu, I assume we just use atextarea` and allow people to edit configuration files. How do we efficiently deal with replacing a part of a 4GB text file or even view one needs to be solved first.

Viewing

For viewing there is no description how a user clicks/triggers this modal to be shown. I assume that a double click of a file would show read only view of a text file?

As files are very generic, symlinks, binary files, I assume we need to restrict this only show plain text files and think about limits. Just streaming a 4GB text file obviously does not work.

So we have several options here:

• Cut off and only show x kB
• Stream the file as a viewport (basically keep only the shown part in memory). This might be challenging when one wants to scroll back up after scrolling down.

[garrett]

Yeah, you're totally right. Editing would only be for text files of reasonable size. We should probably have some kind of warning for larger text files and figure out something else for non-text files.

(These mockups were made as a response to a discussion about which syntax highlighting engine and other IDE related features we want. I said that we should keep it simple (like these mockups) and work on file management related tasks, not implementing a basic code editor. So these are incomplete, but do serve as a starting point.)

For viewing, it's more straightforward; we could show a short version, stream, or whatever. For editing, I really don't think we want to truncate the file or stream it. Anything that large is better suited for something that isn't Cockpit Files.

I guess we can force a viewing-only mode with a warning, and have a download button. But if we have a download button for that, then we probably should have a download button for all of these, making this more of a lightweight previewer with very light editing capabilities only some of the time. And if it's a previewer, then we probably want to show some stats on the file (file size, ownership, # of lines for text files... I guess?). And this means we need a revised design that takes all of this into account.

[mac2net]

I apologise if I missed this, will there be more GUI added to the list view as in the old Navigator?

[garrett]

Yes, that's what the details/grid toggle button is for. You can click it to switch the view and click the dropdown for sorting it.

(However, the current implementation, details aren't yet in details mode; it's still just the icons and labels still.)

[allisonkarlitskaya]

One piece of feedback I have about the overall design of the main page: the top bar seems too full. I feel like it would be more useful to have a top-level navigation-centric bar (bookmarks, breadcrumb, etc) and then a "view" area (filter, sort, etc.) on a separate line.

I feel like this could be helpful on mobile as well...

edit: Just found #474 thanks!

[garrett]

Right, I wanted to move the conversation over there as to not clutter this page, and then I can update this when we're all happy enough.

(The goal was to share the current state all in one place here.)