gimmickng / airdock Goto Github PK

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.

It's been brought to my attention that AIRDock.as (master | experimental) is in need of breaking down into smaller class - as a ~2000 line class it seems to be doing too many things at once.

What will follow this issue is a series of comments indicating the relationship between various functions in AIRDock.as, so as to identify regions of separation and possible cross-cutting concerns.

As it stands, containers are not required to mask their contents within their bounds. Because of this, adding a large sprite to a panel and attaching that panel to a container will result in overlapping of the sprite and other panels which are part of the container.

A solution to this is to have two masks created, one for each side (currentSide and otherSide), with respect to the parent container; that way, the panels do not have to have masks added to them (one sprite can have one mask, and one mask can only be applied to one sprite) and so only 2n masks may be needed (where n is the number of containers with subcontainers below them).

An alternative is to not expect containers to fulfil this responsibility, and instead leave it to the panel creators / IPanel implementations (not counting the default) in order to mask their contents within their bounds, or for custom IContainer implementations to be created with masks attached to their subcontainers. This would involve more work on the side of the developer, but would result in less "cluttering" in the default implementations, due to less assumptions required by other classes working with the default container implementations.

A third alternative is to use a separate flag, say useMask, within the default ContainerConfig class and have it be transparent to every other class in the rest of the library; the only problem with this is that the useMask property may be unnecessary for most other ContainerConfig instances, especially custom implementations which may not bother using a mask. For this, maybe spinning off ContainerConfig into an interface by itself, instead of a class, may be a better option too.

Which of the above is the "best" option? (There may be no right or wrong option, since it seems to be a low-priority design/aesthetic issue)