TASClient API bug and channel headers

[AF]

We need a proper solution for this, or at least an agreement betwene channel operators on a fix.

Currently the bug in the delphi UI word wrapping is being exploited to make multiline channel topics for word art, this is a problem as it means all the other programs ahve to recreate the buggy delphi API or suffer the borked topics.

We have 2 possible solutions:

• A protocol based solution
• Channel topics using a delimeter character to signify a line break, allowing longer channel topics

[Tobi]

What is the bug in the delphi UI wordwrapping?

[BrainDamage]

the topic in main (and in other channels too) is using spaces until the reach word wrap end to send text in a new line without having to interrupt the topic with an \n character to make ascii art or pseudo-carriage returns

the result is that any lobby/lobby user wich doesn't uses the same font, size and chat space as tasclient's default will have main's topic ascii art broken resulting in a text mess

i think that AF suggested to add a character to be used to send newlines in topics without using the hackish solution of the spaces/wordwrap

2 channels with ascii art examples

#main

#italiani

[Tobi]

Yeah I understand what AF wants, I just don't really see how the delphi API is broken. To me it seems correct behaviour that it pulls all spaces over to the end of the line, whether they fit in the window or not, and starts with the first word on the next line.

Maybe we should use the literal \n to encode newlines? (for consistency with programming languages)

Or maybe the literal <br/>, for consistency with html.

It would save a little bandwidth anyway if huge amounts of spaces can be replaced by a few characters.

[BrainDamage]

i never said it's a bug, it's actually the correct behaviour, i'd rather define it a lack in in the protocol

the </br> char could do

[trepan]

FWIW, I don't see any real need for multi-line messages.
I'd rather forbid them, and have the message parser limit
repeated white space.

[AF]

I do nto believe it is the correct behaviour since I am unaware of any other windowing toolkit that uses this behaviour by default.

Every program I have ever used before tasclient that had a form of word wrapping did not have this behaviour.

And aside from ti beign wasteful, its falls apart after you reacha certain screen resolution anyway as you need more spaces than you can fit to get a new line.

[Betalord]

The behaviour is all right and other windows apps use it too, but in the context of channel topic it's of course not ok. Best solution I guess would be either "<br>" (rather than <br /> since it is simpler and this is not html anyway) or not allowing line breaks at all. The \n thing won't work as that is a message delimiter.

I would guess most people would want line breaks, right? (in which case <br> would be best?)

[Tobi]

I didn't mean \n as in ascii 13 but I ment \n as in a backslash and a n.

But this post proves <br> or <br/> is better

[Betalord]

Or perhaps even better would be TAB character to delimit lines. This character is already used in the protocol for separating "sentences". The problem is that <br> can be interpreted as a completely valid text, while TABs can always be replaced by spaces.