Is there any reason the IDLE settings dialog is modal?

(Actually while it is modal on Windows and Linux, on OS X you can actually switch back to the main window while the settings dialog is up, but you can't actually type etc. into it!)

While I could probably ask the same question about all the other modal dialogs, let's start here. :-)

I don't know. I do not thing that any option settings affect the dialog box itself, Someone could switch modal off and experiment. It would certainly make it easier to change something, Apply, and then try it out. The is one place I would not feel obligated to follow modal-happy Microsoft. (Too small, cramped dialog boxes designed for 400x600 screen is another.)

I have asked the same on at least one of the search dialog issues. The search dialog for Notepad++ is not modal and works fine.

Also see bpo-24039.

Ok, I'll do some playing around with that one over the next few days, and see if anything comes up.

Incidentally (and this I would say is a definite bug) because the modal doesn't fully work on the Mac, you can actually create multiple copies of the config dialog!

I've attached decouple_config.patch, which removes some internal knowledge about EditorWindow from configDialog. This is a step towards making the preferences dialog non-modal (and also to launching either the current dialog, or a new ttk-dependent one).

The thing that could currently break things if we switched to non-modal is that when configuration changes, we directly examine "parent.instance_dict". Unfortunately, it's possible that parent will have been destroyed before this happens.

Instead of holding onto parent, the patch holds onto the FileList object, which should persist. It also takes the opportunity to delegate the specifics of what should happen to active editor windows on config changes (previously in configDialog) to FileList, which in turn delegates the specifics back to each EditorWindow instance.

A separate patch, depending on this refactoring, will then change the dialog so that it can be launched non-modally, and make sure only a single instance is present.

The attached demodalize.patch (which includes the changes from the previously posted decouple_config.patch) changes both the settings dialog and the about dialog to be non-modal.

There's a new class UIFactory which is responsible for launching these kinds of windows, keeping track of them, and making sure there's only one of each kind at a time. This is also where the logic for choosing ttk vs. non-ttk components will go.

As a (questionable) bonus, the about dialog, which now incorporates the README's etc directly into the window rather than launching further modal dialogs, also has some other minor cosmetic changes.

Terry, when you get a chance, it would be great if you could have a look at demodalize.patch (or if you can suggest someone else who would be good to take a peek at it).

This is sort of the baseline for the uifactory, and touches a lot of things in small ways to decouple some of the inter-module dependencies.

Other things (the new query dialogs, ttk versions of configuration and search dialogs, etc.) depend on this patch to wire the uifactory into the infrastructure.

Thanks!

Note: about dialog part of the 'demodalize' patch split off and now in bpo-24813; the bulk of the rest of it, which is really providing a cleaner FileList API rather than direct access to internals from EditorWindow, is in bpo-25031.

After the latter patch is accepted, I'll put up a new patch here that is just the changes to make settings modeless... will be just a dozen lines of code or so.