Nice, we needed this!

But I don't think the echo mode indicator is that important that we should use up screen real estate on it. UI team, thoughts?

I think we need it because the user will want (or need) to know that suddenly what they type may not be what gets shown on the main console when they press enter. Remember for that (hopefully short) time it is up to the game server as to what (if anything) gets shown in response to what they sent - typically it will not show anything but it is at liberty to put up anything...

Now, if the user does not normally echo what they type to be sent to the screen, they will not be concerned - so the icon will stay as the grey one whichever end is doing the echoing.

It is also a tele-tell initially that I have correctly handled the ECHO option negotiation - I think I have got it right - but if that triangle stays showing past a password entry than it will give a warning that I have cocked something up - you know how, um, sensitive that part of the code base is! 😜

Good idea not to display and log the password. I think nobody will argue.

However not acceptable to have this indicated in such prominent position. The area next to the command line seems for very important information or toggles. Understandable to place this there during debugging but not for regular use. It also seems somewhat superfluous. Most users will understand automatically that passwords are not shown and may be confused by too much information indeed. What is more, remember us hiding the buttons to the right? This is what users wanted. Other users are modifying the application style as a whole. Some ask about moving the command line elsewhere. The trend is clear: Block as little predefined screen area as possible. Make the rest as configurable as possible.

Oh, and putting it next to where the user is typing feels sort of consistent to me (the reflected arrow symbol sort of says something about what is happening - though I would like it to be a tiny bit bigger - to take up a larger part of the rectangular 96x96 pixmap - or perhaps we need to get our new icon person on the case 😉 for a better/larger rendition.)

The above was written before I saw @Kebap 's response.

That does, disappoint me a little 😢 - I worked hard to get a control and an indicator combined and working there and I was pleased with it - but I guess not everyone has the wide screen(s) that I use and wants an indicator.

So I am going to need to rip that part out and put the control back on the preferences, oh well, back to the code-face. ⚒️

Oh, hang-on - how about if it was included in the command-line, like the search options are in the search term entry box in the Editor? No, that is not going to be any more pleasing to the UI minimalists...

Right - the UI aspect is gone - you will just have to watch the debug output to see the Server negotiating the ECHO option for him being turned on and off - and spot text not showing up when it did before!

Doing this has made the overall changeset much smaller and simpler! 😉

Thanks for the quick update! Hooray for more simple changesets! I am very sorry if I was causing any disappointment. Indeed, I know even a few people who do not play Mudlet in fullscreen, just windowed mode, but also with multi-view enabled. It makes sense to keep buttons low in number for that use case. If there really comes a desire to know more, we can surely add those buttons, because that functionality of both displaying information as well as being toggleable is quite nice. Then again, it could also be realised as sort of an overlay, maybe even in lua by grabbing events. That is to not use up real screen estate. Just thinking out loud here. Maybe that is the lesson learned here: Let's maybe ponder and settle bigger intended changes before actually putting in the work of implementing them, so no work is wasted that way.

I guess it doesn't need review by @Mudlet/ui-review now! 😆

Where can this be tested? Did not seem to work in Achaea, password is shown and debug output is:

Enabling Server ECHOing of our output - perhaps he want us to type a password?
cTelnet::processTelnetCommand() TN_WONT command= 1
cTelnet::processTelnetCommand() we dont accept his option because we didnt want it to be enabled
Server is stopping the ECHOing our output - so back to normal after, perhaps, sending a password...

That is odd - it worked for me on WoTMUD (back when the UI element was present - I got the password wrong and until I got it right on the third attempt the icon was the triangle and then when back to the blue echo.) Analysing the messages:

1. Enabling Server ECHOing of our output - perhaps he want us to type a password?
2. cTelnet::processTelnetCommand() TN_WONT command= 1
3. cTelnet::processTelnetCommand() we dont accept his option because we didnt want it to be enabled
4. Server is stopping the ECHOing our output - so back to normal after, perhaps, sending a password...

1 is our response to his IAC WILL ECHO - where we send IAC DO ECHO and switch off our echoing of what we type
2 should be his telling us that he is stopping echoing which would be AFTER a password entry
3 looks odd - maybe our debug message is too simplistic
4 is what I'd expect after 2.

Are you saying that the password was shown on the main display (the TConsole) or the command line - this does not hide it from the latter where you type it in - only the former... 😕

Yes, our debug messages are confusing here because that message 3 is used any time that he sends a WONT and the corresponding bit in the (bool) cTelnet::triedToEnable[256] array is not set - and we never set any bits in that...

If you compare the code with what I might cheekily call upstream at https://github.com/KDE/kmuddy/blob/master/kmuddy/ctelnet.cpp you can see that KMuddy does set/clear them...! 😮

It is shown in the display

Maybe it's just Achaea that is bad - StickMUD seems to be OK. However, if I reconnect in the middle of this echo off, the echoes don't get turned back on.

I have replaced the (possibly misleading) messages and replaced them, using a new helper to identify all the protocol numbers I could determine so that instead there is a uniform Server sends telnet IAC (WILL|WONT|DO|DONT) (option name).

Having removed my username and password from my Achaea test account I cleared my Qt Creator application output and annotated the output at each stage:

Started a reconnect:

Server sends telnet IAC WILL EOR (25)
EOR enabled
Server sends telnet IAC WILL ATCP (200)
Server sends telnet IAC WILL GMCP (201)
GMCP enabled
Server sends telnet IAC WILL MCCP2 (86)
MCCP v2 negotiated!
Server sends telnet IAC DO TTYPE (24)
server sent wants us to enable telnet option  24 (TN_DO +  24 )
OK we are willing to enable telnet option TERMINAL_TYPE
checking mccp start seq...
MCCP version 2 starting sequence
-1 , -6 , 86 , -1 , -16

Server asks for our user name:

Sent username:

Server asks for our password:

Password sent:

Server sends telnet IAC WILL ECHO (1)
Enabling Server ECHOing of our output - perhaps he want us to type a password?
Server sends telnet IAC WONT ECHO (1)
Server is stopping the ECHOing our output - so back to normal after, perhaps, sending a password...
MMP map registered at "http://www.achaea.com/maps/map.xml"
QNetworkReplyHttpImplPrivate::_q_startOperation was called more than once QUrl("http://www.achaea.com/maps/MD5SUM")

Login happens...!

I repeated the test with break points on the point where the WILL and WONT ECHOs are processed, neither of them were hit until AFTER I sent the password.

Conclusion: Acheae is broken in that it is not sending IAC WILL ECHO before it asks for the password...

OK, sounds good.

Good to merge after the bugfix.

Um, what do you mean by that - I have pushed a further commit which removes some potentially misleading messages and ensured that all the options being negotiated are identified and each DO/DONT/WILL/WONT is displayed in the debug output (if DEBUG_TELNET is defined) - I have moved the code that was conditional on the DEBUG symbol being defined - which it was. There was another debug output that reported the size of some commands received but I thought it was spammy so now is only shown if DEBUG_TELNET is defined to be something greater than 1. As things stand it is currently defined to be 1...

If you reconnect while server has turned off echoes, state is not reset and echoes are off.

Merging so we can get a build out for testers - the small state reset bugfix can be in a follow-up PR.

If you reconnect while server has turned off echoes, state is not reset and echoes are off.

💡 Raised as an issue in #2249

Okay, let me see if I can quickly find a suitable place to reset it on disconnect/reconnect...