From: Pedro Duque Vieira Talking about the Skin discussion: Right now, I think Skins do both the Controller and View part of a Control, making it really difficult to replace, extend, etc a Control's Skin...
I would have to think much more about this but I could see some kind of View class that Skin references. In this View class, we would define just how the control represents itself visually, that is, visual nodes, layout and animations. The Skin would take care of handling events from the View and updating the Model appropriately (the Model being the part that developers already interact with in a JavaFX Control - the class that extends Control), that is, just being a kind of Controller. Main purpose would be to make it as easy as possible for developers to update a Control's visuals (layout, animation, etc). Right now it's a really hard task and 99% of developers just prefer to create a whole new control altogether rather than replace its Skin (even if they just want to slightly tweak an existing control's visuals). In this case developers would replace the "View" class with their own implementation, adding new animations, new visuals, etc... This would allow for a much easier customization of visuals while still maintaining about the same code in the application (the application code being everything else except the Skins' code). This would also allow a new echo system of Skin libraries to start to appear. These libraries would be interchangeable and would allow developers to easily update and enhance the visuals of their apps by setting a skin library. This is what the library I've created FXSkins does (https://github.com/dukke/FXSkins<https://urldefense.com/v3/__https:/github.com/dukke/FXSkins__;!!ACWV5N9M2RV99hQ!NYPX8s8ifvMNX3aG27LG4WAg_WT9drSFGMS0a9-mfDMwEYAP5m8T_2JFtRaRelbXeJdFOsrlRWIdrWsjr1g_lPE5ZCyKLJ8$>), that is, it allows a developer to enhance their app's visuals very easily without changing one line of code in their app. The difference is that if JavaFX Skins architecture were defined as I mentioned above it would be much easier for me to develop FXSkins and there would probably be more libraries like this, created by other developers. With your permission, I’ve extracted this topic into a separate discussion. First I’d start with outlining the problem we are trying to solve. What do we want to achieve? Do we want to change a certain aspect of the existing skin, or do we want to provide a drastically differently looking thing with a different behavior? Could we list some examples? Assuming we do need to touch the skins in some way, we have one major problem: skins are currently public, but extremely opaque. My understanding is that the original intent in FX was to hide everything from the developer under the premise of “future development” or “evolving implementation without introducing compatibility issues”. It’s a good idea, provided such processes were indeed ongoing. We have at least two choices: 1. Simple: make skins and behaviors less opaque (protected methods, non-final classes etc.) similarly to what Swing does. In Swing it is often possible to extend the component UI without much trouble. The price: any code that depends on particular implementation detail will break after a new feature or a bug fix. There is much resistance within this team to this choice, even though Swing has enormous success in delivering quality apps for more than two decades. 2. Not so simple: identify missing APIs that will make skin extension possible and easy. Designing the APIs in such a way that hides internal detains and yet provides enough flexibility is not an easy task. Personally, I don’t think it’s even possible without opening up the skin implementation, but perhaps I am wrong. Did I miss anything? What do you think? -andy
