blob: 3b9f383fc2db2b068ad9fbef59baa384fb758dd4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
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
|
