On 1/26/2011 2:11 AM, rantingrick wrote:
On Jan 26, 12:53 am, Terry Reedy<tjre...@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
--
http://mail.python.org/mailman/listinfo/python-list
