Some feedback concerning this idea would be interesting.
Again, I feel the tendency to generalize things as far as possible, being tempted to create an API which allows very much control, but may possibly be easily misused.
Concerning the custom behavior (mainly initialization and rendering), I’m currently at the state where I consider the follwing: The SwoglContainer provides the necessary things for Swogl (like SwoglComponent handling and MouseEvent handling). Beyond this, it only implements the GLEventListener interface, and maintains one (or several specific) Lists of further GLEventListeners. In the GLEventListener methods mentioned above, it simply calls the respective method of all GLEventListeners in the List.
In this case, the behavior could completely be controlled by the attached GLEventListener implementations - and virtually everything would be a GLEventListener: There are several inner classes which are used for the “default things”. For example, there is an inner class that and simply applies the current camera in its ‘display’ method. Another implementation updates the Picker (for Picking SwoglComponents). And yes, there is one implementation that actually renders the SwoglComponents. Thus, the “default behavior” of the SwoglContainer may be achieved by initializing the List of GLEventListeners with something like
People might override the method that initializes this list, leave out the second line, and obtain a SwoglContainer that does not allow Picking, or add a line with a GLEventListener that performs custom rendering.
This would be very flexible, but of course there are implicit “contstraints” (e.g. the Picker must be updated after the Camera has been applied), which could hardly be documented in detail.
I’m still thinking about this and experimenting a little bit, but feedback would be very welcome.