The flow of opening a file is too complex and seems to be required refactoring.
As I understand the current procedure is roughly following:

1. `openDocument` defined in `mainwindow.cpp` is called
2. `setCurrentFile` defined in `openfileinfo.cpp` is tail-called
3. `currentChanged` is tail-emitted 
4. `setFile` defined in `mdiwidget.cpp` recieves
5. `setFile` calls `part` defined in `openfileinfo.cpp`
6. `setFile` does complex process
7. `activePartChanged` is emitted
8. `createGUI` in `mainwindow.cpp` recieves

I thing the all 2-7 can be done in `openfileinfo.cpp` straightforwardly. Just following:

2. `setCurrentFile` defined in `openfileinfo.cpp` is tail-called
3. `setCurrentFile` calls `part` defined in `openfileinfo.cpp`
4. `setCurrentFile` does complex process
5. `activePartChanged` is emitted (from `setCurrentFile`)
6. `createGUI` in `mainwindow.cpp` and `partChanged` (or so) in `mdiwidget.cpp`  receive
7.  In `mdiwidget.cpp`, `partChanged` (or so) calls `addWidget`(widget)

After all, it seems currently mdiWidget does too many jobs. It shouldn't create or validate parts.
The definition of MDIWidget is also combined with the welcome widget. It can be separated, as I understand.

In addition, seemingly it is assumed that the parent of KPart may vary, with checking of the parent. However it isn't always mdiWidget?

I think I can patch them (if time permits), however first of all I don't know whether those are: actually required for intended functionality, kept so as just working, historical thing, or meaningless. I would appreciate your comments.

Shunsuke


Reproducible: Always