Need GUI pop-up to edit a (unicode ?) string

[Terry Reedy]

On 1/26/2011 2:11 AM, rantingrick wrote:
> On Jan 26, 12:53 am, Terry Reedy<tjre... at udel.edu>  wrote:
>
>> I only see "self.wait_window(self)" in the Dialog base class and not in
>> SimpleDialog, which is what I though you were talking about. It is the
>> last line of Dialog.__init__.
>
> Yes. In the module "tkSimpleDialog"

In 3.x, the module is now tk.simpledialog -- all lower case. The purpose 
of all lowercase module names is to avoid confusion with upper case 
class names.

> the class "Dialog" is what i am
> referring to. Sorry for the confusion.

and there is also a SimpleDialog class.

>
>> It appears that the intention is that all
>> configuration be done in the body and button_box methods which are
>> called earlier.
>
> Yes exactly. And this works well most of the time. However there are
> many times where you may want to create a dialog with say a Label. And
> you do not want to hard code the string displayed on the label.
> However you cannot change the string once you initialize the dialog
> because it enters a "modal wait loop". So what i am proposing is that
> we change tkSimpleDialog to be like any other modal dialogs out there.

SimpleDialog has a go method. Dialog does not, but I see no reason (yet) 
why it could not.

> We move the modal code into a show method and use the dialog like i
> suggested. I can send you a patch if you would be interested.

I saw that first and was puzzled what you were asking. Clearer now.

> My patch
> does break backward compatibility. However we can make it compatible
> somehow. Or an alternative approach would be to create a new dialog
> module and then depreciate tkSimpleDialog.  Let me know on or off list
> if you are interested.
>
>> As far as I know, anything contributed to the stdlib has been licensed
>> by the author to be redistributed under the Python license and can be
>> patched by the developers. (This is one reason for people to not
>> contribute their code to the stdlib.)
>
> I don't understand what that means. Are you suggesting that
> contributing code is bad?

If you write code and want to keep absolute control over it -- the api, 
the doc, the coding style, and the test methods -- then yes it can be 
bad, especially for people who are not active core developers. 
Contributing can also be a great -- if the module already meets with 
approval or if one is flexible and wants the critical review and likely 
improvement and increased usage. It depends on one's goal in writing the 
code.

-- 
Terry Jan Reedy