[External] : Re: [Request for Comments] Behavior / InputMap

[Pedro Duque Vieira]

Yes Input Map would be a welcome addition.

--

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), 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.

Thanks Andy! Kind regards,


On Mon, Oct 16, 2023 at 6:51 PM Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Thank you for clarification!
>
>
>
> I just want to mention that here we are straying into what looks like a
> parallel discussion about skins (nothing wrong about it!).
>
>
>
> just the Skin part. This would likely be a big effort but perhaps it could
> be split into smaller tasks till the end goal is achieved.
>
>
>
> Could you please expand upon this?  What parts should skins be split into?
>
>
>
> As it currently stands, Skins have two responsibilities - visual
> representation (the View in MVC paradigm) and handling of events, currently
> represented by the private behavior implementation.  In some sense,
> behaviors and skins are tightly coupled - it would be hard, in my opinion,
> to separate them without introducing large public API surface and
> consequently solidifying certain aspects of one particular implementation.
>
>
>
> As far as I can tell, the input map proposal addresses the low hanging
> fruit of simple customization like your case of unregistering all key
> mappings from the ScrollPane.  It is certainly not a call to a major
> redesign.
>
>
>
> Cheers,
>
> -andy
>
>
>
> *From: *Pedro Duque Vieira <pedro.duquevieira at gmail.com>
> *Date: *Sunday, October 15, 2023 at 05:11
> *To: *Andy Goryachev <andy.goryachev at oracle.com>
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *[External] : Re: [Request for Comments] Behavior / InputMap
>
> Hi Andy,
>
>
>
> Sorry for the late reply but unfortunately I didn't have time to respond
> to you earlier.
>
>
>
> Yes, you're right, Swing did allow for easier extension of controls'
> themes and you did see people coming up with new theme libraries that
> overwrote Controls appearance/behavior through code.
>
>
>
> I think the main issue with Skins being difficult to extend is that
> they're taking on too much responsibility. They do both the View and
> Controller part of the Controls (the model being the part that developers
> interact with). When I talk about MVC here I mean it in a loose way, I'm
> referring to any and all the MVC like patterns. If for instance there was a
> clear class, in the Skin architecture, that just took care of how a Control
> is displayed, and nothing else, it would be easier to overwrite, for
> example, how the Control is displayed and hence override Skins.
>
>
>
>    - What are the missing APIs in Skins that we can add to simplify
>    extension of skins?
>
> I think, as I said above, Skins would have to have a different
> architecture. IMHO, their responsibilities would likely have to be split
> into different classes each with a smaller set of concerns. I'm not talking
> about changing the whole Control architecture, just the Skin part. This
> would likely be a big effort but perhaps it could be split into smaller
> tasks till the end goal is achieved.
>
>
>
>    - Would this proposal (BehaviorBase + InputMap) prevent us from moving
>    forward?
>
> Likely no.
>
>
>
> BTW, in the past I already had the need for this API (InputMap) for an
> application I was developing that's now in production. To do what I needed
> I had to call on private methods using reflection, etc, since there's no
> public API to achieve this yet.
>
> My use case was that I was creating a custom control, "inside" that
> control I used a ScrollPane but ScrollPane has a bunch of default key
> mappings, like SPACE, PAGE_UP, PAGE_DOWN, HOME that when pressed already do
> predefined things. I needed to remove those key mappings as in this
> application those keys were already meant to do something else other than
> what the default JavaFX ScrollPane does with them.
>
>
>
> Thnaks. Kind regards,
>
>
>
> On Mon, Oct 9, 2023 at 7:38 PM Andy Goryachev <andy.goryachev at oracle.com>
> wrote:
>
> Thank you for the feedback!
>
>
>
> You are right: even though Skins are public classes now, they are very
> difficult to extend – at least, much more difficult that Swing UIs.  It’s a
> source of constant discussions within the team – how much of it should be
> made public (protected) to allow for extension vs. how much of it should be
> hidden as implementation detail to minimize the API surface and allow for
> evolution.  While opening it all up might alleviate developers’ pain when
> extending, it poses a great(er) danger of introducing of all sorts of
> compatibility issues with respect to bug fixes and other changes.
>
>
>
> If we speak about extending skins specifically, a good question might be:
> what exactly is missing?  Which APIs do we need to enable easier extension
> of skins?
>
>
>
> One thing I would like to clarify is that the Behavior / InputMap proposal
> is not about extending skins.  It is also not about making the concrete
> behaviors public (a task which is probably as large as adding missing
> public APIs to skins).
>
>
>
> The main goal is to allow for extending and slightly modifying the
> behavior – like altering the way navigation works in a text control, or
> adding a new key binding.  As a result, the overall proposal is smaller
> than it could be.
>
>
>
> Having said that, nothing prevents us from exploring options to open up
> skins, or making behaviors public.
>
>
>
> To summarize:
>
>    - What are the missing APIs in Skins that we can add to simplify
>    extension of skins?
>    - Would this proposal (BehaviorBase + InputMap) prevent us from moving
>    forward?
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Pedro
> Duque Vieira <pedro.duquevieira at gmail.com>
> *Date: *Saturday, October 7, 2023 at 14:05
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: [Request for Comments] Behavior / InputMap
>
> I second the opinions of others that JavaFX is too closed which, I think,
> hinders the work of library and app developers.
>
>
>
> I wonder if the reasons that were used to make this design decision back
> when JavaFX was being created still hold true. Back in the beginning there
> were more developers involved in developing JavaFX, significant features
> were added at a fast pace so the fact that it was closed wasn't such a big
> drawback as things were changing quickly and missing features that were
> spotted could be added relatively quick.
>
>
>
> Commenting more specifically on your question... I think Skins could
> benefit generally from being easier to extend. The promise of skins is that
> you could easily replace a control behavior and visuals without changing
> its model (the model being the part of the control that developers usually
> interact with) but the problem is that the JavaFX SDK control's skins are
> very difficult to extend. Say, if you only want to add a specific visual
> feature (something that CSS can't do) it takes a significant effort.
>
> What you usually see is that developers opt to create completely new
> controls rather than just new skins.
>
> My attempt at providing new skins for existing javafx sdk controls is
> here: https://github.com/dukke/FXSkins
> <https://urldefense.com/v3/__https:/github.com/dukke/FXSkins__;!!ACWV5N9M2RV99hQ!KEGCkXgeKFVmcORYZZitJOe2wS_s5IdvWHuf9GfRNFkcJWLB1VYNmSwaSO-a_UsIx4HqSa9JYfNU-F1rnEUMVGJOrILwwVs$>
>
> Still it required quite a bit of effort.. at least more than it could
> ideally take (I think).
>
> The advantage of this kind of approach (providing new Skins) and the
> library I created "FXSkins" is that you can enhance the controls of your
> existing app very easily by setting new skins in the CSS stylesheet. You
> won't need to change anything directly in the code.
>
>
>
> Regarding the current state of the JavaFX SDK Skins, there isn't a clear
> MVC separation, the skin does the Controller and View part at the same
> time. Perhaps ideally there would be a clear View part that could easily be
> extended to add different advanced visuals to the control (by advanced I
> mean, anything that can't be done with CSS). And then perhaps also the
> Behavior part where you can easily change the control's functionality. I
> remember at some point Richard Bair saying that it was a goal to make
> Behaviors public.
>
>
>
> Thanks!
>
> --
>
> Pedro Duque Vieira - https://www.pixelduke.com
> <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!KEGCkXgeKFVmcORYZZitJOe2wS_s5IdvWHuf9GfRNFkcJWLB1VYNmSwaSO-a_UsIx4HqSa9JYfNU-F1rnEUMVGJO6wtkRnc$>
>
>
>
>
> --
>
> Pedro Duque Vieira - https://www.pixelduke.com
> <https://urldefense.com/v3/__https:/www.pixelduke.com__;!!ACWV5N9M2RV99hQ!KEGCkXgeKFVmcORYZZitJOe2wS_s5IdvWHuf9GfRNFkcJWLB1VYNmSwaSO-a_UsIx4HqSa9JYfNU-F1rnEUMVGJO6wtkRnc$>
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231017/ef1da51c/attachment-0001.htm>