Re: tkui users please comments

Just for some reference, I wrote that code (I'm pretty sure I wrote it). 
Anyhow, what's going on is that muds traditionally let the client handle 
echoing the characters they're typing rather than the mud server handling 
the characters the user is typing.  This goes along with line mode and sga 
and there are a couple of other telnet options that are involved, too. 
So the client tends to handle "editing" of the command and then when the 
user presses the enter key, the whole thing gets sent off to the mud.

When the mud prompts the user for a password, it informs the mud client 
that the mud server will handle echoing of characters.  When the user 
types in characters of his/her password, the mud client doesn't echo them 
to the screen and the mud server doesn't either.

With the tkui and the textui readline interface and the curses ui, the mud 
client has a more sophisticated ability to handle user command editing. 
When the mud server tells us that it's going to handle echo, we take this 
to mean that the mud server has prompted the user for a password and we 
deal with that accordingly.

Hope that helps.  It's a little incoherent, but that's the gist of what's 
going on.  While you may not care if people over your shoulder can see the 
password on your screen, but I would posit that a larger percentage of 
people do care than don't care, so at a minimum, we should keep the 
functionality.

On a side note, I think there are some edge cases in our telnet 
negotiation handling because there are a few muds that people have brought 
up which don't seem to switch into and out of the server handling echo. 
I never spent the time to figure out what the issue was, though.  I did 
add some code to allow the user to switch on and switch off mudecho to get 
around this problem.

Hope that helps--

/will


On Sun, 1 Jan 2006, Eugene wrote:

> On Sun, 01 Jan 2006 04:53:36 -0500 Eliezer Flores <[email protected]> 
> wrote:
>
>> Well I refactored tkui.py a bit so that it's easier to modify some of 
>> the basic parameters of the interface. Next my plan is to implement a 
>> couple of commands to allow the end-user to change those same 
>> parameters. Kinda like a more formalized tkconf.py. At the end of the 
>> day, i'd like to submit these changes to be a part of the official 
>> codebase.
>
>> Also, I'm vaguely curious why someone would want to not be able to see 
>> what they type. The obscuring isn't a
>
> You know, it's the way how things are going with passwords :) People 
> doesn't want someone staying behind their shoulders to read their 
> passwords.
>
> Anyway, show us the code. Release a working UI module first, let others 
> play with it a bit. I don't see why there cannot be two Tk-based ui 
> modules in the repository, or why your (better) module cannot replace 
> the old one - why not? I'm not the author of the tkui, but if your 
> module will base on the old one, I hope it's ok - it's GPL after all.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click