Sharing lyrics with chords (multiline monospaced messages) in the Chat

[passing]

Problem

The chat only allows for single text lines to be sent. Being able to paste multi-line text would allow for sharing lyrics with chords that you have stored on your computer. You could make them directly available to everybody in the current session without having to upload them somewhere.

Describe the solution you'd like

The chat window could have a button somewhere that switches to 'multi-line' mode. In that mode, the input box would need to turn into a multi-line box. Text written in that box should have monospaced font and the message should also be displayed that way after it got sent

Technically, I could imaging that any message with newlines (\n) could just be treated that way on the clients receiving it.

Describe alternatives you've considered

The multi-line mode could also open another window in case the single-line input box cannot be replaced with a multi-line input.

Additional context

Sharing multi-line / monospaced content was possible before #939, which lets the server escape html in chat messages.
But making use of that also required some way of creating html with specific tags as mentioned here: #890 (comment)

[gilgongo]

Great idea!

I think it may need some discussion to firm up I think though before we add it to the backlog, so I'm migrating this to a Discussion if that's OK.

[pcar75]

I really support this proposition and #1524.

Case : When joining a public server, it is usually a good idea to exchange in a chat window a list of known songs to all participants. However a list will appear as a 1 continuous line (with a limit on nb. of characters) , making it difficult for participants to read.

Case : a mono-spaced font would be great to share text bloc diagram of chords that are easily readable by other participants. To my knowledge 'Courrier new' is mono-spaced and available on Windows and Mac default fonts. Unsure about Linux ...

At the very least 3.7.x + (I am still on 3.6.2) should support basic html tags.
HTML Tag to allow in Chat window in order of usefullness :
br = Line break / delimiter (equiv CR or LF combination)
b = Text in bold
h? = Heading style where ? is 1 to 6
p = Paragraph delimiter
q = Short quote (but does not work either in 3.6.2 under Windows10 !? )

Refs: #1524, #1021, #939, #380, #890

Thank you developers , for re-considering this and the initial proposition.

[hoffie]

I have raised a proof of concept PR (#1571). Feel free to try it out. This should cover what you (@pcar75) proposed, except for <h?> and <q>. Can you explain the use cases for them? I'm a bit worrified for the potential of abusive or annoying messages by using huge headers / font sizes.

[hoffie]

To summarize, there seem to be multiple approaches:

1. Special-case new lines to switch into a monospace text mode as @passing proposed.
2. Allow safe HTML tags again (as @pcar75) mentioned. See Server: Permit simple HTML in chat messages again #1571 for a proof of concept. This seems to be technically simple, unless someone finds relevant flaws.
3. Allow Markdown. While Qt does provide Markdown support on the rendering side, it does not provide generic parsing support, as far as I can see. As such, allowing Markdown would either require us to come up with basic parsing ourselves (sounds cumbersome and error-prone) or introduce an additional dependency on a third-party library to do that for us. While I do like Markdown, I don't think the technical effort is worth it.

1. requires UI support. 2) and 3) might profit from optional UI support, but would work solely text-based as well.

@passing would 2) also work for your use case?

[npostavs]

3. While Qt does provide Markdown support on the rendering side, it does not provide generic parsing support, as far as I can see

Not sure what you mean by "parsing support" exactly. Calling setMarkdown seems to parse the input and render as Markdown fine, but requires Qt 5.14 (also, there seems to be no append equivalent for Markdown, which means that the initial server message loses any formatting that can't be expressed in Markdown. Is that what you were getting at with "parsing support"?).

--- i/src/chatdlg.cpp
+++ w/src/chatdlg.cpp
@@ -129,7 +129,7 @@ void CChatDlg::AddChatText ( QString strChatText )
     }
 
     // add new text in chat window
-    txvChatWindow->append ( strChatText );
+    txvChatWindow->setMarkdown ( txvChatWindow->toMarkdown() + strChatText );
 }

[hoffie]

Not sure what you mean by "parsing support" exactly.

Hrm, I was assuming that this has to be done on the server side. This would require access to the Markdown parsing without creating GUI widgets.

Thinking about it, I'm not fully sure if my assumption is useful.

We could do the rendering on the client side. However, this provides less control. For example, this would also enable Markdown for user names, which I don't think we should do. Avoiding this would require splitting that into different protocol fields or parsing HTML again...

which means that the initial server message loses any formatting

I think full HTML in server messages is something which more people would rely on. I guess with some hacking one could find workarounds (e.g. letting an invisible widget parse the markdown, export the html and append that to the real chat window, but ...).

[passing]

1. Special-case new lines to switch into a monospace text mode as @passing proposed.
2. Allow safe HTML tags again
3. Allow Markdown.

My idea was actually to have (just) a user-friendly way to send multi-line, monspaced text and for that a WYSIWYG input field would be best to not require any extra knowledge about html nor markdown.
More options like bold text, headers, would be out of scope for me - but you could of course want to have that as well..

option 2 would require that you type html into the input field (or use a converter like https://passing.github.io/jamulus-converter/ - but that requires that you copy and paste text between multiple systems)

option 3 would be easier, but you cannot enter multi-line blocks in a single input line in markdown afaik (which is possible in html)
then still you need to know that you have to use 3 backticks before and after your block.
That's why, I'd prefer to just have the option to switch to 'multiline mode' in the Client UI, and then see and send monospaced text

[hoffie]

Ok, thanks for your input! I'd like to wait for some others to comment on whether option 1 would work for them as well.

[pcar75]

@hoffie - The tags h1-6 and q :
I understand your hesitation about the size of headers ... and q was for having an alternative to bold which I thought might appear as Italic on some OS (not Windows, where it simply creates double quotes , quotes or double carets in french ).

But the ideal situation is really a monospaced font and multi-line (end-of-line respecting) chat facility. I see no need to support (also) a proportional font if we can have a monospaced one.
Without the bold option (i.e. no tags ), I suppose one could type the important words in uppercase to focus attention ... :-|

[hoffie]

So, in summary the most benefit seems to be achieved by adding support for multi-line monospaced text. I have therefore closed the generic HTML enabling PR for now.

(I'm not currently working on this, so if someone wants to take this up, feel free to and mention it here)

[passing]

I would like to work on this in the following way:

• The chat window's menu gets a new action that toggles the 'multi line input' mode. In that mode, the input box is replaced with a multi-line box. Text written in that box has monospaced font.
• Messages sent from that box will be formatted by the server (using <pre> and <br> html tags), so clients receiving the message will display it in the same way it was entered.

Only downside is that it would only work on a server running the version including the feature. When being connected to an older server, the message written in the multiline input field would be merged into a single line. Are there any thoughts / suggestions to that?

[hoffie]

Sorry for the late reply.

I'd generally like this simple approach. Thanks for moving this forward!

• UI-wise, @dcorson-ticino-com might want to have a say as well?
• Implementation-wise, do I understand correctly that this would solely be logic which special-cases \n characters?

[passing]

@hoffie got a working implementation already #1859

do I understand correctly that this would solely be logic which special-cases \n characters?

right, if there's \n characters in a message the server adds <pre> tags around the entire message:

jamulus/src/server.cpp

Lines 1417 to 1421 in 5cbeebc

	if ( strChatText.contains ( "\n" ) )
	{
	// add 'preformatted' tags around multiline strings
	strActualMessageText += "<pre>" + strChatText.toHtmlEscaped() + "</pre>";
	}

[dcorson-ticino-com]

Sounds good to me.
My only question is why do the formatting with pre etc. on the server.
If that is done on the client before sending to the server it should work also using old servers.
Or am I missing something?

[hoffie]

If that is done on the client before sending to the server it should work also using old servers.

Current server versions reject/escape client-provided HTML.

[passing]

If that is done on the client before sending to the server it should work also using old servers.

that's not possible as the server (since version 3.7.0) escapes all html it gets from clients: 6ffd1fd

[pcar75]

Thanks for your interest.
My developers days are a long way ago, but isn't div overly 'opened' ? After all the HTML and CSS features were removed in earlier version for security reason . Just a thought ...

.

[passing]

@pcar75 thanks for the feedback. I just mixed up tags: Of course, I need to use <pre> instead of <div> to get a monospaced font. (I have updated my previous comment accordingly)

[passing]

I had recently implemented what I had described in #1021 (comment) and created a PR (#1859), but that turned out to require more changes.

The following things (at least) still need to be clarified and agreed before going on:

• What should happen when a user is connected to a server that does not support multiline messages, a few things I can think of:
  • Don't allow to activate the multiline mode
  • Allow for activating the multiline mode, but deactivate the input field
  • Allow for activating the multiline mode, but deactivate the send button
  • ...
• What should happen when a user has the multiline mode active (on a server that supports it) and now disconnects
• What should happen when a user has the multiline mode active (on a server that supports it) and now switches to a server that doesn't support it
• What should happen with text in the multiline input field that was entered while being connected to a server that supports multiline input
• Are changes needed to the send button, that can be used right now without being connected to a server

I don't have time right now to continue on this and won't mind if someone wants to take this over.

[hoffie]

Thanks for working on this and providing this summary, @passing.

Thinking some more about it (even after #1859 (comment) and the comments after), I come to the following conclusion:

Usability-wise, the best option would be signalling that there is something like a multiline mode (i.e. never hide the feature completely), but it is not available due to lack of support from the currently connected server. The explanation could be in the menu option?
Code-wise, I'd like to avoid addition of new protocol messages just for this feature, but I guess a version-based check as @pljones suggested would work fine?

So, specifically replying to your questions:

• What should happen when a user is connected to a server that does not support multiline messages, a few things I can think of:

  • Don't allow to activate the multiline mode
  • Allow for activating the multiline mode, but deactivate the input field
  • Allow for activating the multiline mode, but deactivate the send button
  • ...

I'd vote for preventing enabling of the multine mode (first option).

• What should happen when a user has the multiline mode active (on a server that supports it) and now disconnects

I'd say: keep it as-is.

• What should happen when a user has the multiline mode active (on a server that supports it) and now switches to a server that doesn't support it

I'd say: Deactivate it (maybe runtime-only and not in the stored settings?).

• What should happen with text in the multiline input field that was entered while being connected to a server that supports multiline input

Sounds edge-casey, but still worth thinking about. Dropping user input would be annoying (even if this case should happen seldomly), so maybe copying it over to the single-line input would be the way to go?

• Are changes needed to the send button, that can be used right now without being connected to a server

I think that's separate to this Issue, isn't it?
I'd say the send button should be disabled when not connected to a server (independent of multiline mode).

[jp8]

I have read through the discussion and pull request #1859 and perhaps I am not understanding it properly.

I believe the functionality can be achieved with no modification to the server, and no extra config on the client side. Did I miss something ?

If the user types, or pastes a single line, no change from current client behaviour

If the user pastes a multi-line, then

• extend the chat entry line to a multi-line
• wait for the user to press enter or click send
• replace all newline characters with the string "\n" and send to the server
• put the chat entry line back to a single line

If the client receives a chat message containing "\n"

• replace it with newline character
• switch typeface to monospaced
• display it
• switch typeface back to normal

Old clients will see the chat message as a single line with the "\n" in it - but we don't care too much about older clients as the typeface wouldn't be monospaced and there's no way around that.

[pcar75]

My interrogation was : isn'it less work to support a new line string that was already good for older version instead of inventing (or borrowing) a new one (i.e. <br> instead of \n ?
From my client 3.8.0, I've tried multi-lines-br-terminated with server versions
3.5.x = Ok
3.6.0 = Ok
3.6.2 = Ok
3.7.0 = Not
3.8.0 = Not
I've corrected my previous comment
Of course, you maintainers & developers know better !

[pcar75]

As an aside note, I would suggest that some documentation indicate the number of characters that one chat send can support . I remember trying to share a (multi-line) setlist and had to break it in section because it would not fit ; I believe the limit is/was around 1200 characters !?

[pljones]

Based on your findings, I guess it was 3.7.0 that added the safety net filtering of incoming chat to strip HTML and only the server can add HTML.

The limit for any UDP packet is about 1500 bytes (not characters). The protocol takes up some of that. I'm not sure if the chat text line is allowed to fill up the entirity of the remaining space.

[jp8]

A similar algorithm to what I proposed, again only requiring client-side modifications, could split each line into a separate chat message and queue them for sending. That would address the size limit, and also it would make the line breaks appear properly on receiving clients below v3.8.1. There is still no way to make 3.7.0 and 3.8.0 display in monospace though.

[jp8]

isn'it less work to support a new line string that was already good for older version instead of inventing (or borrowing) a new one

Maybe, but maybe not.

1. The functionality was removed due to a security concern. There is an argument that selectively re-introducing partial functionality might also introduce security problems we didn't yet think of. In that case it might be better to leave the current block in place, and implement a different escape for specifically the functionality we want to achieve.

2. There is a nice clean implementation in multiline/monospaced chat messages #1859 but then we start to think about additional user interface modifications that need to go with it because it only works with certain combinations of client and server versions.

I don't think it is necessarily simpler to use functionality that used to work in older versions. But if it doesn't add user interface complexity and it meets the security requirements, then yes maybe it is better.