The trouble with Skins

[Tomas Mikula]

Thank you, Richard, for your response.

On Mon, Mar 23, 2015 at 2:07 PM, Richard Bair <richard.bair at 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