element-hq / element-desktop

A glossy Matrix collaboration client for desktop.
https://element.io
GNU Affero General Public License v3.0
1.15k stars 262 forks source link

Enhancing work with attachments #901

Open hyperion-cs opened 2 years ago

hyperion-cs commented 2 years ago

Your use case

Hello. The desktop version of Element has a few problems with attachments that make me very sad.

  1. When we try to download an attachment from a chat room, it is downloaded first, and only then is the choice of the directory to save the file requested. This looks ugly when the files are large, because you have to wait a long time (nothing happens on the client screen while waiting). Solution: First select a storage location and only then download the attachment;

  2. When downloading an attachment from chat, a temporary file is used, which is saved to the system hard drive. This behavior is incorrect because there may not be enough space on the system drive for an attachment of large size. Moreover, why do we need it at all? It looks like an overhead. Solution: We should at least first ask the user for storage space for the attachment (which will probably not be on the system disk);

  3. There is no progress bar to track the process of downloading an attachment. Solution: add a progress bar to improve user experience;

  4. There is no option to define a default location for downloading attachments in the settings, so that we don't have to choose it every time. Solution: add this feature (optional);

  5. The same attachment is downloaded every time, this is extremely inconvenient and not optimal (imagine that the attachment weighs 100+ mb). Solution: We should download the attachment once and remember it. Given that attachments can be saved in different places, we should consider logging where and which attachments are saved;

  6. It is possible to upload an attachment via drag-and-drop to chat. But there is no such option to copy via drag-and-drop an already downloaded attachment from chat (in fact, the copying will happen locally). This is a very useful feature when you need to quickly copy an attachment to another location. Note that this task depends on (5). Solution: add this feature;

  7. When we right-click on an attachment there is no way to open the directory in which the attachment is saved. Solution: add this feature. Note that this task depends on (5).

Additional context

I expect that many users of the wonderful Element will be so happy if these features are implemented, especially (5).

t3chguy commented 2 years ago

When we try to download an attachment from a chat room, it is downloaded first, and only then is the choice of the directory to save the file requested

This only applies to encrypted rooms where the file must be downloaded & decrypted before we can ask the web browser to save it (which prompts you to pick a location)

Solution: First select a storage location and only then download the attachment;

This is not possible in a web browser consistently, Firefox lacks support and Safari has only partial support: https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API

When downloading an attachment from chat, a temporary file is used, which is saved to the system hard drive.

This is an implementation detail of the browser being used, for Element Desktop this is Chromium wrapped in Electron. This is likely not changeable and may be related to Electron's sandboxing properties.

There is no progress bar to track the process of downloading an attachment.

This is tracked in https://github.com/vector-im/element-web/issues/18259

There is no option to define a default location for downloading attachments in the settings, so that we don't have to choose it every time.

This isn't possible for web browsers due to lack of an API - in Electron it is possible through a lot of work for relatedly little gain. Right now Electron handles downloads entirely itself, we'd need to do things manually to allow for this.

Solution: We should download the attachment once and remember it. Given that attachments can be saved in different places, we should consider logging where and which attachments are saved;

This is not possible in Web Browsers, for desktop this is brittle, given you can move & rename files, or may wish to download it again. Does any other chat app do this?

It is possible to to upload an attachment via drag-and-drop to chat. But there is no such option to copy via drag-and-drop an already downloaded attachment from chat (in fact, the copying will happen locally). This is a very useful feature when you need to quickly copy an attachment to another location. Note that this task depends on (5). Solution: add this feature;

I am unclear on what feature you are describing here, maybe a drawing of where you are dragging from and to would help.

When we right-click on an attachment there is no way to open the directory in which the attachment is saved. Solution: add this feature. Note that this task depends on (5).

It is unclear where you are expecting to right click for this to work. Again this would not be possible in web browsers due to lack of access to ability to open random directories.

hyperion-cs commented 2 years ago

@t3chguy, thank you for your quick response. Thus, most of the described features are not possible due to technical limitations.

This is not possible in Web Browsers, for desktop this is brittle, given you can move & rename files, or may wish to download it again. Does any other chat app do this?

For example, Telegram does that. Moreover, it also has most of the features I described.

I am unclear on what feature you are describing here, maybe a drawing of where you are dragging from and to would help.

In any case, it seems to require a task (5) which cannot be done. However, I recorded a small .gif to demonstrate this: 1

It is unclear where you are expecting to right click for this to work. Again this would not be possible in web browsers due to lack of access to ability to open random directories.

Again, I can show this on the example of Telegram: 2

// Considering the impossibility of implementing most of the features described here due to Element's architectural limitations, I propose to close this issue. What do you think?

t3chguy commented 2 years ago

// Considering the impossibility of implementing most of the features described here due to Element's architectural limitations, I propose to close this issue. What do you think?

I think most are possible, though limited to Element Desktop, and will be a decent amount of work so likely only viable through community contributed work.