Tomas,
As it stands there exists two approaches being proposed (my one and
yours). The purpose of my job is to create new API that benefits the
community - your disappointment that I'm doing that is itself
disappointing to me! :-) I couldn't progress our discussion in
JDK-8091189 any further without undertaking the task of porting all
existing UI controls to use the new API, so that I could understand the
implications of my proposed approach. This has now been done and I'm
reporting back to the community my findings. I am not pushing my API
forward any more than I am surfacing it for discussion.
As I said in JavaFX Jira (now JBS), it would be really beneficial to
have clarity around how WellBehavedFX would be used in JavaFX - I seem
to recall we both agreed there was significant API in WellBehavedFX that
wouldn't (and shouldn't) be part of an InputMap proposal. Whilst I
appreciate it is a lot to ask, I think there needs to be some effort put
into creating essentially another sandbox of openjfx that introduces
WellBehavedFX in the way you envisage. Porting a small number of UI
controls to use this would make it far more clear to me, and others who
are interested in this, what your vision is. Otherwise we end up with
long philosophical discussions and not enough code (which removes any
confusion).
-- Jonathan
On 20/08/2015 6:49 a.m., Tomas Mikula wrote:
I provided my feedback on the input mapping API some 4 months ago
here (be warned, it is a *long* discussion)
https://bugs.openjdk.java.net/browse/JDK-8091189
I am very disappointed that this API is being pushed forward with all
its flaws. It is both overly complex (both conceptually and in terms
of the amount of new classes introduced) and at the same time does not
cover simple use cases well (or not at all). Note that all my feedback
was constructive - suggesting a viable alternative (referring to
WellBehavedFX as a proof of concept, which is field tested by its use
in RichTextFX).
Most importantly, I was arguing that InputMap should be a (minimal)
interface, instead of a class (locking us to the particular
implementation). InputMap in the current proposal mixes together two
concerns that should better be separated: 1. the InputMap API required
by Control (turns out it is just one method); and 2. API for the user
to construct such objects.
Splitting these two concerns would allow alternative an implementation
of 2., e.g. an implementation where all controls of the same type
(e.g. Button) share the same instance of InputMap, instead of it being
recreated for each instance of Button.
Another wart is the InputMap#lookupMapping(Object) method (emphasis on
*Object*). I think everyone now agrees that Map#get(Object) is a
terrible API (although it might have been necessary for backwards
compatibility at the time). Aside from the untyped Object thing, the
idea that when I want the control to ignore some specific input, I
first need to look up all the mappings that match it and remove them
is not going to work (simply because the same mapping that matches the
input to be ignored can also match some other input that should not be
ignored). User code that is using lookup is also not going to be
forward compatible, because the default mappings installed by the
controls themselves may change in a newer JavaFX version, thus the
return value of lookupMapping can be different in different JavaFX
versions.
"Specificity" seems like an unnecessary "feature" to me that I can't
see anyone putting into a good use. I cannot predict the effect of
adding a mapping without knowing what mappings with what specificity
are already in the InputMap. As a consequence, when as a user of
JavaFX controls I want to add a mapping, I need to be aware of what
mappings are already installed by the control itself (or its skin).
Even if I knew all that, it can change in a future version of JavaFX,
so my code is not going to be forward compatible.
I just picked a few things. I encourage anyone interested to read the
above mentioned long discussion (relevant part starts from 2015).
Regards,
Tomas
On Sun, Aug 9, 2015 at 9:58 PM, Jonathan Giles
<[email protected] <mailto:[email protected]>> wrote:
The plan is for this kind of detail to be included in the javadoc
documentation.
Thanks,
-- Jonathan
On 7/08/2015 10:36 p.m., Mike Hearn wrote:
I don't know much about skins and how they work, as I haven't
implemented custom controls. My only knowledge comes from
rummaging around inside the code to find some hacky way to get
a particular effect, often via CSS.
I was hoping to read about the skins infrastructure, what it's
for, how it works etc in the jfx.s.c.skins package description
but no such luck. Is the plan for the JavaDocs to give a high
level description of skinning, how to implement it in your own
code etc, or are there plans for other articles to describe this?
