[Idle-dev] breaking up is hard to do...

[Terry Reedy]

On 9/4/2015 3:18 PM, Mark Roseman wrote:

> Goals:
> 1. split off tangential features from mega-modules (EditorWindow and PyShell)
> 2. better encapsulation; reduce internal knowledge about other modules
> 3. reduce assumptions affecting how UI assembled (e.g. toplevels)
> 4. reduce redundancies
> 5. make it easier for new IDLE contributors to navigate code base

Agreed to all; started on #5 with new readme with index to files.

> Non-goals (for now anyway):
> 1. internal API stability
> 2. supporting people using pieces of idlelib
> 3. keeping third party IDLE extensions working

These have to be kept for 2.7 & 3.5, but method will be to keep obsolete 
files around for now.  3.6 is a different question.

> 4. keeping existing tests working

Each test file must pass.  If patch makes individual tests fail, we will 
have to either rewrite or remove.  So agreed at individual assert level, 
which I presume is what you meant, not at file level.

> Work Items:
>
> 1. Define a "IdleComponent" class (effectively a frame or toplevel). Examples would be editor windows, shell, prefs dialog, etc. Base class provides an API for various responsibilities, notifications etc. that can be handled in subclasses if needed.

> 2. Replace WindowList, FileList, PyShellFileList with a smarter "hub" that ties all the pieces of the application together (see previous point). Also serves as a way to broadcast changes application wide, manage overall application state, etc.

It is hard to evaluate things that do not exist ;-).
>
> 3. Create a "IdleMainWindow" which would bundle together a tabbed editor, status bar, debug panel, shell area via paned windows etc. Keep this as simple as possible (delegating to other components) so that experimenting with how pieces are put together is easier.

Key think is making it easy to assemble pieces, so there can be multiple 
bundles.

> 4. Improve module level documentation to help people navigating code base. Clarify role of module within application. Specifically highlight modules that are present for Tk 8.4 compatibility only, so they can be later removed.

Module and functions docstrings are an ongoing project since a couple of 
years.

> 5. EditorWindow - move all the help stuff into a separate module

Partly done.

> 6. EditorWindow - trim responsibilities so it handles "just" editor stuff. For example, things about launching dialogs, creating menu bars, etc. should get moved elsewhere.  Should only respond to editor-related menu commands, while more 'application level' menu commands get done elsewhere.

Agreed.

> 7. Abstract/centralize all the menu management, key bindings etc. as required, delegating minimum amount needed to IdleComponent subclasses. Will likely center around the notion of commands (which may be equivalent to the virtual events used now), but components shouldn't have to mess with menus (would enable putting toolbars etc. in later if desired)
>
> 8. PyShell - split ModifiedInterpreter, Pseudo*File into other modules, strip PyShell class to core functionality like with EditorWindow (e.g. move debugger commands elsewhere). This module is a prime candidate to have everything moved elsewhere, leaving it basically as a main application startup script.
>
> 9. Make it so that we always have a Python shell/interpreter (like we do now) and a debugger object (or wrapper) available, even if they're not onscreen. Ideally separate debugger at least from a UI, so that UI can be created as needed and attach to underlying object.

-- 
Terry Jan Reedy