Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Special-case MOTD in showMessage procedures. #709

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

addap
Copy link

@addap addap commented Dec 31, 2024

Hello, for a MOTD it is natural to use ASCII art but since messages in the chat box are added using QT's HTML-like text fragments, multiple spaces are merged together and the default variable-width font destroys alignment.

default look: desired look:

broken

correct

Therefore, I propose that when showing a MOTD we escape spaces with &nbsp; and wrap everything in <code> tags to select a monospace font.

One problem is that MOTD is also used for showing warnings to the user, such as the "new-syncplay-available-motd-message" message. These will also be changed accordingly. If undesired, these warning should be sent in a separate field.

I have only tested this on openSUSE with python 3.11.11 and PySide6 6.8.0.2 so far. I assume that <code> tags work in every python QT library since they are supported by the rich text engine (https://doc.qt.io/qtforpython-5/overviews/richtext-html-subset.html#supported-html-subset). Is there a standard way to test for the different QT wrapper libraries that should be supported?

For a MOTD it is natural to use ASCII art but since messages in the chat
box are added using QT's HTML-like text fragments, multiple spaces are
merged together and the default variable-width font destroys alignment.

Therefore, when showing a MOTD we escape spaces with `&nbsp;` and wrap
everything in `<code>` tags to select a monospace font.

One problem is that MOTD is also used for showing warnings to the user,
such as the "new-syncplay-available-motd-message" message. These will
also be changed accordingly. If undesired, these warning should be sent
in a separate field.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant