You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of v0.4, foreign containers and the crossDockingPolicy is broken for inter-Docker interactions. This is because a Docker only attempts to handle panels (and containers) which are local with respect to itself; this is because attempting to run as usual for foreign panels and containers results in duplication of event listeners, containers and native windows. After this point, no guarantees can be made about future events, since the two Dockers will effectively compete for the drag-dock operation.
As a result of this, Dockers do not attempt to handle any foreign panels or containers, and routinely checks whether any affected panels are local or foreign to it both before and after a critical event - such as a drag-dock event, or a state-toggle event, etc.
However, this has a problem with it - if the container is local to the Docker, but the panels are not, then the Docker ignores the panel; at the same time, though, the container remains "stuck", since it cannot affect the panels within. The Docker whose panels are local to it, however, is isolated from this - any events on the panels are unreachable to it, since events propagate from the container containing the panels - but the container is local to the foreign Docker, and so cannot receive those events; at the same time, the foreign Docker ignores those events since it assumes the local Docker can handle them!
As a result, the following bugs, may, can and/or will occur:
Moving a set of panels to a foreign Docker will cause the container to which the panels are attached to, to "stick" in place (as described earlier)
Docking a set of panels to a foreign Docker's parked container may cause the foreign Docker's dockPanels() method to fail as it searches for empty containers to dock to (but are already occupied by panel(s) foreign to it)
A foreign panel attached to a subcontainer of a parked container will cause the integratePanels() method of the Docker foreign to the panel to fail since it cannot move the panels to their previous non-parked roots without affecting the panel
Alternatively, it will proceed without error, but the parked container will have an irregular structure consisting of mostly empty containers.
Not all of these have been observed yet, but it is quite likely that it will happen sometime in the future - further testing is required.
The text was updated successfully, but these errors were encountered:
Note: For the time being, until this issue is fixed, it is recommended to not use more than one Docker in an application; if more than one has to be used, then it is recommended to set mutually-isolated crossDockingPolicy on both the Dockers.
Examples of mutually-isolated crossDockingPolicy are:
CrossDockingPolicy.PREVENT_OUTGOING or CrossDockingPolicy.REJECT_INCOMING on both Dockers
CrossDockingPolicy.INTERNAL_ONLY on any one of the Dockers and any other CrossDockingPolicy flag on the other.
Another thing to note: I*Docker (IBasicDocker, ICustomizableDocker, etc.) instances which do not have the same dockFormat (of type IDockFormat), or have instances which do not return the same format strings, will not be able to communicate with each other, regardless of their crossDockingPolicy.
As of v0.4, foreign containers and the
crossDockingPolicy
is broken for inter-Docker interactions. This is because a Docker only attempts to handle panels (and containers) which are local with respect to itself; this is because attempting to run as usual for foreign panels and containers results in duplication of event listeners, containers and native windows. After this point, no guarantees can be made about future events, since the two Dockers will effectively compete for the drag-dock operation.As a result of this, Dockers do not attempt to handle any foreign panels or containers, and routinely checks whether any affected panels are local or foreign to it both before and after a critical event - such as a drag-dock event, or a state-toggle event, etc.
However, this has a problem with it - if the container is local to the Docker, but the panels are not, then the Docker ignores the panel; at the same time, though, the container remains "stuck", since it cannot affect the panels within. The Docker whose panels are local to it, however, is isolated from this - any events on the panels are unreachable to it, since events propagate from the container containing the panels - but the container is local to the foreign Docker, and so cannot receive those events; at the same time, the foreign Docker ignores those events since it assumes the local Docker can handle them!
As a result, the following bugs, may, can and/or will occur:
dockPanels()
method to fail as it searches for empty containers to dock to (but are already occupied by panel(s) foreign to it)integratePanels()
method of the Docker foreign to the panel to fail since it cannot move the panels to their previous non-parked roots without affecting the panelNot all of these have been observed yet, but it is quite likely that it will happen sometime in the future - further testing is required.
The text was updated successfully, but these errors were encountered: