Thank you, Richard, for your response. On Mon, Mar 23, 2015 at 2:07 PM, Richard Bair <richard.b...@oracle.com> wrote: > tl;dr; I lean toward keeping the Control API as view-agnostic as possible, > but where view details become essential to the operation of the control, then > define the Control to always include those specific view details.
This makes sense, but leaves no middle ground. Either the control fits the Skinnable concept (like Button or CheckBox or SimpleMetroArcGauge), or the Control has to include specific view details. In the latter case, these cannot be delegated to the skin, because Control does not know what API is available on the Skin. There is no way for ListView to say that it only accepts skins that implement ListViewSkin interface. Thus, the control has to implement those view details itself, making it effectively a skin-less control. Therefore, there is no middle ground where the Control handles some view-specific details and leaves the rest up to the Skin. Note that passing information (even view-specific) from Control to Skin works somewhat well: at worst the Control can define a new event type that the Skin will observe (such as the ScrollToEvent fired on ListView to order the Skin to scroll). It is the other way that is problematic: when the Control needs to get view-specific information from the Skin. Of course this can be solved (I have done it myself), but at the cost of ugly API on the Control. Tomas
