gimmickng / airdock Goto Github PK
View Code? Open in Web Editor NEWA DockPanelSuite-inspired docking library for Adobe AIR-based applications.
License: Apache License 2.0
A DockPanelSuite-inspired docking library for Adobe AIR-based applications.
License: Apache License 2.0
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 panel
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.