For all Zecke thoughts a nice solution could be found during the last weeks :-)

svn path=/trunk/KDE/kdebase/apps/; revision=642616

1 files changed, 0 insertions, 36 deletions

diff --git a/src/THOUGHTS.zecke b/src/THOUGHTS.zecke
deleted file mode 100644
index 3b9f383fc..000000000
--- a/src/THOUGHTS.zecke
+++ /dev/null
@@ -1,36 +0,0 @@
-Zecke's Implementation Thoughts
-
-
-Task:       Kill the Dolphin Singleton
-Reasoning:  Have more than one Dolphin TLW
-Approach: 
-    1. Create DolphinApplication to hold all TLW's.
-    2. Make dolphin.h dolphomainwindow.h
-    3. Change the Views to have a DolphinMainWindow
-       parameter
-
-Reasoning:
-    I find it more natural that the DolphinApplication
-    holds and controls the list of managed MainWindows and
-    will control the life time of them, specially deleting
-    them on exit.
-    The downside is that DolphinApplication and DolphinMainWindow
-    need to work together but this is managable
-
-    Making DolphinView::mainWindow() public. Most users of the
-    current Dolphin::mainView have a pointer to the current view
-    already. We could pass a second pointer for the mainwindow each
-    time but the same can be achieved by using the appropriate
-    DolphinView::mainWindow.
-    Another approach would be to ask the DolphinView to execute
-    actions on the MainWindow like it is done with declareViewActive
-    in DolphinView. I'm not entirely sure which one wins but currently
-    using mainWindow() does not show any negative impact.
-
-    2 times Dolphin::mainWin was used to check if the view is current.
-    this can be made a method of of the view
-
-    1 time we want the viewChanged signal of our mainwindow to update,
-    the UrlNavigator could connect a signal to a signal to allow this
-
-    12 times this was used to access the actionCollection