Improve image support

[dotWAVE]

The behavior I currently experience with posting images:

• Images dragged onto the text field only paste a file path, (ie: file:///home/User/Pictures/IMAG0013.jpg) Images must be sent by "Channel Right Click & Send Message".
• Images added to a message are converted into base64 and are easily rejected by text message length restrictions.
• With a couple extra steps, the same image can be uploaded to a webserver, served over http, and imbedded in a message with an tag. This bypasses the message length restriction by not converting to base64.
• Additionally, any image sent will be displayed at 100% resolution. This makes many images un-viewable at smaller window sizes. But can be fixed by specifying height and width in the image tag.

The ideal scenario:

• It should be possible to drag and drop images into the mumble window or text field, and send them to the current channel.
• A method of sending local images that is not restricted by message length, but instead by image size. (I don't know what the optimal way of doing this within the scope of the project is, adding webserver functionality to murmur is likely outside the scope of the project.)
• High resolution images should scale down to the dimensions of the window.(This should be possible with CSS? but I am not familiar with it)

I am willing to pay a bounty for these.

[Kissaki]

The server has separate limits for maximum text message length and maximum image message length.

Drag and drop has the issue of where it should be sent; the current channel, the selected channel, or one the user wants to select?
The chat input sends to the selected channel, so it can arguably be expected to be sent to the selected channel if dropped into the chat input textbox.

I believe we recently removed support for link-external-embedding images via href in 1.3.0 [IIRC], as that allows users to send prepared links and the users IP address will be leaked to the web server hosting the image. A potential privacy and security issue.
This was never an exposed functionality - users had to explicitly edit the HTML source of the message to be sent, which made it possible to decide to just remove this hidden feature for its risk.
(An alternative approach would be the server fetching web resources to then embed them within a message. The users privacy would not be an issue in that case.)

Sending images should offer to resize images to more manageable sizes. When dropping a 5MB UHD image mumble should offer to send a resized version.

[dotWAVE]

Perhaps the image when shrunk down to a more manageable size could link back to a full size picture originally fetched?

[azlux]

Maybe #3597 is another way to handle the image.

[Gert-dev]

For completeness' sake, the situation seems to have slightly changed on latest master:

• Dropping an image into the chat text field seems to automatically insert it (at least here on Linux).
• Using Ctrl-C to copy an image (from e.g. Firefox) and using Ctrl-V in the chat text field seems to automatically insert it.
• Mumble seems to size large (as in pixel count) images down to a manageable size. This is fine, but there is no way to enlarge the image anymore. This causes some images to get an unfavorable size and make the details on them hard to see.
  • Saving the image also saves the resized version, not the original version.
  • Perhaps an overlay to view the full version could work, which is the approach taken by e.g. Dino.

Another idea I'm throwing in here in case it helps: if loading external images (by URL) is allowed again, protecting clients could happen by making all images (both external and internal) not automatically load until a client consents to it through an overlay button, which is what mail clients do.

• Mumble could show the domain of the image or optionally allow adding certain domains to a trust list, to avoid it becoming cumbersome. For internal images, users could perhaps be marked as trusted instead.
• Admittedly, clients could still get compromised by malicious images this way, but the explicit step lowers the chances of that happening (it's not much worse than them opening a link through their browser).
• It would also fix the problem where you can force other clients to download large images without recourse.

The ability to paste images could also use some additional exposure in the UI. I've been using Mumble for years and only just figured out that it exists 😄.

[Krzmbrzl]

#4632 is currently working on improving the down-scaling behavior of images. They still are scaled down if they exceed the maximum image size allowed by the server's settings but this is no checked explicitly and the images are not automatically resized to a fixed size.

The ability to paste images could also use some additional exposure in the UI. I've been using Mumble for years and only just figured out that it exists.

Any suggestions for this? :)

[Gert-dev]

#4632 is currently working on improving the down-scaling behavior of images. ...

Great to hear!

Any suggestions for this? :)

Well, I'm no designer or UX expert, but maybe a good first start would be to take a page (steal 😄) from Dino?

This is the chat input field Dino shows:

• The clippy icon allows inserting attachments. In the case of Mumble the file picker would probably be limited to just images - unless Mumble can also send arbitrary files and I never figured it out 😄.
• The input field allows inputting text. Mumble already has this.
• The smiley icon allows inserting arbitrary emoji's through GTK's emoji picker. Mumble already seems to show emoji's if you insert them directly, so it could be another neat addition, though Qt may not expose a picker for this.
• The lock icon indicates encryption status and allows configuring it. Doesn't seem necessary for Mumble since everything is already encrypted by default, I believe. (An idea would be to display a button with a popover here allowing to select the channel to send to, instead of doing it from the user list, but that may be for the future 😄).

Icons could be shown at the end rather than the start, if preferred.

Another idea may be to change Type message to channel 'X' here to something like Type your message or paste your image to channel 'X' here. It's small, but perhaps enough to already be noticed by more alert users :-).

[TerryGeng]

At the end of the day, I think the root of the problem is Mumble's text message function is too simple. We don't keep the history of channel messages, transmit everything as HTML (even for images we just encode it with base64...), and the widget used to render messages is just some basic HTML widget from Qt...

Basically, if we don't support other methods and enhance the protocols, there's no simple way of transferring images and files. If we don't have a backend that keeps track of the message history, there's no way and no point to cache/proxy images and to share files.

I don't know if it is me only or not that feel the chat box is so ugly... and the way to send direct messages to other users is so cumbersome (right-click and Send Messages) and the message compose box is strange as well. Can we have a more consistent method, like what Element Web App would do, display the name and avatar of the user in the input box when sending direct messages?

It is totally possible to customize the widget we are using further and make a beautiful plus modern UI with Qt. But I wonder if we customize more, in the end, QSS would no longer do the job and we have to hard-code color and other UI properties in the code. Maybe QProperty can do the job but I'm not sure.

To summarize, in order to have a better text chat experience, we need to consider:

• Support message history and assets (images, files, etc) management.
• Enhance the protocol to create special messages to transfer images and files, chat history, etc.
• Customized Qt widget to make a modern-looking UI.

These problems are entangled. There's no way to solve one of them without solving all of them.

[Krzmbrzl]

I agree that the chat functionality could use a (major) overhaul. For that it will probably turn out to be useful to go beyond pure HTML messages and on the UI side, we definitely want to go beyond a single HTML viewer. The least thing that is required is something that has already been started to be implemented in #3465

For persistent chat messages (aka message history) see also #2560