Issue 25173: IDLE - several common dialogs don't have correct parent set (original) (raw)

The confirmation, file, etc. common dialogs in tkinter accept both a 'master' and a 'parent' argument. Master is not required (it will use parent if not provided). Parent is used to associate the dialog with a given window. On Mac OS X, using parent further turns this into a 'sheet' attached to that window.

Most places in IDLE we're correctly using parent, but there are several places that master is provided, but not parent, e.g. IOBinding.py. This is most noticeable doing a 'do you want to save before closing...' where now it is not attached to the window on Mac, but it should be.

Need to go through the code, every place the common dialogs are used and check if master/parent are being used correctly.

General comments on 'master' versus 'parent': This seems to be a matter of confusion in tkinterland. When I have asked before about the difference, all I have gotten is that they are more or less the same.

http://effbot.org/tkinterbook/entry.htm, for instance, used 'parent' and 'master' interchangeably in the text, says the signature is 'master=None', copying the docstring, and then says "master\n\tParent widget". Thinking "Ah, they are the same thing" is quite easy after reading this.

A widely recommended reference, http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html, which has otherwise been very helpful to me, documents widgets as having a required 'parent'. (I don't blame it for avoid the complication of a default Tk().) But Widget(parent=root) and Widget(master=root) are not normally the same.

But simple tests may not obviously show a difference, because 'master=None' really means 'master=<hidden default Tk()', unless one has disallowed such, and invalid options are sometimes accepted (at least initially).

Specific comments about 'master' versus 'parent' in relation to this issue, which concerns tkinter.commondialog.Dialog and subclasses, especially messagebox.Message: From experiments and code reading, I discovered the following.

Commondialog.Dialog is does not wrap a tk widget, but is a common baseclass for multiple widget wrappers. The 'master' parameter is used as a master for a Frame. The Frame was needed 20 years ago. Is this still true today? It is not used at all by messagebox.Message. If master is not given, the parent option is used for its value.

The complete set of options (from an exception) is -default, -detail, -icon, -message, -parent, -title, or -type. All but 'detail' are discussed in comments and http://effbot.org/tkinterbook/tkinter-standard-dialogs.htm. Perhaps 'detail' was added since the code and book were written. The latter says

parent (widget) Which window to place the message box on top of. When the message box is closed, the focus is returned to the parent window.

For message boxes, it seems we should use parent=xyz, unless we want the box free-floating, which might be never, especially given the extra meaning on Mac. It also seems that we need not use master=abc unless we omit parent=xyz or xyz is not suitable as a Frame master. (Are there any restrictions on this?)

I need to know if any of the other dialog wrapper use 'master', or if a different usage rule is needed for them.

Grepping (find in files) 'master=' gets 23 hits, 8 in IOBinding, and in 8 different files. Not all of these are for messagebox. Grepping 'master =' finds 1 more use in a message box call in IOBinding. (This is a style error, which can be fixed when working on a file). Grepping 'tkinter.messagebox' gets 14 imports, so many files are not using 'master' in messagebox calls.

If you provide a messagebox patch or patches for both 2.7 and 3.4, I will review and presumably apply. We can then consider the other dialogs.

(When we re-write files to pep8, we will use the 3.x 'messagebox' and rename tkMessageBox in the 2.7 file. I am thinking about doing the switch now, and adding 'tkMessageBox' as a back-compatibility alias. It would be best to do this when adding mbox tests.)

I think both master and parent are needed, for the likely rare case when you don't want a dialog attached to any window, but it needs a Tk window handle to build the dialog from.

Ran across that in SearchEngine, which has a root window just for the purpose of creating dialogs, but the search engine doesn't know what search dialog is invoking it (a bad example, as in this case, the dialogs should be the ones display the error, not the search engine).

Anyway, have attached masterparent.patch for default branch which updates those message and file dialogs that make sense to use parent instead of master.