The active layer¶

In order to make sense of a layered drawing and to provide a context for user input, DrawKit supports one active layer per drawing at a time. DKDrawing is the object that maintains the active layer reference - other objects such as DKViewController also provide convenient access to this value.

The active layer is one nominated layer to which all input is directed. The input may come from menu commands, the keyboard or the mouse being used in a view, or items dragged into a view. For many simple kinds of layers, a layer is able to handle this input directly without the intervention of a controller - in fact by default DKViewController merely forwards all such events to the current active layer without interpretation. The active layer is analogous within the DrawKit system to the active window within an application (or entire computer desktop) as a whole - it provides a context for the focus of a user’s current work.

Input events come from the key view to the active layer through the view’s controller by way of invocation forwarding (except mouse events, which are forwarded directly). This allows a layer to simply implement whatever commands it wants to respond to directly as if it were itself a subclass of NSResponder and part of the responder chain. Effectively the active layer is automatically a delegate of the key view. Object layers extend this forwarding to the selection and even individual target objects. This general approach means that DrawKit is able to offer many commands and features at a variety of different levels that an application can take advantage of (or choose not to, simply by ignoring their presence). For example if your application wishes to implement commands such as Move Layer Forward or Move Layer Backward, it can simply make the appropriate methods available to 1st Responder in Interface Builder and hook up menu items to them - the forwarding mechanism originating in DKDrawingView will see to it that they “just work” as expected.

The current active layer needs to be set appropriately. If your application has many potential active layers, it will need to arrange a user interface to select which one is active. Since the current active layer establishes so much of the basic context of DrawKit, it is important that a UI makes the active layer reasonably obvious to the user. Alternatively a simple application might only have one layer, or not allow it to be changed at all. The active layer can also be selected automatically by a hit being detected in the layer. DKViewController implements this automatic switching, and also allows it to be disabled. The layer itself is required to return whether it was hit or not - typically for object layers this means whether any contained object was hit.

A layer may refuse to become the active layer by returning NO to -layerMayBecomeActive. This response is always honoured, whether switching the active layer through DKDrawing‘s -setActiveLayer: method, or automatically when the mouse hits the layer. In addition a layer can get first shot at the mouseDown that might cause automatic layer activation by overriding -shouldAutoActivateWithEvent: and returning YES or NO. This is addition to the hit test itself, which will have already been performed and found to have hit something.

Note that the active layer is expected to be an individual layer, in general. It is theoretically possible to make a layer group the active layer, but unless that group is a special subclass that implements some particular behaviour, it is not going to do anything useful. Your application’s UI should generally prevent the user from making a layer group active unless it has a special reason to allow it. By default, DKLayerGroup always refuses the active status.