Integrate copy-progress floating window inside Files main window

[dvilelaf]

In comparison with the streamlined UX all over elementary OS apps, it feels weird to have a floating window separated from Files main window while copying some files (specilly for long copies, where you have this small window bothering or covering part of other apps a for long time). Also, this affects the blue-dot indicator in Plank.

Wouldn't it make more sense to have an integrated progressing-bar in the left panel from Files' main window? That way you can track the copy progress from Files itself, while performing other tasks without the need of window switching.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[cassidyjames]

I think one reason it's a separate window is so that it's still visible while the main Files window is closed; we don't want to quit operations if the main window is closed, but we want the process to be visible to the user.

[dvilelaf]

I understand. Could the copy process be run in a separate thread, and spawn the window only if Files is closed?

[peteruithoven]

What about showing the progress in an notification window, maybe except for when Files has focus?

[cassidyjames]

Notifications are not for ongoing progress, that's what dock progress bars generally are for. I think our normal expectation here is that we'd show the progress in-window in Files, closing the window would continue the operation in the background, and we'd throw a notification upon completion of a long operation if the window isn't open and focused.

[lewisgoddard]

Duplicate of #167

[danirabbit]

I think #167 is something different. The solution to this is probably more about putting progress in a popover. #167 is something I think we'd do in addition

[jeremypw]

Needs a design spec to work towards.

[elsiehupp]

I would have opened a new issue for this if it hadn’t existed already, but the way I described it in my notes was “operations progress bars are a cursed windowlet”. Ironically this problem also exists in the macOS Finder, where it much predates the problem in Pantheon Files. What I mean by “a cursed windowlet” is that the window… thing that contains progress bars doesn’t behave like a normal GTK window. For example, it can’t be maximized. In Nautilus the progress bars are a cursed popover (like Firefox or Safari downloads), which is neither better nor worse but still not ideal.

One “quick and dirty” design solution for this problem could be having the progress-bar window literally just be a regular Files window, with the progress bars in place of the filesystem viewport. This window would then be able to be a tab in another Files window, or it could be open on its own. Perhaps even better would be for the progress-bar window to show the sidebar when it’s a tab in a Files window with other tabs but appear more or less like its current iteration (just with “maximize” and everything) if you “tear” it off, or if there are no other tabs open. (What to do with the breadcrumbs in the progress-bar tab is an open question.)

I would shy away from any design solution where the progress bars are integrated into a Files window in such a way that requires there to be a filesystem viewport open in order to see the progress bars, like Nautilus does.

A more integrated solution for this that IMHO would be more ideal is if the Wingpanel included a section for progress indicators analogous to but separate from the existing Notifications interface. This progress interface could provide an API so that other applications could display background operations in it without otherwise showing an application GUI. Like the bell icon with the red dot, any active background operation could be accessed from, e.g., a Wingpanel icon of a GTK spinner animation to indicate that something is going on.

Examples I can think of that could integrate into a unified progress GUI include:

• Files operations (e.g. copy, move, empty trash, etc.)
• Web downloads (i.e. from a web browser, but also potentially from a GUI download service on its own)
• Déjà Dup backups
• Cloud sync operations (Nextcloud, cloud drive, PIM, etc.)
• AppCenter downloads and updates

In each of these examples, the application in question would have to be updated to support an external progress GUI, and it would probably be best to design such a system as, like, an XDG standard of some sort or another, in order to encourage its adoption.

Another advantage with the approach of having a system progress-bar interface is that it could help reduce the need for third-party tray icons and tray menus. Basically it would be nice for things like Nextcloud and Déjà Dup not to require full application interfaces of their own, instead splitting their functions between Switchboard panels, standardized Wingpanel progress indicators, Wingpanel notifications, and contextual plugins for things like Files (i.e. a context-menu item for sharing a file on a cloud service).

Also in general file operations initiated by Files should be their own separate processes so that they don’t lock up the entire Files GUI, though there are probably other issues addressing this already.

But I digress.

[jeremypw]

Thanks for taking the time to think about this! Off-loading file operations to a separate process (e.g. pantheon-files-daemon) is something I have thought of but no-one so far has attempted it. We are in the process of converting the remaining file operation code that is in C to Vala so when that is done moving it to the daemon may be easier. A system level progress indicator service seems like a good idea to me (may need a portal of some kind for flatpak apps). That needs raising in the WingPanel project I guess.

[jeremypw]

Files operations are carried out asynchronously in a separate thread so should not completely lock up the interface, although it may be slowed down if the cpu core gets overloaded.