Contributing - GimmickNG/AIRDock GitHub Wiki

First off, if you're reading this, thanks for deciding to contribute to the development of AIRDock!

As of this writing, AIRDock has 0 dependencies so far (apart from the default flash package), and it's better if it stays that way. Whenever adding a feature, ask yourself, will fully realizing this feature require reinventing the wheel, where a third party library do the job better?¹, or are there other ways to implement this which offer more flexibility? If you answered "yes" to any of them, then see if it is possible to delegate that responsibility out, for example by defining an interface which allows that feature to be included.

An example of a possible feature that may involve a dependency:

When the user initiates a drag-dock action and hovers over an IDockHelper instance, then the dragging thumbnail should fade in to the background and a region should be drawn to indicate the result of docking the panel or container there.

At first glance, it doesn't look like there's a problem with this feature. However, the key problem is the fade in to the background part. This requires code to ease the transition from 100% opacity to 0% opacity. That would require either adding an Event.ENTER_FRAME or a TimerEvent.TIMER listener; a better option is to use a dedicated tween class, like Grant Skinner's GTween or GreenSock's TweenLite (Or TweenMax, or any of the others). This introduces a dependency, and a rather unnecessary one at that: users who don't need the feature will end up having to introduce a new, entirely useless dependency, just to use AIRDock, and that's not even getting into the thorny issues of licensing.

A better solution is to have a dedicated interface which handles the job of rendering the thumbnail for the drag-dock action, and provide a way for the interface to know when the user is hovering over an IDockHelper instance, so that it can do the job of fading out the thumbnail. It could also generate the thumbnail itself, so that customized thumbnails can be used if needed. All that's needed is the default implementation - which does not need to provide the fade-out feature, but it must be easy for the developer² to implement manually if they need the feature (e.g. via delegates which perform boilerplate operations, etc.)

---

^{1. "Better" is a subjective measurement. However, in most cases, a feature which can be better performed by a third party library is that feature which may take a significant amount of time to implement, or introduces extra bloat not directly contributing to the main library, or one which is performed more efficiently by a third-party alternative. This does not mean that bloat is acceptable if it is related to the main library, nor does it mean that if your implementation is the most efficient compared to third party alternatives, then it can be included; a holistic analysis of the feature has to be performed, in view of keeping the library as lean as possible. In short: if you have to ask, then you should probably delegate it out.}

^{2. Here, developer refers to one who uses the AIRDock library, not one who works on it.}