If I understand correctly, when a dockable is hidden, it’s location
(path) is stored starting from it’s root docking station. When that
dockable is shown again, the path may not still be valid, and hence the
framework tries to guess where it should be shown. The guess may not be
accurate and the dockable is displayed in a different location.
I agree, this is an issue which cannot be resolved easily. I have a few
thoughts, though I do not know how difficult it would be to implement them.
Let’s consider the mechanism in which a dockable is stored. Let’s call
it a Situation of the dockable. However the situation of a dockable can
be computed on different criteria. One of them is to store the path from
the root station (the one you have used). Another mechanism is to store
the relation of that dockable to other dockables. So for example
‘Screen’ would be to the WEST of ‘Split’ taking 30% of the horizontal
space, and along with ‘Notes’. Yet a third strategy would be the edge on
which the dockable appears. Again ‘Screen’ appears on the LEFT edge and
takes 100% of the vertical space, and 30% of the horizontal space.
When a dockable is hidden, it is associated with a List of Situations
(PathSituation, RelativeSituation, and EdgeSituation). When the dockable
is shown again, we first try to resolve the situation based on
PathSituation, if that fails, try RelativeSituation, and if that fails
too, then we can resort to EdgeSituation.
I am sure this is not a perfect solution. There will be issues with this
too. However it might work for most cases.
Right now, the framework uses “PathSituation”. A path stores enough data to resolve to some sort of “EdgeSituation” when “PathSituation” fails (it is more a “BoundarySituation” or “RectangleSituation”, the exact location and size of a Dockable can be extracted from a “PathSituation”). So two of your solutions are already in use.
Now “RelativeSituation”. I think, this would work and yield good results (they would certainly be better than “EdgeSituation”).
I see one big problem: Dockables do not know each other. The core library does not have any mechanism to distinguish between Dockables, to assign unique identifiers to a Dockable or anything comparable. Changing that would be a radical change in design. Many applications that use DF would need to be updated, or even redesigned.
However if Dockables don’t know each other, how should they relate to each other?
I can understand your concern with backwards compatibility. I would have to understand DockingFrames in greater detail to make further suggestions. Perhaps as I go along and understand DF better, I may be able to volunteer some thoughts.
However, just a quick idea. Dockables still need not know about other Dockables if we use RelativeDockSituation. Only the Situation object associated with a Dockable will know about other Dockables in their vicinity.
So for example, when a Dockable is docked it has no knowledge of other Dockables. However once it is Docked, the framework knows of all the Dockables around it, and hence it can create a RelativeSituation object for the Dockable.
Is such a design possible.
–
Regards
Parag Shah
[quote=Beni]Your analysis is 100% correct.
Right now, the framework uses “PathSituation”. A path stores enough data to resolve to some sort of “EdgeSituation” when “PathSituation” fails (it is more a “BoundarySituation” or “RectangleSituation”, the exact location and size of a Dockable can be extracted from a “PathSituation”). So two of your solutions are already in use.
Now “RelativeSituation”. I think, this would work and yield good results (they would certainly be better than “EdgeSituation”).
I see one big problem: Dockables do not know each other. The core library does not have any mechanism to distinguish between Dockables, to assign unique identifiers to a Dockable or anything comparable. Changing that would be a radical change in design. Many applications that use DF would need to be updated, or even redesigned.
However if Dockables don’t know each other, how should they relate to each other?[/quote]
I have to think about this. I see the need for this. I would like to have this too.
However… imagine persistent storage: the relations between „RelativeSituation“ and the newly loaded Dockables needs to be put up again. How? Hm, the framework could assign a unique identifier to each Dockable (so the client does not need to do that). I have to think about this
