RichTextFX and Flowless looking for new maintainers (and home)

[Tomas Mikula]

Hi everyone,

since I don't work with JavaFX (or GUI applications, or that matter)
anymore, it is hard for me to keep up with the maintenance of my JavaFX
projects. I am therefore looking for new maintainers (and possibly new
home) of my most active JavaFX project, RichTextFX (
https://github.com/TomasMikula/RichTextFX/), and its essential dependency,
Flowless (https://github.com/TomasMikula/Flowless/).

I want to thank Jordan Martinez, who has been doing the bulk of
fixing bugs and reviewing pull requests for the past two years.

I am hoping that either some bigger user of RichTextFX, or a UI framework
for which RichTextFX would be an attractive addition to the portfolio,
would step forward and take it up. Jordan and I are happy to help with the
transfer.

Best regards,
Tomas

Re: Bootstrapping in Java9

[Tomas Mikula]

Thanks for the links, Kevin. By a quick glimpse, it seems like Tom's
proposal could be used to solve all three.

Tomas

On Tue, Jun 21, 2016 at 11:53 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> As Thomas notes, this is independent of JDK 9 or Jigsaw. We have a couple
> similar RFEs filed:
>
> JDK-8092262 <https://bugs.openjdk.java.net/browse/JDK-8092262>: Add
> Application.launch(ApplicationFactory,String... args)
> JDK-8091703 <https://bugs.openjdk.java.net/browse/JDK-8091703>: Support
> for Dependency Injection in Application
> JDK-8090838 <https://bugs.openjdk.java.net/browse/JDK-8090838>: Add
> Application launching support for dynamic languages
>
> This would be another variation of the JavaFX life-cycle and is something
> we could consider for a future release (or even a JDK 9 update release) if
> there were enough interest in doing this.
>
> -- Kevin
>
>
>
> Tomas Mikula wrote:
>
> I think what Tom proposes makes sense even regardless of Java 9. Another
> benefit is not requiring a no-arg constructor.
>
> Regards,
> Tomas
>
> On Tue, Jun 21, 2016 at 5:19 AM, Tom Schindl  
> 
> wrote:
>
>
>
> Hi,
>
> I was playing around with Java9 a bit yesterday things worked fine but
> what disturbs me a bit is that I need to export the package with my
> Application-Subclass because naturally Java9 can not create an instance
> of none-exported class with reflection.
>
> Although not being a big problem it disturbed me a bit and from my basic
> understanding I think it should be possible to introduce a 3rd variant
> of Application.launch() who looks like this:
>
> Application#launch(Application,String...)
>
> This way no reflection is needed by the jfx bootstrap code.
>
> Tom
>
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruckhttp://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>
>
>

Re: Bootstrapping in Java9

[Tomas Mikula]

I think what Tom proposes makes sense even regardless of Java 9. Another
benefit is not requiring a no-arg constructor.

Regards,
Tomas

On Tue, Jun 21, 2016 at 5:19 AM, Tom Schindl 
wrote:

> Hi,
>
> I was playing around with Java9 a bit yesterday things worked fine but
> what disturbs me a bit is that I need to export the package with my
> Application-Subclass because naturally Java9 can not create an instance
> of none-exported class with reflection.
>
> Although not being a big problem it disturbed me a bit and from my basic
> understanding I think it should be possible to introduce a 3rd variant
> of Application.launch() who looks like this:
>
> Application#launch(Application,String...)
>
> This way no reflection is needed by the jfx bootstrap code.
>
> Tom
>
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: Looking forward to JavaFX 9!

[Tomas Mikula]

Felix,

I'm sure the JavaFX engineers are the first ones who wish that Oracle
invested more resources in JavaFX. Therefore I'm afraid that the anger is
targeted at the wrong crowd here.

Tomas

On Tue, Jun 14, 2016 at 8:52 AM, Felix Bembrick 
wrote:

> OK, I have learned my lesson - I will be careful to be strictly on-topic
> and very well behaved in this post.
>
> So, I would simply request if someone could please provide a complete list
> of all the NEW features that are either planned or possibly going to be
> included in JavaFX 9.
>
> Being totally committed to this awesome toolkit, it's obvious that I am
> extremely excited about all the amazing new features that ISVs like us will
> soon be able to use to produce world class software! I can't wait!
>
> Obviously, WebGL is a given as are programmable shaders and they will most
> certainly be very valuable. Naturally TableView will be completely
> rewritten, a 3D Canvas is a must and it goes without saying that the
> rendering pipeline will also be totally scrapped and rebuilt to use the GPU
> and actually be made performant enough to move more than 2 or 3 nodes
> around the screen at once.
>
> I am even clinging on to the slim hope that my lifelong goal of writing a
> modern version of Pong (which I will call Smell) will finally be possible
> with JavaFX.
>
> Clearly JavaFX 9 will "just work" out of the box on iOS, Android and VIC
> 20.
>
> I am sure I don't even need to mention the features everyone is already
> aware of like  official high performance versions for embedded devices and
> the IoT.
>
> Obviously a game engine will be included along with an advanced physics
> engine and built-in support for monetisation on all those mobile platforms
> it will run on.
>
> And It goes without saying that not every method in every class will be
> marked final (finally).
>
> The features I am looking forward to the most though are of course the
> JavaFX Asset Store, the animation editor and, especially the highly
> anticipated JavaFX Watch.
>
> But other than these features which most people already know about, what
> are all the other new exciting features?
>
> I know everyone is busy so how about you just rank the top 100 and we can
> do our homework to identify the 500 or so..
>
> Anyway, congratulations to Oracle executives for really getting behind
> their flagship product and investing the millions of dollars it has taken
> to make such awesome features possible.
>
> I am sure I speak on behalf of the entire JavaFX community in thanking you
> all for this devotion and enthusiasm and I want you to know just how
> incredibly excited we all are about this extremely significant next release
> and its ability to change the world of software forever!
>
> Humbly and sincerely,
>
> Felix
>
>

Re: Handling Enter key presses on Buttons in JavaFX

[Tomas Mikula]

On Tue, Jun 7, 2016 at 7:08 PM, Michael Berry  wrote:

> On 7 June 2016 at 23:57, Tomas Mikula  wrote:
>
>>
>>
>> On Tue, Jun 7, 2016 at 6:48 PM, Michael Berry  wrote:
>>
>>> On 7 June 2016 at 23:30, Tomas Mikula  wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jun 7, 2016 at 6:10 PM, Michael Berry 
>>>> wrote:
>>>>
>>>>> On 7 June 2016 at 23:04, Tomas Mikula  wrote:
>>>>>
>>>>>> What about forgetting the whole notion of a "default button" and the
>>>>>> only
>>>>>> effect of setting the default property to true being that the button
>>>>>> will
>>>>>> start as focused?
>>>>>>
>>>>>> So I add a question:
>>>>>>
>>>>>> 3) Would anyone miss the "default button"?
>>>>>>
>>>>>
>>>>> Afraid I would - I find the visual difference of the default button
>>>>> rather useful.
>>>>>
>>>>
>>>> The visual difference is also what is confusing when there is also a
>>>> focused button. Maybe they should then lose its visual distinction when a
>>>> different button is focused (at least in Jonathan's point 2) - non-OS
>>>> X platforms).
>>>>
>>>
>>> Perhaps this is just a pure difference of opinion - I find the visual
>>> distinction helpful because it provides a cue (from a UX perspective) as to
>>> which button the user can be expected to hit in "normal" behaviour. This,
>>> in my mind, is very different from the (much more subtle) cue that shows
>>> the currently focused UI component.
>>>
>>
>> If Jonathan's plan is executed:
>>
>> > 2) On non-OS X platforms, we change the behavior so that Enter (and
>> Space) will fire the _focused_ key, if one is focused.
>>
>> then any visual cues on the "default" button are misleading (while a
>> different button is focused, that is), since it will not be triggered on
>> either Enter or Space.
>>
>
> Not necessarily. You're assuming (rightly or wrongly) that the visual cue
> here creates the expectation that a particular key, either enter or space,
> should activate it.
>

That was my assumption, indeed. And I wonder how many users make the same
assumption.


>
> In my case, the visual cue simply indicates that it is the preferred,
> default, or most common option for a user to press, without implying a
> relation to any particular hotkey.
>
>
>>
>> Tomas
>>
>>
>>>
>>>
>>>>
>>>> Tomas
>>>>
>>>>
>>>>> While it would be possible to just use CSS to style it differently,
>>>>> this (in my mind) would be a step backwards (and that's before the issues
>>>>> that would arise from a backwards-compatibility standpoint due to removing
>>>>> an existing property.)
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>>
>>>>>> Tomas
>>>>>>
>>>>>> On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles <
>>>>>> jonathan.gi...@oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Hi all,
>>>>>> >
>>>>>> > One thing I've been looking into recently is the issue of what the
>>>>>> Enter
>>>>>> > key should do when it is pushed with regards to buttons in a UI
>>>>>> where one
>>>>>> > of those buttons is a 'default' button. There are number of Jira
>>>>>> issues on
>>>>>> > this topic, and I wanted to poll the community to understand its
>>>>>> opinions.
>>>>>> >
>>>>>> > The current situation is that the Enter key does not fire the
>>>>>> focused
>>>>>> > Button. The Enter key is reserved for firing the 'default' Button
>>>>>> in the UI
>>>>>> > (i.e. if someone has created a Button instance with the default
>>>>>> property
>>>>>> > set to true). A default button is rendered slightly differently (in
>>>>>> Modena
>>>>>> > it is blue for example). To fire the focused Button, the user must
>>>>>> press
>>>>>> 

Re: Handling Enter key presses on Buttons in JavaFX

[Tomas Mikula]

On Tue, Jun 7, 2016 at 6:48 PM, Michael Berry  wrote:

> On 7 June 2016 at 23:30, Tomas Mikula  wrote:
>
>>
>>
>> On Tue, Jun 7, 2016 at 6:10 PM, Michael Berry  wrote:
>>
>>> On 7 June 2016 at 23:04, Tomas Mikula  wrote:
>>>
>>>> What about forgetting the whole notion of a "default button" and the
>>>> only
>>>> effect of setting the default property to true being that the button
>>>> will
>>>> start as focused?
>>>>
>>>> So I add a question:
>>>>
>>>> 3) Would anyone miss the "default button"?
>>>>
>>>
>>> Afraid I would - I find the visual difference of the default button
>>> rather useful.
>>>
>>
>> The visual difference is also what is confusing when there is also a
>> focused button. Maybe they should then lose its visual distinction when a
>> different button is focused (at least in Jonathan's point 2) - non-OS X
>> platforms).
>>
>
> Perhaps this is just a pure difference of opinion - I find the visual
> distinction helpful because it provides a cue (from a UX perspective) as to
> which button the user can be expected to hit in "normal" behaviour. This,
> in my mind, is very different from the (much more subtle) cue that shows
> the currently focused UI component.
>

If Jonathan's plan is executed:

> 2) On non-OS X platforms, we change the behavior so that Enter (and
Space) will fire the _focused_ key, if one is focused.

then any visual cues on the "default" button are misleading (while a
different button is focused, that is), since it will not be triggered on
either Enter or Space.

Tomas


>
>
>>
>> Tomas
>>
>>
>>> While it would be possible to just use CSS to style it differently, this
>>> (in my mind) would be a step backwards (and that's before the issues that
>>> would arise from a backwards-compatibility standpoint due to removing an
>>> existing property.)
>>>
>>> Michael
>>>
>>>
>>>>
>>>> Tomas
>>>>
>>>> On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles <
>>>> jonathan.gi...@oracle.com>
>>>> wrote:
>>>>
>>>> > Hi all,
>>>> >
>>>> > One thing I've been looking into recently is the issue of what the
>>>> Enter
>>>> > key should do when it is pushed with regards to buttons in a UI where
>>>> one
>>>> > of those buttons is a 'default' button. There are number of Jira
>>>> issues on
>>>> > this topic, and I wanted to poll the community to understand its
>>>> opinions.
>>>> >
>>>> > The current situation is that the Enter key does not fire the focused
>>>> > Button. The Enter key is reserved for firing the 'default' Button in
>>>> the UI
>>>> > (i.e. if someone has created a Button instance with the default
>>>> property
>>>> > set to true). A default button is rendered slightly differently (in
>>>> Modena
>>>> > it is blue for example). To fire the focused Button, the user must
>>>> press
>>>> > the Space key.
>>>> >
>>>> > Tom Schindl filed a bug (JDK-8139510) that is a good example of the
>>>> > 'problem' this creates. In the bug report, a dialog is shown to the
>>>> user.
>>>> > In the dialog is an OK button and a Cancel button. The OK button has
>>>> been
>>>> > made the 'default' button. Regardless of which button has focus, the
>>>> Enter
>>>> > key always fires the OK button. The only way to fire the Cancel
>>>> button is
>>>> > via the Space key. This can be very confusing for users who have
>>>> tabbed
>>>> > specifically to the 'Cancel' button and then pressed the Enter key,
>>>> only to
>>>> > find they unwittingly fired the 'OK' action.
>>>> >
>>>> > To me this has always been a little counter-intuitive, because of my
>>>> > heritage as a long-time Windows user. I believe Linux is much the
>>>> same as
>>>> > Windows. For others who grew up on Mac, I'm less sure on what people
>>>> expect
>>>> > (but it seems to be that the Enter key fires the default button, not
>>>> the
>>>> > focused button, i.e.

Re: Handling Enter key presses on Buttons in JavaFX

[Tomas Mikula]

On Tue, Jun 7, 2016 at 6:33 PM, Stefan Fuchs  wrote:

> Hi,
>
> well, if my dialog would include  a TextField, an cancel- and an
> ok-button, I would obviously want to have the TextField the initial focus.
>
> Once the dialog opens I can immediately type some text.
> When I'm done, I hit enter to confirm the dialog.
> To cancel the dialog i would hit escape.
>
> Therefor I would prefer the following behavior.
>
> If the focused control has an action handler attached (cancel-Button and
> ok-Button), enter should trigger its action.
> If the focused control has no action handler attached (TextField), the
> action of the default button should be triggered.
>

This would be very confusing if you had two TextFields and after entering
text into the first one the user hits Enter and the form gets submitted
with empty second field.


> Escape always triggers the action of the cancel-Button.
>
> Stefan
>
>
>
> What about forgetting the whole notion of a "default button" and the only
>> effect of setting the default property to true being that the button will
>> start as focused?
>>
>> So I add a question:
>>
>> 3) Would anyone miss the "default button"?
>>
>> Tomas
>>
>> On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles > >
>> wrote:
>>
>> Hi all,
>>>
>>> One thing I've been looking into recently is the issue of what the Enter
>>> key should do when it is pushed with regards to buttons in a UI where one
>>> of those buttons is a 'default' button. There are number of Jira issues
>>> on
>>> this topic, and I wanted to poll the community to understand its
>>> opinions.
>>>
>>> The current situation is that the Enter key does not fire the focused
>>> Button. The Enter key is reserved for firing the 'default' Button in the
>>> UI
>>> (i.e. if someone has created a Button instance with the default property
>>> set to true). A default button is rendered slightly differently (in
>>> Modena
>>> it is blue for example). To fire the focused Button, the user must press
>>> the Space key.
>>>
>>> Tom Schindl filed a bug (JDK-8139510) that is a good example of the
>>> 'problem' this creates. In the bug report, a dialog is shown to the user.
>>> In the dialog is an OK button and a Cancel button. The OK button has been
>>> made the 'default' button. Regardless of which button has focus, the
>>> Enter
>>> key always fires the OK button. The only way to fire the Cancel button is
>>> via the Space key. This can be very confusing for users who have tabbed
>>> specifically to the 'Cancel' button and then pressed the Enter key, only
>>> to
>>> find they unwittingly fired the 'OK' action.
>>>
>>> To me this has always been a little counter-intuitive, because of my
>>> heritage as a long-time Windows user. I believe Linux is much the same as
>>> Windows. For others who grew up on Mac, I'm less sure on what people
>>> expect
>>> (but it seems to be that the Enter key fires the default button, not the
>>> focused button, i.e. JavaFX current behavior matches what is expected on
>>> OS
>>> X).
>>>
>>> What I'm proposing we do is to change the behavior as follows:
>>>
>>> 1) On OS X we do not change behavior at all - we keep the current 'Enter
>>> means default' and 'Space means focus' semantics.
>>>
>>> 2) On non-OS X platforms, we change the behavior so that Enter (and
>>> Space)
>>> will fire the _focused_ key, if one is focused. If no Button is focused
>>> (e.g. focus is in a TextField, etc), then Enter will work as it currently
>>> does and fire the default button, if one is specified. In short, default
>>> buttons will still be rendered blue to hint to the user that they are the
>>> default button, but they will be less prevalently fired by Enter key
>>> presses - only when they also have focus.
>>>
>>> The two questions that I have are:
>>>
>>> 1) Will this confuse users when there is a behavior change (and
>>> presumably, this change will be made in JDK 9 and not backported to JDK
>>> 8).
>>> If it will confuse users, is it still the right thing to do?
>>>
>>> 2) Do we want to have different behaviors for OS X and non-OS X? I'm a
>>> newly inducted member into the cult of Mac, and I don't yet have all my
>>> bearings sorted out, so I don't have a strong opinion here.
>>>
>>> Your thoughts, as always, are appreciated.
>>> -- Jonathan
>>>
>>>
>

Re: Handling Enter key presses on Buttons in JavaFX

[Tomas Mikula]

On Tue, Jun 7, 2016 at 6:10 PM, Michael Berry  wrote:

> On 7 June 2016 at 23:04, Tomas Mikula  wrote:
>
>> What about forgetting the whole notion of a "default button" and the only
>> effect of setting the default property to true being that the button will
>> start as focused?
>>
>> So I add a question:
>>
>> 3) Would anyone miss the "default button"?
>>
>
> Afraid I would - I find the visual difference of the default button rather
> useful.
>

The visual difference is also what is confusing when there is also a
focused button. Maybe they should then lose its visual distinction when a
different button is focused (at least in Jonathan's point 2) - non-OS X
platforms).

Tomas


> While it would be possible to just use CSS to style it differently, this
> (in my mind) would be a step backwards (and that's before the issues that
> would arise from a backwards-compatibility standpoint due to removing an
> existing property.)
>
> Michael
>
>
>>
>> Tomas
>>
>> On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles > >
>> wrote:
>>
>> > Hi all,
>> >
>> > One thing I've been looking into recently is the issue of what the Enter
>> > key should do when it is pushed with regards to buttons in a UI where
>> one
>> > of those buttons is a 'default' button. There are number of Jira issues
>> on
>> > this topic, and I wanted to poll the community to understand its
>> opinions.
>> >
>> > The current situation is that the Enter key does not fire the focused
>> > Button. The Enter key is reserved for firing the 'default' Button in
>> the UI
>> > (i.e. if someone has created a Button instance with the default property
>> > set to true). A default button is rendered slightly differently (in
>> Modena
>> > it is blue for example). To fire the focused Button, the user must press
>> > the Space key.
>> >
>> > Tom Schindl filed a bug (JDK-8139510) that is a good example of the
>> > 'problem' this creates. In the bug report, a dialog is shown to the
>> user.
>> > In the dialog is an OK button and a Cancel button. The OK button has
>> been
>> > made the 'default' button. Regardless of which button has focus, the
>> Enter
>> > key always fires the OK button. The only way to fire the Cancel button
>> is
>> > via the Space key. This can be very confusing for users who have tabbed
>> > specifically to the 'Cancel' button and then pressed the Enter key,
>> only to
>> > find they unwittingly fired the 'OK' action.
>> >
>> > To me this has always been a little counter-intuitive, because of my
>> > heritage as a long-time Windows user. I believe Linux is much the same
>> as
>> > Windows. For others who grew up on Mac, I'm less sure on what people
>> expect
>> > (but it seems to be that the Enter key fires the default button, not the
>> > focused button, i.e. JavaFX current behavior matches what is expected
>> on OS
>> > X).
>> >
>> > What I'm proposing we do is to change the behavior as follows:
>> >
>> > 1) On OS X we do not change behavior at all - we keep the current 'Enter
>> > means default' and 'Space means focus' semantics.
>> >
>> > 2) On non-OS X platforms, we change the behavior so that Enter (and
>> Space)
>> > will fire the _focused_ key, if one is focused. If no Button is focused
>> > (e.g. focus is in a TextField, etc), then Enter will work as it
>> currently
>> > does and fire the default button, if one is specified. In short, default
>> > buttons will still be rendered blue to hint to the user that they are
>> the
>> > default button, but they will be less prevalently fired by Enter key
>> > presses - only when they also have focus.
>> >
>> > The two questions that I have are:
>> >
>> > 1) Will this confuse users when there is a behavior change (and
>> > presumably, this change will be made in JDK 9 and not backported to JDK
>> 8).
>> > If it will confuse users, is it still the right thing to do?
>> >
>> > 2) Do we want to have different behaviors for OS X and non-OS X? I'm a
>> > newly inducted member into the cult of Mac, and I don't yet have all my
>> > bearings sorted out, so I don't have a strong opinion here.
>> >
>> > Your thoughts, as always, are appreciated.
>> > -- Jonathan
>> >
>>
>
>
>
> --
> Thanks,
>
> Michael
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_-3404683945119215455_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Handling Enter key presses on Buttons in JavaFX

[Tomas Mikula]

What about forgetting the whole notion of a "default button" and the only
effect of setting the default property to true being that the button will
start as focused?

So I add a question:

3) Would anyone miss the "default button"?

Tomas

On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles 
wrote:

> Hi all,
>
> One thing I've been looking into recently is the issue of what the Enter
> key should do when it is pushed with regards to buttons in a UI where one
> of those buttons is a 'default' button. There are number of Jira issues on
> this topic, and I wanted to poll the community to understand its opinions.
>
> The current situation is that the Enter key does not fire the focused
> Button. The Enter key is reserved for firing the 'default' Button in the UI
> (i.e. if someone has created a Button instance with the default property
> set to true). A default button is rendered slightly differently (in Modena
> it is blue for example). To fire the focused Button, the user must press
> the Space key.
>
> Tom Schindl filed a bug (JDK-8139510) that is a good example of the
> 'problem' this creates. In the bug report, a dialog is shown to the user.
> In the dialog is an OK button and a Cancel button. The OK button has been
> made the 'default' button. Regardless of which button has focus, the Enter
> key always fires the OK button. The only way to fire the Cancel button is
> via the Space key. This can be very confusing for users who have tabbed
> specifically to the 'Cancel' button and then pressed the Enter key, only to
> find they unwittingly fired the 'OK' action.
>
> To me this has always been a little counter-intuitive, because of my
> heritage as a long-time Windows user. I believe Linux is much the same as
> Windows. For others who grew up on Mac, I'm less sure on what people expect
> (but it seems to be that the Enter key fires the default button, not the
> focused button, i.e. JavaFX current behavior matches what is expected on OS
> X).
>
> What I'm proposing we do is to change the behavior as follows:
>
> 1) On OS X we do not change behavior at all - we keep the current 'Enter
> means default' and 'Space means focus' semantics.
>
> 2) On non-OS X platforms, we change the behavior so that Enter (and Space)
> will fire the _focused_ key, if one is focused. If no Button is focused
> (e.g. focus is in a TextField, etc), then Enter will work as it currently
> does and fire the default button, if one is specified. In short, default
> buttons will still be rendered blue to hint to the user that they are the
> default button, but they will be less prevalently fired by Enter key
> presses - only when they also have focus.
>
> The two questions that I have are:
>
> 1) Will this confuse users when there is a behavior change (and
> presumably, this change will be made in JDK 9 and not backported to JDK 8).
> If it will confuse users, is it still the right thing to do?
>
> 2) Do we want to have different behaviors for OS X and non-OS X? I'm a
> newly inducted member into the cult of Mac, and I don't yet have all my
> bearings sorted out, so I don't have a strong opinion here.
>
> Your thoughts, as always, are appreciated.
> -- Jonathan
>

Re: FX-9: Plans for InputMap?

[Tomas Mikula]

Hi Jeanette,

before reimplementing the whole thing, please check out my writeup of some
use cases [1] and whether WellBehavedFX would serve your needs.

Best,
Tomas

[1]
http://htmlpreview.github.io/?https://github.com/TomasMikula/InputMapAPI/blob/master/use-cases.html

On Fri, Mar 18, 2016 at 5:45 AM,  wrote:

>
> when experimenting with custom (or extended) skins, I noticed that I can
> barely live without InputMap. If I had to, I would end up in
> re-implementing the whole thingy.
>
> What are the chances for moving it into public scope?
>
> Cheers
> Jeanette
>
>

Re: Future of JavaFX

[Tomas Mikula]

The proposed strategy also applies to bitbucket, which does have mercurial
support ;)

On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG  wrote:

> Too bad that Github cannot fork mercurial repos. It would be interesting
> to see the real number of pull requests such a fork would gain. Maybe
> Dalibor is right and we would end up with zero? ;-)
>
> -Markus
>
>
>
> From: Tomas Mikula [mailto:tomas.mik...@gmail.com]
> Sent: Dienstag, 1. Dezember 2015 23:05
> To: Markus KARG
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Future of JavaFX
>
>
>
> The review process for external contributions does not even have to be
> different from the internal review process. There can be a virtual
> organization on GitHub called "Oracle CLA signatories". After a pull
> request has been reviewed, all that the OpenJFX committer has to do before
> merging is to check whether the contributor is a member of this
> organization.
>
>
>
> Tomas
>
>
>
> On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG 
> wrote:
>
> We should ask ourselfs whether we want more contributions or not. We will
> not get them until we change something. Most contributors in the Open
> Source just want to drop a bug report or a feature or two, and multiplied
> by the number of those guys, this is a lot of stuff. Only few contributors
> are willing to stay for long time, and only for those it makes sense to
> have the complex rules. For example, I do not see why we cannot have a
> dedicated full time "Community Officer" who simply collects the
> contributions, reviews it, applies the needed checks and rules and all that
> instead of asking everybody to follow a complex process? That would ensure
> the quality, but not for the cost of losing contributors.
>
>
> -Original Message-
> From: Hervé Girod [mailto:herve.gi...@gmail.com]
> Sent: Dienstag, 1. Dezember 2015 20:19
> To: Markus KARG
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Future of JavaFX
>
> Things are not different for Apache projects. Google does not accept any
> external contributions. The Linux kernel development is very tightly
> controlled. We should stop considering that widespread open source policies
> are only a problem with JavaFX. These policies are in place for a reason.
>
> Hervé
>
> Sent from my iPhone
>
> > On Dec 1, 2015, at 20:13, Markus KARG  wrote:
> >
> > I wonder why I was able to jointly assign my copyright with a lot of
> other
> > open source projects without having to sign papers, sent them in by fax,
> > wait for a written agreement, and pray to get a JIRA account... ;-)
> >
> > See, I talked to a real lot of former JavaFX contributors in the past
> weeks
> > (visited some European JUGs in 2015), and *virtually everybody* told me
> that
> > he is really unsatisfied with the fact that he cannot directly file to
> JIRA
> > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX
> team
> > clear about how many contributors you lost by that policy? I really
> wonder
> > whether you see the reality there outside of Oracle. People stopped
> > reporting bugs! This is a real problem for JavaFX. You should act. Now.
> >
> > -Markus
> >
> >
> >
> > -Original Message-
> > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
> Behalf Of
> > dalibor topic
> > Sent: Dienstag, 1. Dezember 2015 19:06
> > To: openjfx-dev@openjdk.java.net
> > Subject: Re: Future of JavaFX
> >
> >> On 01.12.2015 18:35, Markus KARG wrote:
> >> With respect to TeamFX, the better question is: Are there plans to
> further
> >> open the project so third party has an easier channel to contribute
> > without
> >> the hazzle of contributor agreements
> >
> > "Like many other open-source communities, the OpenJDK Community requires
> > Contributors to jointly assign their copyright on contributed code." as
> > http://openjdk.java.net/contribute/ wisely says.
> >
> > There is no good reason to change that.
> >
> > cheers,
> > dalibor topic
> > --
> > <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> > Phone: +494089091214 > | Mobile: +491737185961 
> >  >
> >
> > ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> >
> > ORACLE Deutschland B.V. & Co. KG
> > Hauptverwaltung: Riesstr. 25, D-80992 München
> > Registergericht: Amtsgericht München, HRA 95603
> >
> > Komplementärin: ORACLE Deutschland Verwaltung B.V.
> > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> > Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> >
> > <http://www.oracle.com/commitment> Oracle is committed to developing
> > practices and products that help protect the environment
> >
>
>
>
>

Re: Future of JavaFX

[Tomas Mikula]

The review process for external contributions does not even have to be
different from the internal review process. There can be a virtual
organization on GitHub called "Oracle CLA signatories". After a pull
request has been reviewed, all that the OpenJFX committer has to do before
merging is to check whether the contributor is a member of this
organization.

Tomas

On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG  wrote:

> We should ask ourselfs whether we want more contributions or not. We will
> not get them until we change something. Most contributors in the Open
> Source just want to drop a bug report or a feature or two, and multiplied
> by the number of those guys, this is a lot of stuff. Only few contributors
> are willing to stay for long time, and only for those it makes sense to
> have the complex rules. For example, I do not see why we cannot have a
> dedicated full time "Community Officer" who simply collects the
> contributions, reviews it, applies the needed checks and rules and all that
> instead of asking everybody to follow a complex process? That would ensure
> the quality, but not for the cost of losing contributors.
>
> -Original Message-
> From: Hervé Girod [mailto:herve.gi...@gmail.com]
> Sent: Dienstag, 1. Dezember 2015 20:19
> To: Markus KARG
> Cc: openjfx-dev@openjdk.java.net
> Subject: Re: Future of JavaFX
>
> Things are not different for Apache projects. Google does not accept any
> external contributions. The Linux kernel development is very tightly
> controlled. We should stop considering that widespread open source policies
> are only a problem with JavaFX. These policies are in place for a reason.
>
> Hervé
>
> Sent from my iPhone
>
> > On Dec 1, 2015, at 20:13, Markus KARG  wrote:
> >
> > I wonder why I was able to jointly assign my copyright with a lot of
> other
> > open source projects without having to sign papers, sent them in by fax,
> > wait for a written agreement, and pray to get a JIRA account... ;-)
> >
> > See, I talked to a real lot of former JavaFX contributors in the past
> weeks
> > (visited some European JUGs in 2015), and *virtually everybody* told me
> that
> > he is really unsatisfied with the fact that he cannot directly file to
> JIRA
> > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX
> team
> > clear about how many contributors you lost by that policy? I really
> wonder
> > whether you see the reality there outside of Oracle. People stopped
> > reporting bugs! This is a real problem for JavaFX. You should act. Now.
> >
> > -Markus
> >
> >
> >
> > -Original Message-
> > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
> Behalf Of
> > dalibor topic
> > Sent: Dienstag, 1. Dezember 2015 19:06
> > To: openjfx-dev@openjdk.java.net
> > Subject: Re: Future of JavaFX
> >
> >> On 01.12.2015 18:35, Markus KARG wrote:
> >> With respect to TeamFX, the better question is: Are there plans to
> further
> >> open the project so third party has an easier channel to contribute
> > without
> >> the hazzle of contributor agreements
> >
> > "Like many other open-source communities, the OpenJDK Community requires
> > Contributors to jointly assign their copyright on contributed code." as
> > http://openjdk.java.net/contribute/ wisely says.
> >
> > There is no good reason to change that.
> >
> > cheers,
> > dalibor topic
> > --
> >  Dalibor Topic | Principal Product Manager
> > Phone: +494089091214  | Mobile: +491737185961
> > 
> >
> > ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> >
> > ORACLE Deutschland B.V. & Co. KG
> > Hauptverwaltung: Riesstr. 25, D-80992 München
> > Registergericht: Amtsgericht München, HRA 95603
> >
> > Komplementärin: ORACLE Deutschland Verwaltung B.V.
> > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> > Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> >
> >  Oracle is committed to developing
> > practices and products that help protect the environment
> >
>
>

Re: Future of JavaFX

[Tomas Mikula]

The fact that there are other projects with equally bad or worse
contribution process does not make the JavaFX's any less bad. Yes, there
should be (strict) policies regarding code quality. The rest of the process
should be as easy as opening a pull request.

Tomas

On Tue, Dec 1, 2015 at 2:18 PM, Hervé Girod  wrote:

> Things are not different for Apache projects. Google does not accept any
> external contributions. The Linux kernel development is very tightly
> controlled. We should stop considering that widespread open source policies
> are only a problem with JavaFX. These policies are in place for a reason.
>
> Hervé
>
> Sent from my iPhone
>
> > On Dec 1, 2015, at 20:13, Markus KARG  wrote:
> >
> > I wonder why I was able to jointly assign my copyright with a lot of
> other
> > open source projects without having to sign papers, sent them in by fax,
> > wait for a written agreement, and pray to get a JIRA account... ;-)
> >
> > See, I talked to a real lot of former JavaFX contributors in the past
> weeks
> > (visited some European JUGs in 2015), and *virtually everybody* told me
> that
> > he is really unsatisfied with the fact that he cannot directly file to
> JIRA
> > anymore or AT LEAST vote and comment on existing tickets. Is the JavaFX
> team
> > clear about how many contributors you lost by that policy? I really
> wonder
> > whether you see the reality there outside of Oracle. People stopped
> > reporting bugs! This is a real problem for JavaFX. You should act. Now.
> >
> > -Markus
> >
> >
> >
> > -Original Message-
> > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
> Behalf Of
> > dalibor topic
> > Sent: Dienstag, 1. Dezember 2015 19:06
> > To: openjfx-dev@openjdk.java.net
> > Subject: Re: Future of JavaFX
> >
> >> On 01.12.2015 18:35, Markus KARG wrote:
> >> With respect to TeamFX, the better question is: Are there plans to
> further
> >> open the project so third party has an easier channel to contribute
> > without
> >> the hazzle of contributor agreements
> >
> > "Like many other open-source communities, the OpenJDK Community requires
> > Contributors to jointly assign their copyright on contributed code." as
> > http://openjdk.java.net/contribute/ wisely says.
> >
> > There is no good reason to change that.
> >
> > cheers,
> > dalibor topic
> > --
> >  Dalibor Topic | Principal Product Manager
> > Phone: +494089091214  | Mobile: +491737185961
> > 
> >
> > ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> >
> > ORACLE Deutschland B.V. & Co. KG
> > Hauptverwaltung: Riesstr. 25, D-80992 München
> > Registergericht: Amtsgericht München, HRA 95603
> >
> > Komplementärin: ORACLE Deutschland Verwaltung B.V.
> > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> > Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> >
> >  Oracle is committed to developing
> > practices and products that help protect the environment
> >
>

Re: Future of JavaFX

[Tomas Mikula]

The same blog post of Shay says that "Oracle never discontinues products."
At least not officially. So there you have that.

Given that the biggest achievement of JavaFX 9 will be if old things keep
working in JDK 9, I wouldn't expect any new exciting JavaFX developments
coming from Oracle.

On Mon, Nov 30, 2015 at 11:13 AM, Dirk @ Google 
wrote:

> Hi there,
>
> there has been quite a shake-up in the JavaFX community last week when
> Shay Almog (Codename One) first responded to a blog of mine (
> dlemmermann.wordpress.com) with a lot of negative comments regarding
> JavaFX and its future. He then followed up with a long blog asking the
> question „Should Oracle Spring-Clean JavaFX“ (
> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html <
> https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>).
>
> I do understand that it is often a good strategy to not comment on stuff
> like this because commenting would just draw attention to it, but we have
> now reached the point where potential customers are questioning the
> sustainability of a JavaFX-based solution. They are now wondering if JavaFX
> will still be around in a few years. In my specific case the customer
> demands an answer from me and my partners within the next week, and if not
> convincing they will go with something / someone else. We will loose a
> contract worth around one million dollars because of one blog written by
> Shay with no follow-up from Oracle.
>
> What is needed is an official statement from Oracle / Oracle employees /
> JavaFX development team, saying that Oracle is still committed to JavaFX
> and that it will still be around for a while. Can somebody please do that?
>
> Dirk
>
>
>

Re: Usage of Toolkit firePulse

[Tomas Mikula]

Hi Michael,

attached see your original file updated with the continuation-style
solution.

Regards,
Tomas

On Thu, Sep 24, 2015 at 2:44 PM, Dr. Michael Paus  wrote:

> I have written a little test program to evaluate the various strategies
> which have
> been discussed here. You can download it via this link:
>
> 
>
> The program creates a large canvas inside a scroll pane and fills it with
> some
> butterflies. When you scroll the pane the canvas is redrawn when a certain
> threshold is exceeded. With some boolean flags at the top of the program
> you can select the redraw strategy.
>
> This was just a quick and dirty hack, so I hope I haven't made any mistakes
> but the result so far is that only the AnimationTimer strategy leads to a
> amazingly
> smooth result. For all other strategies the scrolling performance is
> terrible.
> (I have not yet tried the proposal from Tomas.)
>
> Give it a try yourself. The initial setting are for AnimationTimer.
>
> Michael
>
>
> Am 24.09.15 um 17:17 schrieb Kevin Rushforth:
>
> Yes, I think this might be a better approach.
>>
>> -- Kevin
>>
>>
>> Scott Palmer wrote:
>>
>>> For some of these use cases I wonder if an AnimationTimer could be used
>>> to handle spreading work out.
>>> E.g in the case of rendering to a canvas across multiple pulses, do a
>>> bit at a time in the AnimationTimer’s handle() method.
>>>
>>> Scott
>>>
>>> On Sep 24, 2015, at 5:53 AM, Fisher, Robert 
 wrote:

 I was naively thinking something like:

 1. Make small change to canvas
 2. Fire pulse
 3. Make next small change to canvas
 4. Fire pulse
 5. Etc..

 But I was actually also unaware of this firePulse method until this
 morning (and I couldn't have used it anyway since it's not public API).

 -Original Message-
 From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
 Behalf Of Dr. Michael Paus
 Sent: Donnerstag, 24. September 2015 11:07
 To: openjfx-dev@openjdk.java.net
 Subject: Re: Usage of Toolkit firePulse

 Hi,
 I wasn't aware of this Toolkit method when I wrote the mail you are
 referring to. Can you or anybody else explain what this method exactly
 does. It sounds indeed as if I could solve some problems with it although I
 am not sure yet and of course only if Jonathan does not block it in the
 future :-) Michael

 Am 24.09.15 um 09:31 schrieb Fisher, Robert:

> I think it would be great to have in the public API. It looks like it
> would allow you to spread large UI updates out over several pulses in a
> well-defined way.
>
> See also this post from a month or so ago:
>
> Hi,
>> I want to do some performance tuning of a JavaFX application of mine
>> but before I can start with that I have to learn a little bit about the
>> scene graph redraw handling.
>> Maybe there is someone on this list who can help me there.
>>
>> What I want to achieve is a super smooth animation (movement) of my
>> scene graph.
>> Let's assume the scene graph itself can be redrawn fast enough in
>> less than 1/60s.
>> In addition let's assume the scene graph contains a canvas which only
>> has to be updated from time to time but an update of the canvas takes
>> substantially longer.
>> Let's say it takes 1s.
>>
>> When an update of the canvas is in progress will this delay the next
>> pulse until all internal drawing within the canvas is finished? From my
>> observations I think so.
>>
>> If I submit my drawing calls to the canvas in smaller chunks via
>> Platform.runLater calls will these also delay the next pulse or will the
>> execution of these calls be delayed in favor of the scene graph update?
>>
>> I hope my goal has become clear. I would like to be able to spread
>> the update of the canvas over several scene graph redraw cycles so that 
>> an
>> animation of the canvas stays smooth although the content builds up more
>> slowly.
>>
>> Michael
>>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
> Behalf Of Jonathan Giles
> Sent: Donnerstag, 24. September 2015 01:49
> To: openjfx-dev@openjdk.java.net
> Subject: Usage of Toolkit firePulse
>
> Hi all,
>
> Today I am keen to get your help on understanding use of the
> Toolkit.getToolkit().firePulse() private API. If you could spare a few
> minutes to grep your source directory for any usage of 'firePulse', and
> email me your findings, that would be really interesting.
>
> As a gentle motivational tool I'll conclude by saying that,
> surprisingly, this private API is barely used inside the openjfx 
> production
> code. If you look at the openjfx unit tests, it is used massively. The
>>>

Re: Usage of Toolkit firePulse

[Tomas Mikula]

I think using Platform.runLater to schedule chunks of work should work.
However, dumping all chunks to the event queue at once will likely delay
the next pulse and event processing. Using the continuation style, where
each chunk schedules the next one, should work IMO.

interface Continuation {
abstract Optional step();

static void schedule(Continuation work) {
Platform.runLater(() -> {
work.step().ifPresent(Continuation::schedule);
});
}
}

Now you "just" need to implement your work as the above Continuation
interface, which might be a little tricky, but feasible.

Keep in mind that if your chunks are interspersed with other events, those
events might, in general, interfere with what you set out to do in an
upcoming chunk. (For example, if a chunk was going to add an item to a list
at position 8, but before that chunk was executed, some event caused the
list to shrink to size 5, you will get an IOOBE.)

Regards,
Tomas

On Thu, Sep 24, 2015 at 9:48 AM, Dr. Michael Paus  wrote:

> I also thought about using an AnimationTimer but I see a problem with the
> load balancing there.
> If you do too much in the handle() method, then the pulses will be delayed
> but if you do not do enough,
> your canvas update is unnecessarily stretched and you are wasting time.
> You would have a similar
> problem with the firePulse() method.
>
> Am 24.09.15 um 15:13 schrieb Scott Palmer:
>
> For some of these use cases I wonder if an AnimationTimer could be used to
>> handle spreading work out.
>> E.g in the case of rendering to a canvas across multiple pulses, do a bit
>> at a time in the AnimationTimer’s handle() method.
>>
>> Scott
>>
>> On Sep 24, 2015, at 5:53 AM, Fisher, Robert 
>>> wrote:
>>>
>>> I was naively thinking something like:
>>>
>>> 1. Make small change to canvas
>>> 2. Fire pulse
>>> 3. Make next small change to canvas
>>> 4. Fire pulse
>>> 5. Etc..
>>>
>>> But I was actually also unaware of this firePulse method until this
>>> morning (and I couldn't have used it anyway since it's not public API).
>>>
>>> -Original Message-
>>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
>>> Behalf Of Dr. Michael Paus
>>> Sent: Donnerstag, 24. September 2015 11:07
>>> To: openjfx-dev@openjdk.java.net
>>> Subject: Re: Usage of Toolkit firePulse
>>>
>>> Hi,
>>> I wasn't aware of this Toolkit method when I wrote the mail you are
>>> referring to. Can you or anybody else explain what this method exactly
>>> does. It sounds indeed as if I could solve some problems with it although I
>>> am not sure yet and of course only if Jonathan does not block it in the
>>> future :-) Michael
>>>
>>> Am 24.09.15 um 09:31 schrieb Fisher, Robert:
>>>
 I think it would be great to have in the public API. It looks like it
 would allow you to spread large UI updates out over several pulses in a
 well-defined way.

 See also this post from a month or so ago:

 Hi,
> I want to do some performance tuning of a JavaFX application of mine
> but before I can start with that I have to learn a little bit about
> the scene graph redraw handling.
> Maybe there is someone on this list who can help me there.
>
> What I want to achieve is a super smooth animation (movement) of my
> scene graph.
> Let's assume the scene graph itself can be redrawn fast enough in less
> than 1/60s.
> In addition let's assume the scene graph contains a canvas which only
> has to be updated from time to time but an update of the canvas takes
> substantially longer.
> Let's say it takes 1s.
>
> When an update of the canvas is in progress will this delay the next
> pulse until all internal drawing within the canvas is finished? From
> my observations I think so.
>
> If I submit my drawing calls to the canvas in smaller chunks via
> Platform.runLater calls will these also delay the next pulse or will
> the execution of these calls be delayed in favor of the scene graph
> update?
>
> I hope my goal has become clear. I would like to be able to spread
> the update of the canvas over several scene graph redraw cycles so
> that an animation of the canvas stays smooth although the content
> builds up more slowly.
>
> Michael
>
 -Original Message-
 From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
 Behalf Of Jonathan Giles
 Sent: Donnerstag, 24. September 2015 01:49
 To: openjfx-dev@openjdk.java.net
 Subject: Usage of Toolkit firePulse

 Hi all,

 Today I am keen to get your help on understanding use of the
 Toolkit.getToolkit().firePulse() private API. If you could spare a few
 minutes to grep your source directory for any usage of 'firePulse', and
 email me your findings, that would be really interesting.

 As a gentle motivational tool I'll conclude by saying 

Re: JEP 253: UI control skins and input mapping discussion

[Tomas Mikula]

Hi all,

it seems that after dropping input mapping API from JEP 253, Jonathan has
for now retracted from further work on this API. I nevertheless compiled a
list of some use cases and presented how they can be solved using
WellBehavedFX. I would like to invite anyone to supply other use cases and
comment on the current use cases, the presented solutions and the proposed
API.

https://github.com/TomasMikula/InputMapAPI

Thanks,
Tomas

On Wed, Aug 19, 2015 at 9:09 PM, Tomas Mikula 
wrote:

>
>
> On Wed, Aug 19, 2015 at 8:15 PM, Jonathan Giles  > wrote:
>
>> Tomas, I hope you'll agree that throughout our long discussion on JBS we
>> both improved our implementations based on our discussion. To say that I
>> haven't addressed your issues isn't fair - I worked with you to understand
>> your issues and I addressed many of them as my InputMap implementation and
>> API iterated. We have fundamentally different views on how to implement
>> this, so I can't bend over and completely change my approach to your
>> approach - or else we'd not be doing a proper job of exploring the domain.
>
>
> I never meant it to sound like you (or JavaFX) should adopt my approach. I
> was just pointing out some flaws with the proposal, and in an attempt to
> also be constructive, I was referring to WellBehavedFX as an evidence that
> they indeed can be resolved.
>
>
>> I'm not saying one approach is right and the other is wrong - I'm working
>> on my idea of how to approach this, and as I said, I invite you to do the
>> same. In regard to 'closing doors' - I don't think anything I've done up to
>> now has closed doors. I believe that WellBehavedFX will continue to be able
>> to work in the current approach I have implemented (it just hooks into
>> EventHandlers, right?) - it just won't make use of any of it!
>
>
> By the same argument, neither is JavaFX closing doors to anyone who wants
> to implement their own UI toolkit. They just won't make use of any of it!
> :D More seriously though, no, the two mechanisms cannot coexist well on the
> same control: they both hook into event handlers and 1) the order in which
> event handlers are invoked is undefined and 2) all applicable event
> handlers are invoked, regardless of whether some of them consumed the
> event. In fact, if there was enough control over event handlers, there
> would be little motivation for any of this input mapping stuff. Since there
> can only be one mechanism in place, it better cover 99.99% of use cases.
>
>
>> Nothing I'm creating is being forced down anyones throats - it is an
>> implementation and API that is optional. As it stands, the sandbox repo I'm
>> working in has all controls using it, but that doesn't mean controls such
>> as your rich text editor are forced to use it, and I imagine that they will
>> continue to work well with your WellBehavedFX API and implementation. Am I
>> misunderstanding what you're saying? -- Jonathan
>
>
> If my control uses WellBehavedFX, and in JDK 9 there will be the new
> InputMap API, users (especially new ones) will try to use that API to
> customize input mappings (because, well, that is the JavaFX way to do it,
> right?). Except the two can interact in unpredictable ways (see above). Now
> if you say that they should study the control and the ways how to interact
> with it, that argument does not extend to generic code, where the type of
> node is known to be only Control (or Node), not the concrete custom
> control. So custom control authors will be forced to switch to the new API.
> So again, it better cover 99.99% of use cases.
>
> Regards,
> Tomas
>
>

Re: JEP 253 webrev ready for review

[Tomas Mikula]

Let me comment on the examples you picked.


The 1st and 2nd rely on the default skin being used (they lookup a node
based on style class and then cast it to the expected type). This code
would not work with a custom skin.


The 3rd and 5th actually don't need skin implementations to be public,
since they are just setting a default skin. So instead of

control.setSkin(new DefaultSkinImplementation(control));

they could as well do

control.setSkin(control.createDefaultSkin());


Number 4 seems like a legit reuse and customization of the default skin.
Too bad it still needs to do reflection to access its private field, thus
even though it keeps working for now, it can break without warning in the
future.


I now see that making skins public averts the disaster, but the code that
was problematic before stays problematic.


Regards,
Tomas

On Thu, Sep 3, 2015 at 11:03 PM, Jonathan Giles 
wrote:

> Tomas,
>
> The webrev has a few examples of how skins being public will help. There
> are many more of such cases when you take into account the large number of
> projects I surveyed, but I just picked out the first few from this webrev
> for Scene Builder. The short answer is: if skins aren't public, these
> classes wouldn't compile in JDK 9.
>
> Examples include:
>
>
> http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/content/driver/TableViewDesignInfoX.java.sdiff.html
>
>
> http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/panel/content/driver/TreeTableViewDesignInfoX.java.sdiff.html
>
>
> http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/apps/experiments/ConferenceScheduleApp/src/main/java/com/javafx/experiments/scheduleapp/control/PopoverTreeList.java.sdiff.html
>
>
> http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/apps/experiments/ConferenceScheduleApp/src/main/java/com/javafx/experiments/scheduleapp/control/ScrollPaneSkin3.java.sdiff.html
>
>
> http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/apps/experiments/ConferenceScheduleApp/src/main/java/com/javafx/experiments/scheduleapp/control/SearchBox.java.sdiff.html
>
> -- Jonathan
>
> On 4/09/2015 2:55 p.m., Tomas Mikula wrote:
>
> Hi Jonathan,
>
> regarding skins, while I don't see anything immediately wrong with the
> published API, I have trouble seeing how making skin implementations public
> is going to be useful. In particular, the JEP states that one of the
> success metrics is
>
> Projects that depend on JavaFX internal APIs, in particular Scene Builder,
>> ControlsFX, and JFXtras, continue to work after updating to the new API
>> with no loss of functionality.
>
>
> Can you, or someone else from those projects, give a concrete example how
> making skins public will help?
>
> Best,
> Tomas
>
> On Thu, Sep 3, 2015 at 9:17 PM, Jonathan Giles 
> wrote:
>
>> Hi folks.
>>
>> For those of you interested in JEP 253 we've got some light weekend
>> reading lined up for you. We are at a point where the JEP is basically
>> ready to merge back into a mainline (public) repo, and out of its sandbox.
>> Before we do that, we want any additional feedback from the community, if
>> there is any remaining. The two links you'll want to peruse are as follows:
>>
>> JavaDocs: http://jonathangiles.net/javafx/jdk9/jep253/7/
>> Webrev: http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/
>>
>> Thanks,
>> -- Jonathan
>>
>
>
>

Re: JEP 253 webrev ready for review

[Tomas Mikula]

Hi Jonathan,

regarding skins, while I don't see anything immediately wrong with the
published API, I have trouble seeing how making skin implementations public
is going to be useful. In particular, the JEP states that one of the
success metrics is

Projects that depend on JavaFX internal APIs, in particular Scene Builder,
> ControlsFX, and JFXtras, continue to work after updating to the new API
> with no loss of functionality.


Can you, or someone else from those projects, give a concrete example how
making skins public will help?

Best,
Tomas

On Thu, Sep 3, 2015 at 9:17 PM, Jonathan Giles 
wrote:

> Hi folks.
>
> For those of you interested in JEP 253 we've got some light weekend
> reading lined up for you. We are at a point where the JEP is basically
> ready to merge back into a mainline (public) repo, and out of its sandbox.
> Before we do that, we want any additional feedback from the community, if
> there is any remaining. The two links you'll want to peruse are as follows:
>
> JavaDocs: http://jonathangiles.net/javafx/jdk9/jep253/7/
> Webrev: http://cr.openjdk.java.net/~kcr/jep-253/webrev.00/
>
> Thanks,
> -- Jonathan
>

Re: JEP 253: UI control skins and input mapping discussion

[Tomas Mikula]

On Wed, Aug 19, 2015 at 8:15 PM, Jonathan Giles 
wrote:

> Tomas, I hope you'll agree that throughout our long discussion on JBS we
> both improved our implementations based on our discussion. To say that I
> haven't addressed your issues isn't fair - I worked with you to understand
> your issues and I addressed many of them as my InputMap implementation and
> API iterated. We have fundamentally different views on how to implement
> this, so I can't bend over and completely change my approach to your
> approach - or else we'd not be doing a proper job of exploring the domain.


I never meant it to sound like you (or JavaFX) should adopt my approach. I
was just pointing out some flaws with the proposal, and in an attempt to
also be constructive, I was referring to WellBehavedFX as an evidence that
they indeed can be resolved.


> I'm not saying one approach is right and the other is wrong - I'm working
> on my idea of how to approach this, and as I said, I invite you to do the
> same. In regard to 'closing doors' - I don't think anything I've done up to
> now has closed doors. I believe that WellBehavedFX will continue to be able
> to work in the current approach I have implemented (it just hooks into
> EventHandlers, right?) - it just won't make use of any of it!


By the same argument, neither is JavaFX closing doors to anyone who wants
to implement their own UI toolkit. They just won't make use of any of it!
:D More seriously though, no, the two mechanisms cannot coexist well on the
same control: they both hook into event handlers and 1) the order in which
event handlers are invoked is undefined and 2) all applicable event
handlers are invoked, regardless of whether some of them consumed the
event. In fact, if there was enough control over event handlers, there
would be little motivation for any of this input mapping stuff. Since there
can only be one mechanism in place, it better cover 99.99% of use cases.


> Nothing I'm creating is being forced down anyones throats - it is an
> implementation and API that is optional. As it stands, the sandbox repo I'm
> working in has all controls using it, but that doesn't mean controls such
> as your rich text editor are forced to use it, and I imagine that they will
> continue to work well with your WellBehavedFX API and implementation. Am I
> misunderstanding what you're saying? -- Jonathan


If my control uses WellBehavedFX, and in JDK 9 there will be the new
InputMap API, users (especially new ones) will try to use that API to
customize input mappings (because, well, that is the JavaFX way to do it,
right?). Except the two can interact in unpredictable ways (see above). Now
if you say that they should study the control and the ways how to interact
with it, that argument does not extend to generic code, where the type of
node is known to be only Control (or Node), not the concrete custom
control. So custom control authors will be forced to switch to the new API.
So again, it better cover 99.99% of use cases.

Regards,
Tomas

Re: JEP 253: UI control skins and input mapping discussion

[Tomas Mikula]

Hi Jonathan,

On Wed, Aug 19, 2015 at 7:00 PM, Jonathan Giles 
wrote:

> 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! :-)
>

My disappointment comes from not addressing the issues I have raised.


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

That was the "template" part, i.e. the part which enables you to share an
input map across all instances of the same control. I'm not saying this
should or shouldn't be part of proposal. I'm saying the proposal should not
close doors to such implementations (by third parties or in future JavaFX
versions).


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

 I don't have the bandwidth to port JavaFX controls. However, we can write
down a list of use-cases and present user code for them side by side (e.g.
a document on GitHub, BitBucket, ... to which both of us and possibly other
people have write access). These can include all the cases that you
encountered while porting JavaFX controls. Metrics on the implementation
(like the API surface) will be easy to calculate (I can restructure
WellBehavedFX to put the non-essential stuff into a separate package).

Regards,
Tomas


>
>
> -- 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 ma

Re: JEP 253: UI control skins and input mapping discussion

[Tomas Mikula]

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 
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?
>>
>
>

Re: The Case for JavaFX & Emulated L&Fs (across iOS, Android etc.)

[Tomas Mikula]

I share your view of FXML and CSS. I will not shed a single tear if the
support for them is dropped tomorrow. My main problem with CSS is that it
lacks any sort of static "type" checking.

Tomas

On Wed, Jul 29, 2015 at 7:36 AM, cogmission (David Ray) <
cognitionmiss...@gmail.com> wrote:

> The argument against emulated L&Fs hinges on one point: That they will
> "always" be one step behind.
>
> This (Greg Brown et al.) is a fallacy!
>
> The reason being is that companies like Apple and Google count on
> "affinity", acculturation, and familiarization with a given method of
> presentation in order to increase patronage!
>
> It is *not* like these companies change their L&Fs with every new release.
> You are confusing language/application features with presentation formats -
> which *do not* change at the same rate. Apple has changed its iOS widget
> set twice in the last ~10 years! (while features do in fact change) ...and
> let's not talk about the speed of Android feature uptake; let alone actual
> GUI widget-set changes?
>
> Yes, Oracle can indeed keep up with L&F changes - *easily*; and they do not
> have to worry about "features" so much because much of that is passed to
> implementation developers.
>
> Another point.
>
> HTML 5 usage idioms suck. (Sorry, I feel strongly about this). The whole
> idea of spreading L&F configuration across 2 or 3 different formats is
> ill-conceived and painfully over-verbose! (Yes I'm talking about FXML,
> BXML; CSS etc...) The fact that it allows designers  to function
> autonomously is also a fallacy. I have never seen this play out in actual
> practice - as time-to-market doesn't allow the creation of "perfect code"
> (in terms of separation of concerns) - because developers cost too much
> money; and while companies want expressively rich UIs - they are
> concordantly not willing to pay for it. (unfortunately - I have seen this
> over and over and over again).
>
> Back to the point...
>
> Spreading the UI definition across language formats means the developer has
> to learn more than one format to get the job done - thus invoking the
> eventuality; "Jack of all trades; Master of none." This also makes
> maintainability dependent on local convention (which is absurd and not
> dependable across implementation entities).
>
> The only thing it (FXML, BXML) is good for is automatic GUI builder
> implementations; and it should be left at that.
>
> CSS is not intuitive (as is a GUI widget toolset API; in the language of
> implementation). Mastery depends on memorization (which is a losing
> proposition for uptake); instead of intuitive insight across consistent
> methods of accomplishing tasks.
>
> I think in our field, if something is said often enough - it starts to be
> accepted as truth. I for one would like to stand up against some of these
> misnomers.
>
> I apologize for my emphatic expression of these points - I have been
> holding this in for a long time :-P
>
> --
> *With kind regards,*
>
> David Ray
> Java Solutions Architect
>
> *Cortical.io *
> Sponsor of:  HTM.java 
>
> d@cortical.io
> http://cortical.io
>

Re: Lazy loading of images in scrollpane

[Tomas Mikula]

Or use Flowless
https://github.com/TomasMikula/Flowless

Tomas
 On Jul 13, 2015 2:36 PM, "Tom Schindl"  wrote:

> Use a ListView ;-) Unfortunately the base class (VirtualFlow is not
> public API)
>
> Tom
>
> On 13.07.15 20:19, Christian Krampenschiesser wrote:
> > Hi all,
> >
> > I am trying around since some time to load images when they are visible
> in
> > a scollpane.
> > However the only solution I got so far is quite complicated and done via
> > checking the bounds in the scene.
> > However sometimes the calculated bounds of the item in the scene are way
> > out of the scene.
> > I am really looking for a simpler solution then my current one.
> > My tests are fine so far with small amounts of thumbnails. however with
> big
> > scenes (~3000 thumbnails) everything goes wrong :(
> > But if there is none maybe someone can point out my wrong bounding box
> > calculations and why they are wrong. It seems I didn't understand
> > everything correctly:
> >
> > protected SimpleObjectProperty item = new
> > SimpleObjectProperty<>();//contains, path and loads thumbnail + real
> > image
> >
> > 
> >
> > button.localToSceneTransformProperty().addListener(new
> > ChangeListener() {//button has an imageview which displays
> > the thumbnail
> >   @Override
> >   public void changed(ObservableValue observable,
> > Transform oldValue, Transform newValue) {
> > Point2D point = button.localToScene(button.getLayoutX(),
> > button.getLayoutY());
> > Scene scene = button.getScene();
> >
> > boolean isLayoutedCorrectly = button.getWidth() > 100 &&
> > button.getHeight() > 100;//hack to execute after layouting, otherwise
> > all items are visible
> >
> > if (scene != null && button.getParent() != null &&
> > isLayoutedCorrectly && armed) {//armed is set 100ms after adding all
> > buttons to a flowpane in a scrollpane
> >   BoundingBox sceneBox = new BoundingBox(scene.getX(),
> > scene.getY(), scene.getWidth(), scene.getHeight());
> >   BoundingBox buttonBox = new BoundingBox(point.getX(),
> > point.getY(), button.getWidth(), button.getHeight());
> >
> >   if (sceneBox.intersects(buttonBox)) {//visible
> > if (imageView.getImage() == null) {
> >   log.debug("Showing {}", button.getText());
> >   Image image = item.get().loadThumbNail();
> >   if (image != null) {
> > imageView.setImage(image);
> > imageView.setFitHeight(image.getHeight());
> > imageView.setFitWidth(image.getWidth());
> >   }
> > }
> >   }
> > }
> >   }
> > });
> >
> >
> > Thanks!
> >
> > Christian
> >
>
>
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization

[Tomas Mikula]

Hi Robert,

> The Behaviors contain logic at the moment, various functions that are used
> by the skin or the behavior itself (for example the selectNextTab() function
> in the TabPaneBehavior).

In my view, such code should be refactored to not have any
back-reference from skin to behavior. As a result, it will be
impossible for the skin to directly call methods of behavior.

Tomas

Re: Why are style classes stored in a List instead of a Set?

[Tomas Mikula]

Hi Roland,

I don't know why it is a List (maybe it is just copying it being a
list in the DOM), but it makes sense to me that a style class can be
present multiple times (for that matter, a multi-set would work just
as well):

If I have two places in my code that add and remove the same style
class, it makes sense to me the style class being removed after both
of them have removed it, not just the first one. Say that I have two
different conditions, either of which makes a node "highlighted". When
both are true, and then one of them stops being true, I still want the
node to stay highlighted.

Why do you need to make a contains-check?

Tomas

On Thu, May 21, 2015 at 1:17 AM, Roland C  wrote:
> I was recently toying around with CSS in JavaFX and noticed that I got the
> same style multiple times in the style list of my node.
>
> Since the order of the styles is defined by the order in the css file and
> not by the order of the list that getStyleClass() of a node returns, I was
> wondering if there is a special reason for that.
>
> Example:
>
> application.css
>
> .bg-color-1 {
> -fx-background-color:red; }.bg-color-2 {
> -fx-background-color:green;}
>
> Main.java
>
> public class Main extends Application {
> @Override
> public void start(Stage primaryStage) {
> try {
> BorderPane root = new BorderPane();
>
> root.getStyleClass().add( "bg-color-1");
> root.getStyleClass().add( "bg-color-2");
>
> Scene scene = new Scene(root,400,400);
> 
> scene.getStylesheets().add(getClass().getResource("application.css").toExternalForm());
> primaryStage.setScene(scene);
> primaryStage.show();
> } catch(Exception e) {
> e.printStackTrace();
> }
> }
>
> public static void main(String[] args) {
> launch(args);
> }}
>
> It doesn't matter if you write
>
> root.getStyleClass().add( "bg-color-1");
> root.getStyleClass().add( "bg-color-2");
>
> or change the order to
>
> root.getStyleClass().add( "bg-color-2");
> root.getStyleClass().add( "bg-color-1");
>
> The used style will always be the last in the css file, i. e. "bg-color-2".
>
> *Question*
>
> Why is a List used instead of a Set? A list is less performing than a Set
> and it clutters the code if you always have to make a contains-check first.
>
>
> Thank you very much!

Re: JavaFX JIRA issues moving to JBS

[Tomas Mikula]

On Wed, Apr 15, 2015 at 10:54 AM, Richard Bair  wrote:
> This is exactly the issue. We know from the last 20 years that in fact we get 
> a huge amount of completely bogus bugs that get filed via bugs.java.com 
>  (previously bugs.sun.com ). 
> Wild stuff from end users like “I can’t reboot my computer” and so forth. The 
> concern with JBS (as I understand it) was that we’d end up with 10’s or 
> 100,000’s of thousands of user accounts, many of which would be one-shot 
> submitters associated with bogus issues.

This is a problem of a huge community, but also can be solved by the
community: if community members can flag those bug reports and a
consensus of, say, 5 community members is sufficient to close the
issue. Just like on StackOverflow.

Tomas

Re: Private APIs not usable in Java 9?

[Tomas Mikula]

>Should I rely now on all of those fixes
> to be backported to 8?

Why do you need them to be backported to 8? Just having them fixed in
9 should be fine, no? (keeping the private workarounds for 8)

T.

Re: Private APIs not usable in Java 9?

[Tomas Mikula]

I do believe in making things right (like killing Unsafe, hiding private APIs).

The transition will just be so much pain now that there is so much
accumulated private APIs used in production. If there were no
accessible private APIs to start with, there would be more pressure to
fix bugs and expose functionality in public APIs.

And no, in practice, there are not /*years*/ to transition. In
practice, projects have dependencies. If I decide to move on to 9, but
my dependency has not been ported yet, I have a problem. If I'm still
stuck with 8, but my dependency has moved on to 9 and stopped
backporting bugfixes and new features to 8 (which would be
understandable, because it is quite a bit of maintanence cost to
maintain two codebases), then I have a problem.

Anyway, the transition is inevitable and good in the long term. I will
just be happy if Oracle manages to flesh out their experimental
private APIs that people are already using today, but I am somewhat
skeptical that this will happen for JavaFX before 9, thus resulting in
a period of temporarily lost functionality.

Tomas

On Wed, Apr 8, 2015 at 3:15 PM, Donald Smith  wrote:
> Making any theoretical flag available to the deployment side would entirely
> miss the point.
>
> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait for it
> -- Unsafe.  It must go.  Ignore any kind of theoretical rope and start the
> path to righteousness _*/now/*_. It is still years until the end of public
> updates to JDK 8, so we have /*years */to work this out properly.  But
> sticking our heads in the collective sands and hoping for trivial work
> arounds to Unsafe is not going to work.  If you're using Unsafe, this is the
> year to explain where the API is broken and get it straight
>
> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do so
> as quickly as possible to the ultimate benefit of everyone.
>
>  - Don
>
>
> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>>
>> Hi,
>>
>> then I can only hope, that this flag is available to webstart
>> applications.
>> Webstart applications have no control over the installed jre. In the past
>> we encountered various bugs in the jre, which required using internal apis
>> for workarounds.
>> For example in some releases of Java 7 the swing gui thread did not start
>> unless hacking internal apis (see
>> https://javafx-jira.kenai.com/browse/RT-31205 for details). If such an error
>> occurs again in the future and we are no longer able to hack around the
>> problem, our only choice to keep our business alive, is to discourage users
>> from upgrading to newer versions of the jre, exposing them to security
>> risks.
>>
>> - Stefan
>>
>>
>>>
>>> >  it's not strictly JFX-only.
>>>
>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>> as being relatively new it does not have 20 years of accumulation
>>> of people using internal APIs that the larger JDK does, often dating from
>>> when there were no suitable public APIs. There still remains some
>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>> inaccessible in modular mode. But the FX list isn't really the place
>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>> is simply bound by the rules that are set there.
>>>
>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>> transition.
>>>
>>> Also remember FX is open source. You can propose patches !
>>> If there are specific APIs that are missing from FX that are suitable
>>> to be *supported* public APIs then those could be considered here (this
>>> list).
>>>
>>> -phil.
>>>
>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:

 sed -i 's/private/public/g' ;)

 The whole notion of a strongly enforced private keyword is IMHO dumb
 when
 not using sandboxing. The number of gross hacks that occur in an attempt
 to
 work around overly strict enforcement of this stuff is crazy. The D
 compiler has a special flag that disables visibility enforcement when
 compiling unit tests, and that's a good idea, but why not go all the way
 and just make accessing of private state a compiler warning a la
 deprecated?

 I also need to use private JFX APIs. I think any real JFX app does, way
 too
 much basic stuff relies on it. Heck, the number of popular Java
 libraries
 that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
 in
 this regard then I will just write a simple tool that flips
 private->public
 either at the source level or via bytecode editing, and see what happens
 :-)


 On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger 
 wrote:

> Hi,
>
> I hope this is not too off-topic, because although it came up in a JFX
> context it's not strictly JFX-only.
>
> Someone from our team recently had a chat with a high-ranking regional
> Oracle representative who gave a talk on the state of JFX

Re: Private APIs not usable in Java 9?

[Tomas Mikula]

My concern is that issues with existing workarounds were given lower
priority. Now many workarounds will disappear, but I'm worried that
the priorities will not be reconsidered.

I think part of the problem is the fact that Java does not have a good
way of marking an API as experimental. Anything public can never
change, so JDK developers don't make things public if they are not
quite happy with the API yet, even though some bits would be useful
for others. As a consequence, they get no or very little feedback on a
private API, thus slowing the progress towards the non-experimental
API even more. Sure, experimental functionality could still be dropped
at any time, but that is not happening here. The functionality
remains, it is just going to be hidden.

Robert makes a good point that designing a stable API for something
that is currently private and possibly ugly is much more work than
pulling ad-hoc hacks with the experimental API. I believe Jira issues
are mostly there, I'm just skeptical that all of the issues currently
targeted for 9 will actually be resolved in 9.

On Wed, Apr 8, 2015 at 1:23 PM, Robert Krüger  wrote:
> OK, while I wrote this, all the other replies came in. So I see that your
> recommendation for the cases I mentioned is then to patch OpenJDK and
> submit Jira issues. Fair enough.
>
> Regarding Jira issues, we are already doing that. Regarding code
> contribution, this is a different thing, because in many cases a hack to
> expose something that should be there is quick but designing a consistent
> API that exposes the missing things is often something that requires a
> different qualification.
>
>
>>

How to tell if KEY_PRESSED comes with a corresponding KEY_TYPED?

[Tomas Mikula]

On character input, two events are fired: KEY_PRESSED and KEY_TYPED.
When my control is interested in the characters, KEY_TYPED should be
handled, because it contains the entered Unicode characters. In that
case, however, I would also like to consume the corresponding
KEY_PRESSED event, so that it does not bubble up the scene graph.

A user reported an instance of this problem with my RichTextFX control
placed inside a ScrollPane: when spacebar was pressed, a space was
inserted in the text area *and* the ScrollPane scrolled down. This
happened because RichTextFX handled the KEY_TYPED event, but let the
KEY_PRESSED bubble up and ScrollPane handled the KEY_PRESSED event.

I can fix the above case by RichTextFX consuming KEY_PRESSED events
whose key code isLetterKey(), isDigitKey() or isWhitespaceKey(), but
it is not a general solution: it would still not work if ScrollPane
used e.g. '[' and ']' to scroll up and down.

My question is, is there a general solution for this kind of problem?

Given a KEY_PRESSED event, being able to tell whether there is a
corresponding KEY_TYPED event generated would solve the problem, but
it is currently not possible AFAIK.

Regards,
Tomas

Re: ProgressBar has significant leaks

[Tomas Mikula]

Looks like someone is adding weak listeners to ProgressBarSkin$1 in
the first case and to Node$NodeTransformation$2 in the second case,
but does not bother removing them, relying on the WeakReference to
enable their garbage collection. Well, the listeners themselves get
garbage collected, but the WeakReferences to them do not, until the
property is invalidated. Can you figure out what ProgressBarSkin$1 and
Node$NodeTransformation$2 are? These are probably properties that
don't change, thus WeakListeners fail to work well with them. You
could probably work around the problem by invalidating them
occasionally.

See also "Problem 2: Memory Leaks" in my post on "The Trouble with
Weak Listeners"
http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html

Tomas

On Fri, Mar 27, 2015 at 2:36 PM, Scott Palmer  wrote:
> Another chain to the GC root looks like:
>
> WeakReference
> BindingHelperObserver
> InvalidationListener[]
> ExpressionHelper$Generic
> Node$NodeTransformation$2
> Node$NodeTransformation
> StackPane
> ProgressBarSkin
> ProgressBar
>
>
> On Fri, Mar 27, 2015 at 2:28 PM, Scott Palmer  wrote:
>
>> I searched the bug database and though ProgressBar leaks have been
>> reported before, they are supposed to be fixed in 8u40.  I'm seeing tons of
>> leaks in 8u40.
>>
>> Comparing heap dumps with jvisualvm I see in three minutes that my app has
>> accumulated 11,000 WeakReference and BindingHelperObserver objects that
>> appear to be associated with the ProgressBarSkin.
>>
>> The chain to the GC root looks like this:
>>
>> WeakReference
>> BindingHelperObserver
>> InvalidationListener[]
>> ExpressionHelper$Generic
>> ProgressBarSkin$1
>> ProgressBarSkin
>> ProgressBar
>>
>> My application needs to run for a long time.  (Streaming realtime video -
>> i.e. a TV station broadcast for hours if not weeks at a time...)
>>
>> I suspect this may be a regression in 8u40.  I will try to get that
>> confirmed.
>>
>> Scott
>>

Re: The trouble with Skins

[Tomas Mikula]

On Tue, Mar 24, 2015 at 6:47 PM, Tom Eugelink  wrote:
> On 22-3-2015 13:53, John Hendrikx wrote:
>>
>> On 22/03/2015 09:59, Tom Eugelink wrote:
>>>
>>> On 22-3-2015 00:12, John Hendrikx wrote:


 What I do need however is a way to restore the control to the exact same
 state it was in before (the same amount of pixels scrolled, the same item 
 at
 the top, the same item at the bottom).
>>>
>>>
>
> I was thinking; maybe you are approaching this from the wrong angle by
> trying to break open the controls. How about inspecting the node tree, after
> it has been constructed (all skins have created their nodes)? After all, a
> ListView will insert a scrollpane into the tree, which will insert a
> scrollbar. You could analyze the resulting node tree and search for the
> scrollbars, then record their scroll values.
>
> The trick would be to identify the correct one again to reset the value. You
> may be able to derrive an identifier from the tree path to the scrollbar,
> assuming it would be identical before and after. Or maybe better, you could
> place a UUID in the node's properties and also use that UUID for storing the
> recorded values. Could that work?
>

I'm sure you could make it work this way, but 1) it is a lot of work
and 2) it is very fragile. It will break when ListView internals
change or when the ListView is loaded with a different skin on
restart. So it's a matter of how badly John wants this done.

Btw, "inspecting the node tree" seems like "break open the controls" to me.

I think it is OK to say that ListView does not support this; my more
general question was how should one proceed when writing a custom
control that supports some view-specific details and at the same time
wants to have customizable (i.e. skinnable) look & feel.

Tomas

Re: The trouble with Skins

[Tomas Mikula]

Yes, I think that would be much better than the current situation.

On Mon, Mar 23, 2015 at 5:08 PM, Tom Eugelink  wrote:
> Suppose control would support have generics type, to make the requirement on
> the Skin formal.
>
> Control
> Control
>
> Then getSkin would expose information for every skin the control has,
> without polluting the control's API. Would that work for you?
>
> Tom
>
>
> On 23-3-2015 22:03, Tomas Mikula wrote:
>>
>> Sure, it is a workaround that works, but I don't think type cast
>> should be the recommended way to do this (or to do anything).
>>
>> Tomas
>>
>> On Mon, Mar 23, 2015 at 4:15 PM, Tom Eugelink  wrote:
>>>
>>> On 23-3-2015 20:30, Tomas Mikula wrote:
>>>>
>>>> Control does not know what API is available on the Skin
>>>
>>>
>>> I have many controls that require a skin that implements a certain
>>> interface
>>> (refresh() is often present). Granted, this is not something that is
>>> compiler checkable via the setSkin method, but it can fail quickly at
>>> runtime. Works for me.
>>>
>>>
>>> https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/AgendaSkin.java
>>>
>>>
>>> Tom
>
>

Re: The trouble with Skins

[Tomas Mikula]

Sure, it is a workaround that works, but I don't think type cast
should be the recommended way to do this (or to do anything).

Tomas

On Mon, Mar 23, 2015 at 4:15 PM, Tom Eugelink  wrote:
> On 23-3-2015 20:30, Tomas Mikula wrote:
>>
>> Control does not know what API is available on the Skin
>
>
> I have many controls that require a skin that implements a certain interface
> (refresh() is often present). Granted, this is not something that is
> compiler checkable via the setSkin method, but it can fail quickly at
> runtime. Works for me.
>
> https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/AgendaSkin.java
>
>
> Tom

Re: The trouble with Skins

[Tomas Mikula]

Thank you, Richard, for your response.

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

Re: The trouble with Skins

[Tomas Mikula]

On Sat, Mar 21, 2015 at 2:10 PM, Tom Eugelink  wrote:
> I don't understanding how you see that.
>
>
>
> On 21-3-2015 18:47, Tomas Mikula wrote:
>>
>> So Skins prevent us from getting visual details of the Control (such
>> as scroll position, position of item on screen, ...), because it is
>> Skin-specific,

I suppose this part is clear?

>> but at the same time they fail to customize the look &
>> feel, because visual presentation leaks into the Control anyway.

This is a summary of John's email.

Tomas

>>
>> On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx  wrote:
>>>
>>> On 14/03/2015 08:31, Tom Eugelink wrote:
>>>>
>>>> Hi Tomas,
>>>>
>>>> I have looked into it, but not yet attempted, but I did do a lot of
>>>> custom
>>>> controls. And I agree that it is dubious that a control is a node, and
>>>> has
>>>> the properties that come with it. I try to maintain a strict separation
>>>> in
>>>> my controls in JFXtras; controls only have functional methods, the skin
>>>> and
>>>> CSS do all the layout. For example the gauge I've ported from Enzo; my
>>>> version does not have a setFillColor() like the one in Enzo, that is
>>>> something that the user needs to do through CSS.
>>>>
>>>> That said, if a control were only a model, than it would not be a
>>>> control,
>>>> right? We would create model-skins, so there is something that
>>>> differentiates a control from a model. To me that is an abstraction of
>>>> the
>>>> skin. For example: not knowning HOW it is rendered, a textbox does know
>>>> that
>>>> it can receive the focus, it is implicit to what it is. So there is a
>>>> certain logic for allowing controls to have rudimentary rendering info,
>>>> as
>>>> long as it does not expose the actual layout details.
>>>>
>>>> Looking at ListView, there is a logic in that a list can scroll, so
>>>> onScroll on the control makes sense. Whether that scrolling is done via
>>>> a
>>>> scrollbar or buttons is a skin detail that should not leak out. So the
>>>> fact
>>>> that ListView does not have a scroll position makes sense to me.
>>>
>>>
>>> As someone that has been tempted to write a new Control that replaces
>>> ListView atleast half a dozen times now because of restrictions or idioms
>>> that don't match my needs, I'd disagree.  A ListView doesn't need to
>>> scroll
>>> at all.  An application that isn't mouse or touchscreen controlled
>>> (keyboard
>>> or remote controlled for example) has zero need for scrollbars except
>>> maybe
>>> as information to show the relative size of the view.
>>>
>>> A List of items could be paged only, or they could flip.  I'd like to be
>>> able to take a List, and wrap it in a ScrollBarView... or in a PagerView,
>>> FlipOverView or CoverFlowView (with 30 new properties to set things like
>>> reflections, 3d parameters, distance between items, etc).   It is
>>> possible
>>> to do this with Skins, but it feels like a hack rather than simply a
>>> different Look&Feel in the end.
>>>
>>>   After all, a ListView is a container for an unbounded list of items.  I
>>> can
>>> think of half a dozen ways of how that can be shown to the user, and the
>>> current ListView is just one way to do it.  The promise of Skins here is
>>> that I could just change the look & feel, but unfortunately way too many
>>> details of the "default" look & feel leak through in the Control itself.
>>>
>>> --John
>>>
>>>> Tom
>>>>
>>>>
>>>> On 14-3-2015 04:33, Tomas Mikula wrote:
>>>>>
>>>>> A quick poll:
>>>>>
>>>>> Has anyone ever implemented a custom skin for some of the more complex
>>>>> controls like ListView, TableView, TreeView, TextArea?
>>>>>
>>>>> The problem I have with the Control/Skin architecture is that a
>>>>> Control, being a Node in the scene graph, cannot be a pure model (in
>>>>> the MVC sense) - it is inherently a view (in the MVC sense). What is
>>>>> the model of a check box? For me, a model of a check box is a boolean
>>>>> property; certainly not something that has boundsInParent or

Re: The trouble with Skins

[Tomas Mikula]

So Skins prevent us from getting visual details of the Control (such
as scroll position, position of item on screen, ...), because it is
Skin-specific, but at the same time they fail to customize the look &
feel, because visual presentation leaks into the Control anyway.

On Sat, Mar 21, 2015 at 12:01 PM, John Hendrikx  wrote:
> On 14/03/2015 08:31, Tom Eugelink wrote:
>>
>> Hi Tomas,
>>
>> I have looked into it, but not yet attempted, but I did do a lot of custom
>> controls. And I agree that it is dubious that a control is a node, and has
>> the properties that come with it. I try to maintain a strict separation in
>> my controls in JFXtras; controls only have functional methods, the skin and
>> CSS do all the layout. For example the gauge I've ported from Enzo; my
>> version does not have a setFillColor() like the one in Enzo, that is
>> something that the user needs to do through CSS.
>>
>> That said, if a control were only a model, than it would not be a control,
>> right? We would create model-skins, so there is something that
>> differentiates a control from a model. To me that is an abstraction of the
>> skin. For example: not knowning HOW it is rendered, a textbox does know that
>> it can receive the focus, it is implicit to what it is. So there is a
>> certain logic for allowing controls to have rudimentary rendering info, as
>> long as it does not expose the actual layout details.
>>
>> Looking at ListView, there is a logic in that a list can scroll, so
>> onScroll on the control makes sense. Whether that scrolling is done via a
>> scrollbar or buttons is a skin detail that should not leak out. So the fact
>> that ListView does not have a scroll position makes sense to me.
>
>
> As someone that has been tempted to write a new Control that replaces
> ListView atleast half a dozen times now because of restrictions or idioms
> that don't match my needs, I'd disagree.  A ListView doesn't need to scroll
> at all.  An application that isn't mouse or touchscreen controlled (keyboard
> or remote controlled for example) has zero need for scrollbars except maybe
> as information to show the relative size of the view.
>
> A List of items could be paged only, or they could flip.  I'd like to be
> able to take a List, and wrap it in a ScrollBarView... or in a PagerView,
> FlipOverView or CoverFlowView (with 30 new properties to set things like
> reflections, 3d parameters, distance between items, etc).   It is possible
> to do this with Skins, but it feels like a hack rather than simply a
> different Look&Feel in the end.
>
>  After all, a ListView is a container for an unbounded list of items.  I can
> think of half a dozen ways of how that can be shown to the user, and the
> current ListView is just one way to do it.  The promise of Skins here is
> that I could just change the look & feel, but unfortunately way too many
> details of the "default" look & feel leak through in the Control itself.
>
> --John
>
>>
>> Tom
>>
>>
>> On 14-3-2015 04:33, Tomas Mikula wrote:
>>>
>>> A quick poll:
>>>
>>> Has anyone ever implemented a custom skin for some of the more complex
>>> controls like ListView, TableView, TreeView, TextArea?
>>>
>>> The problem I have with the Control/Skin architecture is that a
>>> Control, being a Node in the scene graph, cannot be a pure model (in
>>> the MVC sense) - it is inherently a view (in the MVC sense). What is
>>> the model of a check box? For me, a model of a check box is a boolean
>>> property; certainly not something that has boundsInParent or
>>> onZoomFinished properties. CheckBox is hardly a model. It is a view.
>>> Everything in the scene graph is inherently a view.
>>>
>>> There is this idea that the view aspect of a control is implemented by
>>> the skin. The control itself does not know what the skin looks like or
>>> even what skin class is used. So a ListView knows about its items, but
>>> it does not know about its scroll position. But users sometimes want
>>> to know the scroll position. Why should there be onScrollProperty, but
>>> not way to get the current scroll position? Why should there be
>>> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There
>>> is no good way to implement the latter methods using custom skins. The
>>> ListView or TextArea don't know anything about the skin, thus they
>>> don't know anything about the current scroll position or caret bounds.
>>> They cannot ask the skin, because there might b

Re: OpenJFX mirror at BitBucket?

[Tomas Mikula]

But we still need this one-way mirror, from which users can fork,
right? My assumption is that bitbucket will not keep track of how much
you diverged from the OpenJDK repo you initially cloned. It will,
however, tell you how much you diverged from a bitbucket repo that you
forked.

On Tue, Mar 17, 2015 at 8:09 PM, Jonathan Giles
 wrote:
> BitBucket supports generation of patches from pull requests. My suggestion
> was that community members who wanted to use BitBucket to collaborate and /
> or easily keep their work current with the repo could do so, and when they
> create their pull request, they can have bitbucket generate the patch file
> for submission 'the old fashioned way'.
>
> -- Jonathan
>
> On 18/03/2015 1:03 p.m., Tomas Mikula wrote:
>>
>> Legal issues could be resolved by requiring a signed OCA before each
>> pull request is merged. But anyway, if OpenJDK project does not accept
>> pull requests, who is going to create the patches? If patches are
>> painful for individual developers, they are going to be super painful
>> for the person who is supposed to get the accepted PRs back to
>> OpenJDK.
>>
>> OTOH, one-way mirrors should be easy enough to maintain by anyone who
>> has access to a server where they can set up a cron task to
>> periodically pull from OpenJDK repos and push to bitbucket repos.
>> Whoever forks the mirror and makes changes would still have to submit
>> patches directly to OpenJDK.
>>
>> Tomas
>>
>> On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
>>  wrote:
>>>
>>> There is no issue with members of the community using BitBucket to
>>> develop
>>> their patches. I just don't think it is a wise use of our limited time to
>>> maintain a mirror. This seems something that interested community members
>>> can do if they want. The main issue is as Kevin mentioned - someone has
>>> to
>>> submit the patch officially, and that someone has to have signed an OCA
>>> stating that they are owners of the code and IP being submitted. It would
>>> pay to very carefully track who has contributed code to a certain patch
>>> file, as all contributors will need to have signed an OCA.
>>>
>>> -- Jonathan
>>>
>>>
>>> On 18/03/2015 11:12 a.m., Florian Brunner wrote:
>>>>
>>>> Wouldn't it be possible for the OpenJFX team to officially maintain a
>>>> mirror at
>>>> BitBucket themselves and use the same criteria for accepting a
>>>> pull-request as
>>>> for accepting a patch-file? Then you're sure that you can synchronize it
>>>> with
>>>> the main repositories without any legal or quality issues.
>>>>
>>>> The contributors could link their forks and pull-requests in JIRA for
>>>> documentation purposes.
>>>>
>>>> It would really be great if we could move on with this.
>>>>
>>>> -Florian
>>>>
>>>> Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
>>>>>
>>>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
>>>>> for your own experiments, that is certainly something you could do
>>>>> (subject to the GPLv2 + CLASSPATH license terms).
>>>>>
>>>>> For those patches to then be incorporated into the openjfx repos on
>>>>> hg.openjdk.java.net they need to go through the existing openjdk
>>>>> mechanism (which requires a signed OCA) as patches / webrevs, just like
>>>>> any other openjdk project. We cannot take patches directly from a
>>>>> BitBucket repo.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>> Jonathan Giles wrote:
>>>>>>
>>>>>> There was a mirror, but it was unofficial and one-way (OpenJDK ->
>>>>>> BitBucket). I believe (although my memory may be failing me) that it
>>>>>> was operated by Danno, so he might have more to say.
>>>>>>
>>>>>> In regards to fork / pull-request vs patch-file, I have no arguments
>>>>>> there. Of course, OpenJFX is part of the OpenJDK, and therefore makes
>>>>>> use of the OpenJDK infrastructure. My main point is that any movement
>>>>>> regarding infrastructure is guided by an over-arching infrastructure
>>>>>> team, in conjunction with the OpenJDK masters. OpenJFX can't work
>>>>>> independent of this.
>>>>>>
>>>>>> -- Jonathan
>>>>>>
>>>>>> On 18/03/2015 10:50 a.m., Florian Brunner wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> AFAIK there is/ was a mirror of OpenJFX at BitBucket.
>>>>>>>
>>>>>>> I think the URL was https://bitbucket.org/openjfxmirrors, but it's
>>>>>>> not valid
>>>>>>> anymore.
>>>>>>>
>>>>>>> Is there still a mirror of OpenJFX at BitBucket?
>>>>>>>
>>>>>>> A fork/pull-request workflow is state-of-the-art nowadays in software
>>>>>>> development and way better than a patch-file based workflow IMHO.
>>>>>>>
>>>>>>> It would be great to have such a fork/pull-request workflow also for
>>>>>>> OpenJFX!
>>>>>>>
>>>>>>> -Florian
>>>
>>>
>

Re: OpenJFX mirror at BitBucket?

[Tomas Mikula]

Legal issues could be resolved by requiring a signed OCA before each
pull request is merged. But anyway, if OpenJDK project does not accept
pull requests, who is going to create the patches? If patches are
painful for individual developers, they are going to be super painful
for the person who is supposed to get the accepted PRs back to
OpenJDK.

OTOH, one-way mirrors should be easy enough to maintain by anyone who
has access to a server where they can set up a cron task to
periodically pull from OpenJDK repos and push to bitbucket repos.
Whoever forks the mirror and makes changes would still have to submit
patches directly to OpenJDK.

Tomas

On Tue, Mar 17, 2015 at 6:22 PM, Jonathan Giles
 wrote:
> There is no issue with members of the community using BitBucket to develop
> their patches. I just don't think it is a wise use of our limited time to
> maintain a mirror. This seems something that interested community members
> can do if they want. The main issue is as Kevin mentioned - someone has to
> submit the patch officially, and that someone has to have signed an OCA
> stating that they are owners of the code and IP being submitted. It would
> pay to very carefully track who has contributed code to a certain patch
> file, as all contributors will need to have signed an OCA.
>
> -- Jonathan
>
>
> On 18/03/2015 11:12 a.m., Florian Brunner wrote:
>>
>> Wouldn't it be possible for the OpenJFX team to officially maintain a
>> mirror at
>> BitBucket themselves and use the same criteria for accepting a
>> pull-request as
>> for accepting a patch-file? Then you're sure that you can synchronize it
>> with
>> the main repositories without any legal or quality issues.
>>
>> The contributors could link their forks and pull-requests in JIRA for
>> documentation purposes.
>>
>> It would really be great if we could move on with this.
>>
>> -Florian
>>
>> Am Dienstag, 17. März 2015, 15.02:01 schrieb Kevin Rushforth:
>>>
>>> Right. If you wanted to revive the unofficial OpenJFX bitbucket mirror
>>> for your own experiments, that is certainly something you could do
>>> (subject to the GPLv2 + CLASSPATH license terms).
>>>
>>> For those patches to then be incorporated into the openjfx repos on
>>> hg.openjdk.java.net they need to go through the existing openjdk
>>> mechanism (which requires a signed OCA) as patches / webrevs, just like
>>> any other openjdk project. We cannot take patches directly from a
>>> BitBucket repo.
>>>
>>> -- Kevin
>>>
>>> Jonathan Giles wrote:

 There was a mirror, but it was unofficial and one-way (OpenJDK ->
 BitBucket). I believe (although my memory may be failing me) that it
 was operated by Danno, so he might have more to say.

 In regards to fork / pull-request vs patch-file, I have no arguments
 there. Of course, OpenJFX is part of the OpenJDK, and therefore makes
 use of the OpenJDK infrastructure. My main point is that any movement
 regarding infrastructure is guided by an over-arching infrastructure
 team, in conjunction with the OpenJDK masters. OpenJFX can't work
 independent of this.

 -- Jonathan

 On 18/03/2015 10:50 a.m., Florian Brunner wrote:
>
> Hi,
>
> AFAIK there is/ was a mirror of OpenJFX at BitBucket.
>
> I think the URL was https://bitbucket.org/openjfxmirrors, but it's
> not valid
> anymore.
>
> Is there still a mirror of OpenJFX at BitBucket?
>
> A fork/pull-request workflow is state-of-the-art nowadays in software
> development and way better than a patch-file based workflow IMHO.
>
> It would be great to have such a fork/pull-request workflow also for
> OpenJFX!
>
> -Florian
>
>

Re: The trouble with Skins

[Tomas Mikula]

I could say how I _feel_ differently about some things, but it's not
important how I feel. What is important is that it comes down to
practical problems. The layout details often leak and are not details
anymore. Sometimes you would like to know if an item of a ListView is
currently displayed. Or you want to know item's location on screen, so
that you can position a popup next to it. This is something only the
skin knows.

As said before, Control is not your domain model. We need to go no
further than OpenJFX for evidence: TextArea has a field of type
TextAreaContent, which says "Text area content model". So not even
OpenJFX uses Controls as (domain) models. So what kind of model is it?
Is it a "model of interaction" with the domain model? Layout details
necessarily leak in.

Maybe just being able to specify required type of skin would help: if
TextArea could say that its skin has to implement interface
TextAreaSkin (which has the method getCaretBounds()). Also, I think
skins should be opt-in - not all Controls should be Skinnable by
default.

Tomas

On Sat, Mar 14, 2015 at 3:31 AM, Tom Eugelink  wrote:
> Hi Tomas,
>
> I have looked into it, but not yet attempted, but I did do a lot of custom
> controls. And I agree that it is dubious that a control is a node, and has
> the properties that come with it. I try to maintain a strict separation in
> my controls in JFXtras; controls only have functional methods, the skin and
> CSS do all the layout. For example the gauge I've ported from Enzo; my
> version does not have a setFillColor() like the one in Enzo, that is
> something that the user needs to do through CSS.
>
> That said, if a control were only a model, than it would not be a control,
> right? We would create model-skins, so there is something that
> differentiates a control from a model. To me that is an abstraction of the
> skin. For example: not knowning HOW it is rendered, a textbox does know that
> it can receive the focus, it is implicit to what it is. So there is a
> certain logic for allowing controls to have rudimentary rendering info, as
> long as it does not expose the actual layout details.
>
> Looking at ListView, there is a logic in that a list can scroll, so onScroll
> on the control makes sense. Whether that scrolling is done via a scrollbar
> or buttons is a skin detail that should not leak out. So the fact that
> ListView does not have a scroll position makes sense to me.
>
> Tom
>
>
>
> On 14-3-2015 04:33, Tomas Mikula wrote:
>>
>> A quick poll:
>>
>> Has anyone ever implemented a custom skin for some of the more complex
>> controls like ListView, TableView, TreeView, TextArea?
>>
>> The problem I have with the Control/Skin architecture is that a
>> Control, being a Node in the scene graph, cannot be a pure model (in
>> the MVC sense) - it is inherently a view (in the MVC sense). What is
>> the model of a check box? For me, a model of a check box is a boolean
>> property; certainly not something that has boundsInParent or
>> onZoomFinished properties. CheckBox is hardly a model. It is a view.
>> Everything in the scene graph is inherently a view.
>>
>> There is this idea that the view aspect of a control is implemented by
>> the skin. The control itself does not know what the skin looks like or
>> even what skin class is used. So a ListView knows about its items, but
>> it does not know about its scroll position. But users sometimes want
>> to know the scroll position. Why should there be onScrollProperty, but
>> not way to get the current scroll position? Why should there be
>> TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There
>> is no good way to implement the latter methods using custom skins. The
>> ListView or TextArea don't know anything about the skin, thus they
>> don't know anything about the current scroll position or caret bounds.
>> They cannot ask the skin, because there might be no skin yet, and even
>> if there is, all they know about it is that it is an instance of
>> Skin - not much one can do with it (certainly not get caret
>> bounds).
>>
>> I'm leaning more and more towards not supporting custom skins at all.
>> The whole idea of overriding skins via CSS looks to me like dependency
>> injection via CSS, except without any possibility to constrain the
>> type of what can be injected.
>>
>> I would like to know the community opinion on this. Even hear your
>> success story how skins are awesome, if there is such.
>>
>> Regards,
>> Tomas
>
>

The trouble with Skins

[Tomas Mikula]

A quick poll:

Has anyone ever implemented a custom skin for some of the more complex
controls like ListView, TableView, TreeView, TextArea?

The problem I have with the Control/Skin architecture is that a
Control, being a Node in the scene graph, cannot be a pure model (in
the MVC sense) - it is inherently a view (in the MVC sense). What is
the model of a check box? For me, a model of a check box is a boolean
property; certainly not something that has boundsInParent or
onZoomFinished properties. CheckBox is hardly a model. It is a view.
Everything in the scene graph is inherently a view.

There is this idea that the view aspect of a control is implemented by
the skin. The control itself does not know what the skin looks like or
even what skin class is used. So a ListView knows about its items, but
it does not know about its scroll position. But users sometimes want
to know the scroll position. Why should there be onScrollProperty, but
not way to get the current scroll position? Why should there be
TextArea.getBoundsInParent(), but not TextArea.getCaretBounds()? There
is no good way to implement the latter methods using custom skins. The
ListView or TextArea don't know anything about the skin, thus they
don't know anything about the current scroll position or caret bounds.
They cannot ask the skin, because there might be no skin yet, and even
if there is, all they know about it is that it is an instance of
Skin - not much one can do with it (certainly not get caret
bounds).

I'm leaning more and more towards not supporting custom skins at all.
The whole idea of overriding skins via CSS looks to me like dependency
injection via CSS, except without any possibility to constrain the
type of what can be injected.

I would like to know the community opinion on this. Even hear your
success story how skins are awesome, if there is such.

Regards,
Tomas

Re: 8u40 is released / SB

[Tomas Mikula]

And then there are GroovyFX and ScalaFX, which embed the declarative
UI language in the host language. To me, FXML seems to be just
compensation for the lack of expressiveness in Java.

Tomas

On Thu, Mar 5, 2015 at 9:58 AM, Doug Schaefer  wrote:
> GUI builders are great for prototyping or helping you learn. But when the
> application gets complex I keep hearing developers throw them out. They
> start getting in the way.
>
> I think if you have a good API and a good declarative UI language, think
> QML not FXML, then you may find you don¹t really need a GUI builder. How
> may people are using GUI builders to create Web app UI¹s? Now web UIs are
> simpler, but maybe that¹s the point.
>
> And why not leave GUI builders to the tools vendors. They¹re hard to make
> and get right, especially of you don¹t have a revenue model to support the
> army of developers you need.
>
> Doug.
>
> Hmm, I wonder what React Native would look like with JavaFX and NashornŠ
>
> On 2015-03-05, 7:20 AM, "Scott Palmer"  wrote:
>
>>I would never consider for a second coding FXML "directly".  I have only
>>tweaked it by hand occasionally after creating it with SceneBuilder. SB
>>is an important selling point for JavaFX and should be included in the
>>JDK, it shouldn't even be a separate download.
>>
>>Scott
>>
>>> On Mar 5, 2015, at 3:19 AM, Tom Eugelink  wrote:
>>>
>>> My two cents would be that maintaining a UI builder is an awful lot of
>>>work, while I expect that a lot of programmers won't be using SB because
>>>it always has limitations. Either with complex layouts or custom
>>>controls. "Real" programmers probably use FXML directly or even just
>>>code it in Java. So the "return on investment" probably is fairly low
>>>and thus the resources can be much better spent on the core. IMHO.
>>>
>>>
 On 5-3-2015 02:34, Mike Hearn wrote:
 I agree that SB is probably something that can be well maintained by
the
 community at this point, especially with commercial backing from Gluon
>>>
>

Re: 8u40 is released

[Tomas Mikula]

On Wed, Mar 4, 2015 at 7:50 PM, Mike Hearn  wrote:
> WRT 8u60+9, I read that 8u60 is going to be a bug fix only release with no
> new features at all. I don't know how to read that, as JavaFX does not seem
> especially buggy to me,

2349 Unresolved Bugs seems buggy to me:
https://javafx-jira.kenai.com/issues/?jql=issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved

I personally don't mind if higher-level projects like SceneBuilder are
handed to the community, as long as Oracle keeps maintaining a healthy
and _portable_ core.

Re: 8u40 is released

[Tomas Mikula]

To add fuel to the fire, I have seen issues in the JIRA going from
"assigned" to "unassigned", for multiple assignees. Also, Steve is now
(back) at IBM: https://ca.linkedin.com/in/stevenorthover.

On Wed, Mar 4, 2015 at 5:32 PM, Tobias Bley  wrote:
> which future should it be? IoT?
>
>
>> Am 04.03.2015 um 23:29 schrieb Felix Bembrick :
>>
>> JavaFX has a future but perhaps not the one we were all expecting or hoping 
>> for.
>>
>> On 5 March 2015 at 09:18, Tobias Bley > > wrote:
>> In the past there were 2 bad signs from Oracle concerning JavaFX: end of 
>> support for JavaFX on RaspPi and SceneBuilder…
>>
>> So does have JavaFX a future?
>>
>> Tobi
>>
>>
>> > Am 04.03.2015 um 23:14 schrieb Mike Hearn > > >:
>> >
>> > That's great Johan, but .. what does this mean, exactly? Is SB
>> > effectively dead at this point? Short of some horrifically convoluted
>> > corporate politics I can't understand why Oracle would develop an
>> > application but not provide downloads of it. Does this mean SB won't be
>> > upgraded past 8u40?
>> >
>> > I mean - I don't think it's unreasonable of me to be surprised by this, and
>> > I thought I followed JFX development pretty closely. What's the story here?
>> >
>> > On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos > > > wrote:
>> >
>> >> Oracle stated that they won't release new binaries for SceneBuilder, but
>> >> since the code is open-source and BSD licensed, third parties and the Java
>> >> Community in general can create binaries based on the SceneBuilder 
>> >> sources.
>> >> This is what we did at Gluon (http://gluonhq.com ), 
>> >> and the result can be
>> >> downloaded at http://gluonhq.com/products/downloads/ 
>> >> 
>> >> This download is based on the latest 8u40 source code in OpenJFX. It
>> >> includes the 8u40 Controls (e.g. Spinner, Dialogs).
>> >>
>> >> Hope this is helpful.
>> >>
>> >> - Johan
>> >>
>> >> 2015-03-04 16:31 GMT+01:00 Mike Hearn > >> >:
>> >>
>> >>> Hi Kevin,
>> >>>
>> >>> Scene Builder source code is available in the OpenJFX repo under the BSD
>>  license, but separate binaries are no longer being released as of 8u40.
>> >>>
>> >>>
>> >>> I'm a bit confused what this means.
>> >>>
>> >>> People who want to use Scene Builder are expected to compile it 
>> >>> themselves
>> >>> from now on? Does that really make sense? Presumably the idea here is 
>> >>> that
>> >>> SB will be integrated into IDEs and will no longer have any purpose as a
>> >>> standalone app, but I'm not sure we're ready to go there yet - the last
>> >>> time I tried the SB integration into IntelliJ it was extremely basic and
>> >>> far below the experience of the dedicated app.
>> >>>
>> >>> As just one example, UI design benefits a lot from maximal screen space.
>> >>> IDE embeddings often don't provide that.
>> >>>
>> >>
>> >>
>>
>>
>

Re: Event when CSS is applied

[Tomas Mikula]

Hmm, my view is rather reverse to yours:
The fact that the implementation of layout is best solved with
inheritance is a sign that JavaFX does _not_ aim enough at doing
things via composition.

Tomas

On Wed, Feb 18, 2015 at 4:37 PM, Tom Eugelink  wrote:
>
>
> On 18-2-2015 21:49, Tomas Mikula wrote:
>>
>> So back to your original question:
>>
>>> Basically I would like to be informed when the styling of a node has been
>>> applied or changed. Is there some place that can provide this information?
>>
>> Turns out you don't actually need this information ;)
>>
>
>
> Indeed. Pattern learned.
>
> What does surprise me is that JavaFX aims at doing things via composition,
> that is why almost everything is final, and where the structure in my
> original code comes from. This turns out is best solved with inheritance.
>
> Tom
>

Re: Event when CSS is applied

[Tomas Mikula]

So back to your original question:

> Basically I would like to be informed when the styling of a node has been 
> applied or changed. Is there some place that can provide this information?

Turns out you don't actually need this information ;)

Regards,
Tomas

On Wed, Feb 18, 2015 at 3:20 PM, Tom Eugelink  wrote:
> I like the improvements to the code. Thanks!
>
> Tom

Re: Event when CSS is applied

[Tomas Mikula]

On Wed, Feb 18, 2015 at 2:32 PM, Tom Eugelink  wrote:
> On 18-2-2015 08:34, Tomas Mikula wrote:
>>
>> What I think should be done is, instead of trying to hack around Pane,
>> create class NeedlePane that extends Region and overrides
>> layoutChildren. It would create its children in the constructor (or
>> take them as constructor parameters), add them to its children list
>> right in the constructor and never clear them, and position them on
>> the layout pass (i.e. in layoutChildren).
>>
>
> Creating a DialPane is not such a problem, but creating a path only once and
> the only layout it turns out to be more of a challenge: the constructed but
> not yet correctly initialized path elements do not behave well with the
> rotate. It is an approach with merrit though, especially in resizing.

I meant my advice to apply only to Nodes. PathElements are not Nodes.
For example, there is no CSS applied to them, only to the containing
Path. I would just clear() and recreate them on each layout, if that
is simpler. Since they are not nodes (thus not part of the scene graph
by themselves), the comment about not modifying grand-children in
layoutChildren does not apply to them.

Best,
Tomas

>
> Tom

Re: Event when CSS is applied

[Tomas Mikula]

In case this information was buried in the previous email, maybe all
you need to better understand the problem is that layout() works
roughly* like this:

public final void layout() {
layoutChildren();
for(Node child: getChildren()) {
child.layout();
}
}

layoutChildren() just resizes and positions child nodes (only direct
children), it does not call layout() on them.
You do not (usually) call layout() directly, it is called on the root
node in the layout pass. Neither can you override layout(), it is
final.

* In reality, it first checks whether layout is needed at all. Also,
it only calls layout() on children that are Parents (other Nodes do
not have that method). And there's another piece that prevents
recursive calls to layout() on the same node.

On Wed, Feb 18, 2015 at 2:34 AM, Tomas Mikula  wrote:
> OK, so the major problem I see is that a lot of layout is done outside
> layoutChildren, using code like this:
>
> needlePane = new Pane();
> needlePane.widthProperty().addListener( (observable) -> {
> drawNeedlePane();
> });
>
> What I think should be done is, instead of trying to hack around Pane,
> create class NeedlePane that extends Region and overrides
> layoutChildren. It would create its children in the constructor (or
> take them as constructor parameters), add them to its children list
> right in the constructor and never clear them, and position them on
> the layout pass (i.e. in layoutChildren).
>
> The problem you have (or one of the problems) is that in the layout
> pass, when lStackPane sets the size of needlePane, drawNeedlePane() is
> triggered which clears needlePane's children (this is shortly after
> the CSS was applied to them, just before the layout pass that is
> currently in progress), then adds them quickly back, but without CSS
> applied.
>
> Another problem is that in Skin's layoutChilren, you are trying to
> layout grand-grand-children. You should only be laying out direct
> children. The code reads
>
> protected void layoutChildren(double arg0, double arg1, double arg2,
> double arg3) {
> super.layoutChildren(arg0, arg1, arg2, arg3);
> setValueText();
> scaleValueText();
> positionValueText();
> }
>
> This is what it does:
>
> super.layoutChildren() resizes and positions lStackPane. It does not
> call layout() on it yet.
>
> The rest of the methods are positioning grand-children of that lStackPane.
>
> When the layoutChildren call returns, layout() will be called on all
> children, i.e. on lStackPane. Within lStackPane.layout(),
> lStackPane.layoutChildren() is called, which sets the width and height
> of needlePane, which triggers drawNeedlePane() (if size changed),
> which clears the children and adds them back. When
> lStackPane.layoutChildren() returns, needlePane.layout() is called,
> within which needlePane.layoutChildren() is called. This is where you
> should do the layout for valueText.
>
> Hope this helps.
> Tomas
>
>
> On Wed, Feb 18, 2015 at 1:46 AM, Tom Eugelink  wrote:
>> Sure! I'm very curious what can be done better.
>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/internal/scene/control/skin/gauge/linear/SimpleMetroArcGaugeSkin.java
>>
>> You can also checkout the sources, you should be able to run
>> SimpleMetroArcGaugeTrial1.java without any other dependencies. Some of the
>> other classes will have compilation errors, but the gauge should run.
>>
>> Tom
>>
>>
>>
>> On 17-2-2015 23:15, Tomas Mikula wrote:
>>>
>>> Maybe if you can post the relevant part of your layoutChildren method
>>> so that others can look if they can suggest an improvement.
>>>
>>> Tomas
>>>
>>> On Tue, Feb 17, 2015 at 5:05 PM, Tom Eugelink  wrote:
>>>>
>>>> On 17-2-2015 20:01, David Grieve wrote:
>>>>>
>>>>> On 2/17/15 1:30 PM, Tom Eugelink wrote:
>>>>>>
>>>>>> The control is a codewise polish up one of Gerrit's gauges (with
>>>>>> permission!) and pulled into JFXtras (with tests and all). For an idea
>>>>>> on
>>>>>> what we are talking about:
>>>>>> https://www.youtube.com/watch?v=RH5X1uBu1d8
>>>>>>
>>>>>> The process of centering the Text in that circle is a bit more complex.
>>>>>> 1. The value may vary between a min and max value.
>>>>>> 2. I want the Text to automatically utilize the maximum available
>>>>>> space,
>>>>>> but not change size when a longer or shorter text is shown.
>>>>>>
>>>>

Re: Event when CSS is applied

[Tomas Mikula]

OK, so the major problem I see is that a lot of layout is done outside
layoutChildren, using code like this:

needlePane = new Pane();
needlePane.widthProperty().addListener( (observable) -> {
drawNeedlePane();
});

What I think should be done is, instead of trying to hack around Pane,
create class NeedlePane that extends Region and overrides
layoutChildren. It would create its children in the constructor (or
take them as constructor parameters), add them to its children list
right in the constructor and never clear them, and position them on
the layout pass (i.e. in layoutChildren).

The problem you have (or one of the problems) is that in the layout
pass, when lStackPane sets the size of needlePane, drawNeedlePane() is
triggered which clears needlePane's children (this is shortly after
the CSS was applied to them, just before the layout pass that is
currently in progress), then adds them quickly back, but without CSS
applied.

Another problem is that in Skin's layoutChilren, you are trying to
layout grand-grand-children. You should only be laying out direct
children. The code reads

protected void layoutChildren(double arg0, double arg1, double arg2,
double arg3) {
super.layoutChildren(arg0, arg1, arg2, arg3);
setValueText();
scaleValueText();
positionValueText();
}

This is what it does:

super.layoutChildren() resizes and positions lStackPane. It does not
call layout() on it yet.

The rest of the methods are positioning grand-children of that lStackPane.

When the layoutChildren call returns, layout() will be called on all
children, i.e. on lStackPane. Within lStackPane.layout(),
lStackPane.layoutChildren() is called, which sets the width and height
of needlePane, which triggers drawNeedlePane() (if size changed),
which clears the children and adds them back. When
lStackPane.layoutChildren() returns, needlePane.layout() is called,
within which needlePane.layoutChildren() is called. This is where you
should do the layout for valueText.

Hope this helps.
Tomas


On Wed, Feb 18, 2015 at 1:46 AM, Tom Eugelink  wrote:
> Sure! I'm very curious what can be done better.
> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/internal/scene/control/skin/gauge/linear/SimpleMetroArcGaugeSkin.java
>
> You can also checkout the sources, you should be able to run
> SimpleMetroArcGaugeTrial1.java without any other dependencies. Some of the
> other classes will have compilation errors, but the gauge should run.
>
> Tom
>
>
>
> On 17-2-2015 23:15, Tomas Mikula wrote:
>>
>> Maybe if you can post the relevant part of your layoutChildren method
>> so that others can look if they can suggest an improvement.
>>
>> Tomas
>>
>> On Tue, Feb 17, 2015 at 5:05 PM, Tom Eugelink  wrote:
>>>
>>> On 17-2-2015 20:01, David Grieve wrote:
>>>>
>>>> On 2/17/15 1:30 PM, Tom Eugelink wrote:
>>>>>
>>>>> The control is a codewise polish up one of Gerrit's gauges (with
>>>>> permission!) and pulled into JFXtras (with tests and all). For an idea
>>>>> on
>>>>> what we are talking about:
>>>>> https://www.youtube.com/watch?v=RH5X1uBu1d8
>>>>>
>>>>> The process of centering the Text in that circle is a bit more complex.
>>>>> 1. The value may vary between a min and max value.
>>>>> 2. I want the Text to automatically utilize the maximum available
>>>>> space,
>>>>> but not change size when a longer or shorter text is shown.
>>>>>
>>>>> To do this I have two additional Text nodes that have the same styling
>>>>> as
>>>>> the Text node (so these are on the scene, but not visible, otherwise
>>>>> CSS is
>>>>> not applied). These two text nodes get the maximum and minimum possible
>>>>> value set. Then on these two some pythagoras is applied and in that way
>>>>> one
>>>>> can determine the scale factor so that the value will never be rendered
>>>>> outside of the circle. Then the actual to-be-rendered value can be
>>>>> placed
>>>>> into the Text node and positioned in the centre of the circle.
>>>>>
>>>>> The problem is that a lot of these calculations depend on the CSS
>>>>> styling. What font is set? Bold or not? So I can only do these
>>>>> calculcation
>>>>> after the CSS has been applied. This unfortunately is not yet the case
>>>>> when
>>>>> the skin is instantiated. This means that if I do not used the
>>>>> layoutChildren, the initial presentation is totally off, untill the
>>>>> first
>>>>> min/max/value is set.
>>>>
>>>> Have you looked at the javadoc for Node#applyCss()?
>>>
>>>
>>> I did just now and tried calling that and layout when the skin is being
>>> instantiated, but apparently things are not setup right yet.
>>>
>>> Maybe layoutChildren with bound checking is the way to go.
>
>

Re: Event when CSS is applied

[Tomas Mikula]

Maybe if you can post the relevant part of your layoutChildren method
so that others can look if they can suggest an improvement.

Tomas

On Tue, Feb 17, 2015 at 5:05 PM, Tom Eugelink  wrote:
> On 17-2-2015 20:01, David Grieve wrote:
>>
>> On 2/17/15 1:30 PM, Tom Eugelink wrote:
>>>
>>> The control is a codewise polish up one of Gerrit's gauges (with
>>> permission!) and pulled into JFXtras (with tests and all). For an idea on
>>> what we are talking about:
>>> https://www.youtube.com/watch?v=RH5X1uBu1d8
>>>
>>> The process of centering the Text in that circle is a bit more complex.
>>> 1. The value may vary between a min and max value.
>>> 2. I want the Text to automatically utilize the maximum available space,
>>> but not change size when a longer or shorter text is shown.
>>>
>>> To do this I have two additional Text nodes that have the same styling as
>>> the Text node (so these are on the scene, but not visible, otherwise CSS is
>>> not applied). These two text nodes get the maximum and minimum possible
>>> value set. Then on these two some pythagoras is applied and in that way one
>>> can determine the scale factor so that the value will never be rendered
>>> outside of the circle. Then the actual to-be-rendered value can be placed
>>> into the Text node and positioned in the centre of the circle.
>>>
>>> The problem is that a lot of these calculations depend on the CSS
>>> styling. What font is set? Bold or not? So I can only do these calculcation
>>> after the CSS has been applied. This unfortunately is not yet the case when
>>> the skin is instantiated. This means that if I do not used the
>>> layoutChildren, the initial presentation is totally off, untill the first
>>> min/max/value is set.
>>
>> Have you looked at the javadoc for Node#applyCss()?
>
>
> I did just now and tried calling that and layout when the skin is being
> instantiated, but apparently things are not setup right yet.
>
> Maybe layoutChildren with bound checking is the way to go.

Re: Event when CSS is applied

[Tomas Mikula]

On Tue, Feb 17, 2015 at 1:30 PM, Tom Eugelink  wrote:
> The control is a codewise polish up one of Gerrit's gauges (with
> permission!) and pulled into JFXtras (with tests and all). For an idea on
> what we are talking about:
> https://www.youtube.com/watch?v=RH5X1uBu1d8
>
> The process of centering the Text in that circle is a bit more complex.
> 1. The value may vary between a min and max value.
> 2. I want the Text to automatically utilize the maximum available space, but
> not change size when a longer or shorter text is shown.
>
> To do this I have two additional Text nodes that have the same styling as
> the Text node (so these are on the scene, but not visible, otherwise CSS is
> not applied). These two text nodes get the maximum and minimum possible
> value set. Then on these two some pythagoras is applied and in that way one
> can determine the scale factor so that the value will never be rendered
> outside of the circle. Then the actual to-be-rendered value can be placed
> into the Text node and positioned in the centre of the circle.
>
> The problem is that a lot of these calculations depend on the CSS styling.
> What font is set? Bold or not? So I can only do these calculcation after the
> CSS has been applied. This unfortunately is not yet the case when the skin
> is instantiated. This means that if I do not used the layoutChildren, the
> initial presentation is totally off, untill the first min/max/value is set.

Maybe I was misunderstood. I didn't suggest not doing it in
layoutChildren. My conclusion was to keep doing it in layoutChildren
and not worry about repositioning the text too often.

Tomas

>
> So I would like to know when the CSS is applied to do the initial
> calculations. After that only when CSS, min or max changes is a
> recalculation required.
>
> Tom
>
>
>
>
> On 17-2-2015 19:05, Tomas Mikula wrote:
>>
>> Hi Tom,
>>
>> suppose you have such an event and can tell whether CSS of your Text
>> has changed. But is changed CSS the only time you want to re-position
>> the Text? I guess you also need to re-position it when the size of the
>> parent changes. I imagine the logic for determining whether you need
>> to re-position the Text or not can get quite complicated.
>>
>> Why is it a problem that you reposition the Text too often?
>>
>> I imagine, and someone please correct me if I'm wrong, that when you
>> ask for text.prefWidth(-1), you get a cached prefWidth from the last
>> call, if no properties of Text have changed since the last call to
>> prefWidth. I also suppose, and again correct me if I'm wrong, that if
>> you resizeRelocate the Text to the exact same position and size as it
>> already has, it does not incur any additional operations down the road
>> compared to not calling resizeRelocate at all. So my conclusion is
>> that repositioning the Text to the same place is not more expensive
>> than checking whether the Text needs to be repositioned.
>>
>> Regards,
>> Tomas
>>
>> On Tue, Feb 17, 2015 at 10:14 AM, Tom Eugelink  wrote:
>>>
>>> Registering to fontProperty works, but potentially requires a lot of
>>> listeners on every property that may affect the size, like effect, scale,
>>> etc. So I'm leaving it in layoutChildren for now; better once to many
>>> than
>>> not often enough.
>>>
>>> Would adding such an event be a big change?
>>>
>>>
>>>
>>>
>>> On 17-2-2015 14:50, David Grieve wrote:
>>>>
>>>>
>>>> On 2/17/15 8:02 AM, Tom Eugelink wrote:
>>>>>
>>>>> I have a skin (of a control) that centers a Text node. This Text node
>>>>> can
>>>>> be styled via CSS, so this styling is a factor when centering. because
>>>>> larger font means wider text.
>>>>>
>>>>> The centering works perfectly, the only problem is figuring out when to
>>>>> center the node. At the moment I'm centering the node on every
>>>>> layoutChildren call of the skin, but this is way to often, because
>>>>> after
>>>>> applying the CSS chances are very low that the node will need to be
>>>>> repositioned.
>>>>>
>>>>> Basically I would like to be informed when the styling of a node has
>>>>> been
>>>>> applied or changed. Is there some place that can provide this
>>>>> information?
>>>>>
>>>> Not in general, no. But you can add a listener to a property that is
>>>> styled by CSS and react to the change. You might add a listener to the
>>>> Text
>>>> node's fontProperty, for example. Clearly this isn't an all-purpose
>>>> solution. Another approach is to hold onto the bounds (or maybe just the
>>>> pref width and height) of the child node. If the old bounds doesn't
>>>> equal
>>>> the new bounds, then recenter.
>>>
>>>
>

Re: Event when CSS is applied

[Tomas Mikula]

Hi Tom,

suppose you have such an event and can tell whether CSS of your Text
has changed. But is changed CSS the only time you want to re-position
the Text? I guess you also need to re-position it when the size of the
parent changes. I imagine the logic for determining whether you need
to re-position the Text or not can get quite complicated.

Why is it a problem that you reposition the Text too often?

I imagine, and someone please correct me if I'm wrong, that when you
ask for text.prefWidth(-1), you get a cached prefWidth from the last
call, if no properties of Text have changed since the last call to
prefWidth. I also suppose, and again correct me if I'm wrong, that if
you resizeRelocate the Text to the exact same position and size as it
already has, it does not incur any additional operations down the road
compared to not calling resizeRelocate at all. So my conclusion is
that repositioning the Text to the same place is not more expensive
than checking whether the Text needs to be repositioned.

Regards,
Tomas

On Tue, Feb 17, 2015 at 10:14 AM, Tom Eugelink  wrote:
> Registering to fontProperty works, but potentially requires a lot of
> listeners on every property that may affect the size, like effect, scale,
> etc. So I'm leaving it in layoutChildren for now; better once to many than
> not often enough.
>
> Would adding such an event be a big change?
>
>
>
>
> On 17-2-2015 14:50, David Grieve wrote:
>>
>>
>> On 2/17/15 8:02 AM, Tom Eugelink wrote:
>>>
>>> I have a skin (of a control) that centers a Text node. This Text node can
>>> be styled via CSS, so this styling is a factor when centering. because
>>> larger font means wider text.
>>>
>>> The centering works perfectly, the only problem is figuring out when to
>>> center the node. At the moment I'm centering the node on every
>>> layoutChildren call of the skin, but this is way to often, because after
>>> applying the CSS chances are very low that the node will need to be
>>> repositioned.
>>>
>>> Basically I would like to be informed when the styling of a node has been
>>> applied or changed. Is there some place that can provide this information?
>>>
>> Not in general, no. But you can add a listener to a property that is
>> styled by CSS and react to the change. You might add a listener to the Text
>> node's fontProperty, for example. Clearly this isn't an all-purpose
>> solution. Another approach is to hold onto the bounds (or maybe just the
>> pref width and height) of the child node. If the old bounds doesn't equal
>> the new bounds, then recenter.
>
>

Re: Selection Events v. Focus Events - order is broken in JavaFX 8?

[Tomas Mikula]

Hi Scott,

whether that behavior is a bug in JavaFX 8 or not, why not commit on
focus lost *or* selection change? Less assumptions means more robust
code.

Regards,
Tomas

On Tue, Feb 10, 2015 at 10:15 AM, Scott Palmer  wrote:
> I have a custom field (my own formatted field done in JavaFX 2.2) bound to
> a property of the selected row in a TableView. My control commits an edit
> on focus lost.
>
> This works on JavaFX 2.2 but fails on JavaFX 8.  After a bit of debugging I
> discovered why. The way to reproduce the problem was to type something into
> the field and then select a different row in the table.   With JavaFX 2.2
> the edit is committed and then the control is populated with the data from
> the new selection.  With JavaFX 8, the selection change event happens prior
> to the focus lost event, so my control's data is replaced without being
> committed.
>
> This smells like a rather serious bug in JavaFX 8.  The TableView selection
> should not change as the result of a mouse click prior to the TableView
> getting the focus (and thus my control losing the focus and committing the
> edit to the selected item before the selection changes).
>
> Do you agree that this is broken behavior?
> Do you have an idea of how to work around it?
>
> Regards,
>
> Scott

Re: How to "apply" skin?

[Tomas Mikula]

Hi Werner,

the problem is that I am already doing it in layout: only in the
layout process of the parent node do I determine that I need to add
some more child nodes. So after adding them, I would like to have them
properly laid out in the current layout pass.

Tomas

On Mon, Feb 9, 2015 at 4:43 AM, Werner Lehmann
 wrote:
> Hi Tomas,
>
> I think the expected way of doing this is to defer the code which requires
> the control width until normal layout passes come across it. Or maybe not
> only defer that code but actually move it to layouting methods.
>
> Werner
>
>
> On 09.02.2015 00:51, Tomas Mikula wrote:
>>
>> Actually, I want skins to be applied in the whole sub-tree of a node.
>> The node itself may not be a control, but it may contain controls.

Re: How to "apply" skin?

[Tomas Mikula]

Actually, I want skins to be applied in the whole sub-tree of a node.
The node itself may not be a control, but it may contain controls.

On Sun, Feb 8, 2015 at 6:44 PM, Tomas Mikula  wrote:
> Hello list,
>
> after adding a node to the scene graph, how do I "apply" the skin to
> it, in case it is a Control? Something like an equivalent of
> applyCss() for skins.
>
> My use case is this:
> I add a node to the scene, and want to know its preferred width. So I
> call node.applyCss() to make sure CSS is applied, and then call
> node.prefWidth(-1). But for a (non-empty) Label, this still returns
> 0.0, presumably because there is no skin yet.
>
> I don't want to set a concrete skin using
> node.setSkin(node.createDefaultSkin()), because I want the node to
> have whatever skin would be applied to it, which could be different
> from the default skin.
>
> Thanks,
> Tomas

How to "apply" skin?

[Tomas Mikula]

Hello list,

after adding a node to the scene graph, how do I "apply" the skin to
it, in case it is a Control? Something like an equivalent of
applyCss() for skins.

My use case is this:
I add a node to the scene, and want to know its preferred width. So I
call node.applyCss() to make sure CSS is applied, and then call
node.prefWidth(-1). But for a (non-empty) Label, this still returns
0.0, presumably because there is no skin yet.

I don't want to set a concrete skin using
node.setSkin(node.createDefaultSkin()), because I want the node to
have whatever skin would be applied to it, which could be different
from the default skin.

Thanks,
Tomas

Re: Event Filtering

[Tomas Mikula]

On Fri, Feb 6, 2015 at 8:45 PM, Scott Palmer  wrote:
>
>> On Feb 6, 2015, at 8:21 PM, Tomas Mikula  wrote:
>>
>>> On Fri, Feb 6, 2015 at 7:33 PM, Scott Palmer  wrote:
>>> Is it possible to modify the event in an event filter or otherwise tweak
>>> the event that is ultimately received by the target?
>>>
>>> 
>
>>>
>>> There are no public constructors for KeyEvents,
>>
>> Are we looking at the same Javadoc?
>> http://docs.oracle.com/javase/8/javafx/api/javafx/scene/input/KeyEvent.html#KeyEvent-javafx.event.EventType-java.lang.String-java.lang.String-javafx.scene.input.KeyCode-boolean-boolean-boolean-boolean-
>>
>
> No. :-)
> I wanted to do this originally with Java 7
> The JavaFX 2.2 docs do not list any constructors.
>
>>>
>>> I suppose the 8u40 support for formatted fields is what should be used for
>>> my example, but the idea of tweaking the events before they are delivered
>>> to an event handler, or synthesizing a new event is more general.  Is it
>>> possible?
>>>
>>> Scott
>>
>> 1. So I think that you can proceed with what you have in mind: consume
>> an event and create and fire a new one (with Event.fireEvent(target,
>> event)), but I am afraid that is going to mess the order of events.
>> Suppose you type JavaFX *really* quickly (or when the UI thread is
>> busy with something else). IMO you end up with is JFXAVA instead of
>> JAVAFX.
>
> Yeah that would be a problem. I suppose I could be extra clever and remember 
> and consume the 'F' and 'X' events in my filter and then fire new ones after 
> I see my synthesized event come through.
> This is starting to smell though.
>
>>
>> 2. You could instead consume the event in the event filter and handle
>> it properly yourself, i.e. call textField.replaceSelection() and such.
>> (Not very nice, I know, I would not like reproducing TextField's
>> behavior.)
>
> Agreed.
>
>>
>> 3. I understand that you don't want some property to ever hold an
>> invalid value, but does it have to be the textProperty of the
>> textfield?
>
> It just makes things easier to use without the intermediate property and 
> temporary lowercase state on the textProperty, but yes that is one workaround.
>
>> If you set up your data flow like this:
>>
>> ObservableValue upper = EasyBind.map(textField.textProperty(),
>> String::toUpperCase)
>> upper.addListener((obs, oldVal, newVal) -> textField.setText(newVal));
>>
>> And then use `upper` wherever you used textField.textProperty()
>> before, the rest of your code will never observe any lowercase
>> characters.
>>
>> 4. Your idea of tweaking an event on its route is interesting, though.
>> Let's see if other people have some opinion about that.
>
> Perhaps a new kind of filter could simply return an event if it is meant to 
> be passed on, or return null to prevent it from going any further. Then I 
> would just return a different event than the one that was passed in if I 
> needed to tweak it.

Makes sense to me. I like this better than the side-effecting
consume() method. Better yet, return Optional.

> Perhaps returning an array of events would be more appropriate, then one 
> event could cause many downstream events.

I am not so sure about this. What use case do you have in mind?

Tomas

>
>
> Scott

Re: Event Filtering

[Tomas Mikula]

On Fri, Feb 6, 2015 at 7:33 PM, Scott Palmer  wrote:
> Is it possible to modify the event in an event filter or otherwise tweak
> the event that is ultimately received by the target?
>
> Let's say I have a TextField and I only want to allow typing of capital
> letters.  That is easy enough to enforce with an event filter.. if the
> KeyTyped event doesn't represent a capital letter I can consume it in an
> event filter and it won't get to the control.
>
> But let's say that I want to allow the user to type lowercase letters and
> have them appear in uppercase.  I don't ever want the text property of the
> TextField to hold a lowercase character.  Can that be done?
>
> There are no public constructors for KeyEvents,

Are we looking at the same Javadoc?
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/input/KeyEvent.html#KeyEvent-javafx.event.EventType-java.lang.String-java.lang.String-javafx.scene.input.KeyCode-boolean-boolean-boolean-boolean-

> and the fields are
> immutable.  So it doesn't seem like I can change the event that is
> delivered to the target.  (What are the copyFor(...) methods on Event used
> for?)

You don't need to worry about the copyFor methods, AFAIK they are used
only by the event dispatching mechanism. I think you need to implement
them if you define your own event type.

>
> I suppose the 8u40 support for formatted fields is what should be used for
> my example, but the idea of tweaking the events before they are delivered
> to an event handler, or synthesizing a new event is more general.  Is it
> possible?
>
>  Scott

1. So I think that you can proceed with what you have in mind: consume
an event and create and fire a new one (with Event.fireEvent(target,
event)), but I am afraid that is going to mess the order of events.
Suppose you type JavaFX *really* quickly (or when the UI thread is
busy with something else). IMO you end up with is JFXAVA instead of
JAVAFX.

2. You could instead consume the event in the event filter and handle
it properly yourself, i.e. call textField.replaceSelection() and such.
(Not very nice, I know, I would not like reproducing TextField's
behavior.)

3. I understand that you don't want some property to ever hold an
invalid value, but does it have to be the textProperty of the
textfield? If you set up your data flow like this:

ObservableValue upper = EasyBind.map(textField.textProperty(),
String::toUpperCase)
upper.addListener((obs, oldVal, newVal) -> textField.setText(newVal));

And then use `upper` wherever you used textField.textProperty()
before, the rest of your code will never observe any lowercase
characters.

4. Your idea of tweaking an event on its route is interesting, though.
Let's see if other people have some opinion about that.

Regards,
Tomas

Re: TableView API, no lazy retrieval of visible cell content possible?

[Tomas Mikula]

If the cells don't ever get removed from the scene, then I guess your
best bet is to start and cancel loading when the item changes, i.e.
listening to itemProperty(). This is similar to your original
updateItem() approach, but also don't forget to cancel loading of the
old item: cancel loading of the old item, if not null, and start
loading the new item, if not null. I don't think you can yourself do
much about the inefficiency that more cells than needed are created
and hold non-null items.

Let's see if others have something to suggest.

Tomas

On Tue, Jan 27, 2015 at 3:49 PM, Robert Krüger  wrote:
> Hi Tomas,
>
> When I do that, the property is never set to null. If I use it for
> triggering the loading (when it is set to a non-null value) it is set for a
> lot more rows than those actually visible. In my test with a model
> containing 200 items of which the first 4 were visible, it was set to
> non-null for the first 23 items.
>
> Am Dienstag, 27. Januar 2015 schrieb Tomas Mikula :
>
>> Hi Robert,
>>
>> instead of listening to visibleProperty(), listen to sceneProperty()
>> and cancel loading when scene becomes null.
>>
>> Tomas
>>
>> On Tue, Jan 27, 2015 at 1:16 PM, Robert Krüger 
>> wrote:
>> > Hi,
>> >
>> > either I don't see the forest for the trees or something is missing in
>> > the
>> > TableView API as I cannot seem to implement something that seems a
>> > common
>> > requirement and was rather easy (not pretty though) in Swing.
>> >
>> > Imagine an application like OSX finder in its list view, i.e. something
>> > that displays a possibly very long list of files and displays thumbnails
>> > for them generated on the fly. For many files (e.g. video files)
>> > extracting
>> > these thumbnails is an expensive operation and has to be performed in
>> > the
>> > background. My application does a very similar thing and uses a
>> > TableView.
>> > What I want is to begin extracting video thumbnails as soon as their
>> > corresponding table row has become visible. I have done that in Swing in
>> > the past without any problem (for more info, you can read
>> > https://community.oracle.com/message/12810930).
>> >
>> > With JavaFX I have tried the following:
>> >
>> > 1) Trigger loading the thumbnail in the table cell when it is updated
>> > and
>> > the corresponding thumbnail isn't already there
>> >
>> > Result: Triggering works more or less as desired but how do I stop the
>> > loading process if the cell becomes invisible? If the user quickly
>> > scrolls
>> > through a large number of rows and puts tons of thumbnail loading jobs
>> > on
>> > the queue I have not found a way to dequeue them, so this is unusable. I
>> > added output to the calls to the update method of the TableCell to see
>> > which instances are used and how their data is reset but the pattern I
>> > see
>> > is not suitable for deciding which cell is currently visible.
>> >
>> > 2) Register a change listener to the TableCell’s visible property to
>> > make
>> > that control the image loading.
>> >
>> > Result: I don’t seem to get any change events when I do that, so it does
>> > not work at all for my purpose.
>> >
>> > I see no public API in table view to explicitly compute the items
>> > visible
>> > in the current viewport either. What am I missing. It can't be an
>> > oversight
>> > in the API design, as the thing, I am trying to achieve appears rather
>> > basic.
>> >
>> > Thanks in advance for any hints,
>> >
>> > Robert
>
>
>
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
>
> www.lesspain-software.com
>

Re: TableView API, no lazy retrieval of visible cell content possible?

[Tomas Mikula]

Hi Robert,

instead of listening to visibleProperty(), listen to sceneProperty()
and cancel loading when scene becomes null.

Tomas

On Tue, Jan 27, 2015 at 1:16 PM, Robert Krüger  wrote:
> Hi,
>
> either I don't see the forest for the trees or something is missing in the
> TableView API as I cannot seem to implement something that seems a common
> requirement and was rather easy (not pretty though) in Swing.
>
> Imagine an application like OSX finder in its list view, i.e. something
> that displays a possibly very long list of files and displays thumbnails
> for them generated on the fly. For many files (e.g. video files) extracting
> these thumbnails is an expensive operation and has to be performed in the
> background. My application does a very similar thing and uses a TableView.
> What I want is to begin extracting video thumbnails as soon as their
> corresponding table row has become visible. I have done that in Swing in
> the past without any problem (for more info, you can read
> https://community.oracle.com/message/12810930).
>
> With JavaFX I have tried the following:
>
> 1) Trigger loading the thumbnail in the table cell when it is updated and
> the corresponding thumbnail isn't already there
>
> Result: Triggering works more or less as desired but how do I stop the
> loading process if the cell becomes invisible? If the user quickly scrolls
> through a large number of rows and puts tons of thumbnail loading jobs on
> the queue I have not found a way to dequeue them, so this is unusable. I
> added output to the calls to the update method of the TableCell to see
> which instances are used and how their data is reset but the pattern I see
> is not suitable for deciding which cell is currently visible.
>
> 2) Register a change listener to the TableCell’s visible property to make
> that control the image loading.
>
> Result: I don’t seem to get any change events when I do that, so it does
> not work at all for my purpose.
>
> I see no public API in table view to explicitly compute the items visible
> in the current viewport either. What am I missing. It can't be an oversight
> in the API design, as the thing, I am trying to achieve appears rather
> basic.
>
> Thanks in advance for any hints,
>
> Robert

Re: Make TableView height match content

[Tomas Mikula]

On Wed, Jan 7, 2015 at 11:49 AM, Werner Lehmann
 wrote:
> Hi Dan,
>
> typically it is not a good idea to do this. TableView has a reason to manage
> scrolling on its own: if the tableview has 10 items you don't want to
> have all these nodes in the scenegraph when it is sufficent to show the
> visible ones.

On that note, it would be interesting to explore the idea of managing
TableView's (ListView's, TreeView's) scroll by its parent (e.g. a
parent ScrollPane) while still keeping the content virtualized. It's
not unreasonable to ask for, and not impossible either. It's just not
how things are right now.

Tomas

Re: Scrollbars on *View or better VirtualFlow based UI elements

[Tomas Mikula]

Hi Werner,

On Mon, Dec 15, 2014 at 4:35 PM, Werner Lehmann
 wrote:
> Hi Tomas,
>
> On 15.12.2014 16:10, Tomas Mikula wrote:
>>
>> To add an idea, semi-transparent scrollbars could be shown over the
>> content when the mouse approaches the edge. This would avoid
>> flickering andto save space at the same time. I realize one could not
>> use this if the scrollbars would cover some interactive controls at
>> the edge of the content.
>
>
> Sounds similar to invisible scrollbars which appear on hover only.
> Personally I don't like either one. I guess it is a matter of taste. In a
> touch scenario it is a bit of problem though because usually you cannot rely
> on hover events.

Show scrollbars on hover might be even a better idea. On a touch
device, scrollbars could be shown after an initial tiny scroll by
swipe.

>> Also, I would like to see some new creative way of scrolling the
>> content, especially for cases when the full length of the content is
>> not known, e.g. a ListView with variable cell sizes, or a possibly
>> infinite stream of items that are loaded as needed. In these cases,
>> the scrollbar length always lies about the actual total length of the
>> content.
>
>
> If you have variable cell sizes an easy way to map this to a scrollbar is to
> use the number of items, possibly with some adjustments involving the height
> of the known cells. From my impression this is what virtual flow does but I
> could be wrong.

My point was that any such mapping to a scrollbar is only an estimate
of the total content length. So why bother trying to indicate the
total length by a scroll bar at all.

> An infinite stream of items can be scrolled with the "Google Picasa" light
> table approach. You can find an implementation of this concept in
> ControlsFX, see the PlusMinusSlider control.

Thanks, I wasn't aware of PlusMinusSlider.

Best,
Tomas

Re: Scrollbars on *View or better VirtualFlow based UI elements

[Tomas Mikula]

To add an idea, semi-transparent scrollbars could be shown over the
content when the mouse approaches the edge. This would avoid
flickering andto save space at the same time. I realize one could not
use this if the scrollbars would cover some interactive controls at
the edge of the content.

Also, I would like to see some new creative way of scrolling the
content, especially for cases when the full length of the content is
not known, e.g. a ListView with variable cell sizes, or a possibly
infinite stream of items that are loaded as needed. In these cases,
the scrollbar length always lies about the actual total length of the
content.

Regards,
Tomas

On Mon, Dec 15, 2014 at 2:23 PM, Tom Schindl
 wrote:
> Hi,
>
> The constant hiding of the horizontal (ListView & TreeView) and vertical
> (TreeView) makes the interaction with the control very noisy because the
> viewport size always changes e.g. when expanding & collapsing and or
> e.g. scrolling a list with cells of different sizes.
>
> The native UI-Toolkits (at least OS-X and IIRC) don't do this and always
> reserve a scrollbar area which makes interacting with the control IMHO a
> lot better.
>
> I looked into VirtualFlow to see if I could hack myself (via reflection)
> into it and make the scrollbars show up all time but unless I've looked
> at the wrong places I could not find anything I could do. Am I right?
> What do others think?
>
> Tom
>
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Permutation of scene graph children

[Tomas Mikula]

Hi Werner,

On Tue, Dec 2, 2014 at 11:50 AM, Werner Lehmann
 wrote:
> Tom,
>
> I know about Collections.swap but it looks like a bad idea to use on scene
> graph children because it seems to temporarily have a duplicate element in
> the list and I can't have a node twice in the scene graph. The setAll
> approach is what I am using now but native permutation or swap support would
> be better because it does not remove/add nodes, triggering CSS and possibly
> some listeners on scene or parent properties.

note that if JavaFX is ever going to support CSS selectors like
:first-child, :nth-child(), etc., it will be necessary to re-apply CSS
even for a permutation.

Regards,
Tomas

Re: How do I find out why the render loop is running?

[Tomas Mikula]

> BTW animatedBind is a useful utility. It makes it much easier to make cool
> animations that adjust as the data model changes. Here it is:
>
> https://gist.github.com/mikehearn/f639176566d735b676e7
>
> Something like that should be in the framework really.

Nice indeed.

Re: How do I find out why the render loop is running?

[Tomas Mikula]

Okay :)

So you are using opacityProperty() and not visibleProperty(), so my
exact workaround would not work anyway. A nice thing about that kind
of workaround though is that you would have the workaround in one
place and once you remove it, the compiler points you to all other
places you need to edit. But since the places you need to edit
independently are exactly 2, it's not that bad :)

Tomas

On Sat, Oct 4, 2014 at 12:16 AM, Mike Hearn  wrote:
> Oh well the hacks aren't so bad :-)
>
> Hack 1:
>
>
> animatedBind(loadingIndicatorArea,
> loadingIndicatorArea.opacityProperty(),
> when(isLoading).then(1.0).otherwise(0.0));
> // Hack around a bug in jfx: progress indicator leaks the spinner
> animation even if it's invisible so we have
> // to forcibly end the animation here to avoid burning cpu.
> loadingIndicator.progressProperty().bind(
>
> when(loadingIndicatorArea.opacityProperty().greaterThan(0.0)).then(-1).otherwise(0)
> );
>
>
> Hack 2:
>
>
> if (syncItem != null) {
> // Hack around JFX progress animator leak bug.
> GuiUtils.runOnGuiThreadAfter(500, () -> {
> syncItem.cancel();
> syncItem = null;
> });
> }
>
>
> The runOnGuiThreadAfter() call can just be removed once the bug is resolved.
> No big deal. It was finding all the leaks that was the painful part, and
> figuring out what combination of things would make the animations stop.
> Finding the receivers array and figuring out how to trace the object graph
> back to the widgets causing them was the breakthrough.

Re: How do I find out why the render loop is running?

[Tomas Mikula]

This is just a tip: until the bug is fixed, you can use a subclass of
ProgressBar like the one below to avoid "a bunch of hacks".

class MyProgressBar extends ProgressBar {
private final DoubleProperty myProgress = new SimpleDoubleProperty();
public DoubleProperty myProgressProperty() { return myProgress; }
public void setMyProgress(double progress) { myProgress.set(progress); }

public MyProgressBar() {
progressProperty().bind(

Bindings.when(Bindings.isNotNull(sceneProperty()).and(visibleProperty()))
.then(myProgress)
.otherwise(0);
);
}
}

You will have to change setProgress() and progressProperty() in your
code to setMyProgress() and myProgressProperty(). The good thing is
that if you forget to replace setProgress() by setMyProgress(), you
will get an error, because progressProperty() is now bound, so you
cannot set() it.

Hope this gets your code clarity close to the original level.

Note, however, that this will not work if a parent is made invisible.
You would need some more logic for that, unless there is an easy way
to determine whether a node is actually visible. Here is one approach
using EasyBind:

public static Binding nodeVisible(Node node) {
Binding parentVisible = EasyBind.monadic(node.parentProperty())
.flatMap(parent -> nodeVisible(parent))
.orElse(true);
return EasyBind.combine(parentVisible, node.visibleProperty(), (a,
b) -> a && b);
}

Best,
Tomas

On Fri, Oct 3, 2014 at 10:37 PM, Mike Hearn  wrote:
> Well, this was a pain in the ass. The cause is indeed
> ProgressBar/ProgressIndicator. It turns out that they can "leak" animations
> even when removed from the scene graph or their parents are made invisible.
> I filed:
>
> https://javafx-jira.kenai.com/browse/RT-38894
>
> I now have a bunch of hacks to set the progress bar/indicators I have to
> non-indeterminate when they're no longer visible or just before they are
> removed from the scene graph, to let them clean up. I don't know why this
> is required because I can see the code is trying to do the right thing, but
> for whatever reason it does not seem to work reliably.
>
> I figured out what's running by taking a look at
> Toolkit.getToolkit().getMasterTimer().receivers every so often. A healthy
> (idling) app that isn't using up battery should have just a single entry
> inside a button click handler. If there are more, it means the app is
> animating even if nothing on the screen is changing.

Re: How do I find out why the render loop is running?

[Tomas Mikula]

There might be some kind of infinite loop which is not apparent due to
asynchrony, such as recursive Platform.runLater

void foo() {
Platform.runLater(this::foo);
}

or an infinite loop in layout:

void layoutChildren() {
Platform.runLater(this::requestLayout);
}

On Tue, Sep 30, 2014 at 4:03 PM, Mike Hearn  wrote:
>>
>> 2) A control, such as a ProgressIndicator, that uses animation to display
>>> changes (even if the control is scrolled off the screen)
>>>
>> One common control animation that is easily overlooked is a text cursor,
>> which is animated to blink - when the control has focus.
>
>
> That would only cause one pulse per second or so, right?

Re: Accelerators - odd behavior

[Tomas Mikula]

On Sat, Sep 27, 2014 at 12:02 AM, Kevin Rushforth
 wrote:
> Can you add this information to the JIRA?
>
> https://javafx-jira.kenai.com/browse/RT-38830

I added it to https://javafx-jira.kenai.com/browse/RT-27602.

Tomas

>
> Thanks.
>
> -- Kevin
>
>
> Tomas Mikula wrote:
>>
>> Anyway, the algorithm used in KeyCharacterCombination looks odd to me.
>>
>> What it does is it tries to find a key code capable of producing the
>> character and then compares it to the event's key code.
>>
>> It would make more sense to me if it took the event, converted it to a
>> character it produced and then compare the characters.
>>
>> This way your first attempt to capture both MINUS and SUBTRACT with a
>> single KeyCharacterCombination("-") would work, as well as capturing
>> all of Shift-EQUALS, PLUS, ADD with a single
>> KeyCharacterCombination("+").
>>
>> Tomas
>>
>> On Fri, Sep 26, 2014 at 9:11 PM, Tomas Mikula 
>> wrote:
>>
>>>>
>>>> That doesn't explain why this isn't happening for PLUS.
>>>>
>>>
>>> KeyCodeCombination(KeyCode.PLUS, KeyCombination.CONTROL_DOWN)
>>>
>>> is never matched. It might even be impossible to get a KEY_PRESSED
>>> event with key code PLUS with English keyboard layout. When I switch
>>> keyboard layout to Slovak, which has the '+' sign accessible without
>>> Shift, I do get the runnable fired twice.
>>>
>>> Best,
>>> Tomas
>>>

Re: Accelerators - odd behavior

[Tomas Mikula]

Anyway, the algorithm used in KeyCharacterCombination looks odd to me.

What it does is it tries to find a key code capable of producing the
character and then compares it to the event's key code.

It would make more sense to me if it took the event, converted it to a
character it produced and then compare the characters.

This way your first attempt to capture both MINUS and SUBTRACT with a
single KeyCharacterCombination("-") would work, as well as capturing
all of Shift-EQUALS, PLUS, ADD with a single
KeyCharacterCombination("+").

Tomas

On Fri, Sep 26, 2014 at 9:11 PM, Tomas Mikula  wrote:
>> That doesn't explain why this isn't happening for PLUS.
>
> KeyCodeCombination(KeyCode.PLUS, KeyCombination.CONTROL_DOWN)
>
> is never matched. It might even be impossible to get a KEY_PRESSED
> event with key code PLUS with English keyboard layout. When I switch
> keyboard layout to Slovak, which has the '+' sign accessible without
> Shift, I do get the runnable fired twice.
>
> Best,
> Tomas

Re: Accelerators - odd behavior

[Tomas Mikula]

> That doesn't explain why this isn't happening for PLUS.

KeyCodeCombination(KeyCode.PLUS, KeyCombination.CONTROL_DOWN)

is never matched. It might even be impossible to get a KEY_PRESSED
event with key code PLUS with English keyboard layout. When I switch
keyboard layout to Slovak, which has the '+' sign accessible without
Shift, I do get the runnable fired twice.

Best,
Tomas

Re: Accelerators - odd behavior

[Tomas Mikula]

Here is a possible solution to Scott's original problem:


KeyCombination CtrlMinus = new KeyCombination(CONTROL_DOWN) {
@Override
public boolean match(KeyEvent event) {
return super.match(event)
&& event.getEventType() == KEY_PRESSED
&& (event.getCode() == MINUS || event.getCode() ==
SUBTRACT);
}
};

menuItem.setAccelerator(CtrlMinus);


On Fri, Sep 26, 2014 at 8:05 PM, Tomas Mikula  wrote:
> The cause of the problem seems clear to me. This is what I observe on
> my (Linux) system.
>
> Pressing '-' on the main part of the keyboard produces MINUS key code
> pressed. Pressing '-' on the numeric keypad produces SUBTRACT key code
> pressed.
>
> KeyCharacterCombination("-") matches MINUS pressed, but does not match
> SUBTRACT pressed (this is the part that may vary across systems, I
> think. If on Mac it match SUBTRACT and not MINUS, it explains the
> problem).
>
> So in Scott's test case, when I press ordinary minus, MINUS pressed
> event is fired, and both KeyCodeCombination(MINUS) and
> KeyCharacterCombination("-") match, so the runnable is executed twice.
>
> When, on the other hand, I pres minus on numeric keypad, SUBTRACT
> pressed event is fired, and only KeyCodeCombination(SUBTRACT) matches,
> so the runnable is executed only once.
>
> To test this explanation, can someone please run the following program
> on a Mac and post its output?
>
>
> import static javafx.scene.input.KeyCode.*;
> import static javafx.scene.input.KeyEvent.*;
> import javafx.application.Platform;
> import javafx.embed.swing.JFXPanel;
> import javafx.scene.input.KeyCharacterCombination;
> import javafx.scene.input.KeyEvent;
>
>
> public class KeyCodeForMinus {
>
> public static void main(String[] args) {
> new JFXPanel();
>
> KeyCharacterCombination minusChar = new KeyCharacterCombination("-");
> KeyEvent minusPressed = new KeyEvent(KEY_PRESSED, "", "",
> MINUS, false, false, false, false);
> KeyEvent subtractPressed = new KeyEvent(KEY_PRESSED, "", "",
> SUBTRACT, false, false, false, false);
>
> System.out.println("'-' matches MINUS: " +
> minusChar.match(minusPressed));
> System.out.println("'-' matches SUBTRACT: " +
> minusChar.match(subtractPressed));
>
> Platform.exit();
> }
>
> }
>
> On Fri, Sep 26, 2014 at 7:44 PM, Scott Palmer  wrote:
>> Please attach the test case I mailed earlier to the JIRA issue.
>>
>> On Fri, Sep 26, 2014 at 1:42 PM, Stephen F Northover <
>> steve.x.northo...@oracle.com> wrote:
>>
>>> Agree.  Suggest that we move the discussion to the JIRA to capture the
>>> background information for whoever will address the bug.
>>>
>>> Steve
>>>
>>>
>>> On 2014-09-26, 1:41 PM, Kevin Rushforth wrote:
>>>
>>>> It may or may not be a bug, but it will be good to investigate.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Stephen F Northover wrote:
>>>>
>>>>> Two on Windows, one on Mac.  See https://javafx-jira.kenai.com/
>>>>> browse/RT-38830
>>>>>
>>>>> Steve
>>>>>
>>>>> On 2014-09-26, 1:25 PM, Stephen F Northover wrote:
>>>>>
>>>>>> This is on Mac.  Will try Windows.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 2014-09-26, 1:24 PM, Kevin Rushforth wrote:
>>>>>>
>>>>>>> Is this on a Mac or on Windows?  I just ran your test case and I get
>>>>>>> two runnables, which is what I would expect.
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>> Stephen F Northover wrote:
>>>>>>>
>>>>>>>> I am only seeing the runnable fired once in FX 8u40.
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>> Steps:
>>>>>>>>
>>>>>>>> 1) Run TestKeyCombination
>>>>>>>> 2) Press Control+-
>>>>>>>>
>>>>>>>> Here is the test code:
>>>>>>>>
>>>>>>>> import javafx.application.Application;
>>>>>>>> import javafx.scene.Group;
>>>>>>

Re: Accelerators - odd behavior

[Tomas Mikula]

The cause of the problem seems clear to me. This is what I observe on
my (Linux) system.

Pressing '-' on the main part of the keyboard produces MINUS key code
pressed. Pressing '-' on the numeric keypad produces SUBTRACT key code
pressed.

KeyCharacterCombination("-") matches MINUS pressed, but does not match
SUBTRACT pressed (this is the part that may vary across systems, I
think. If on Mac it match SUBTRACT and not MINUS, it explains the
problem).

So in Scott's test case, when I press ordinary minus, MINUS pressed
event is fired, and both KeyCodeCombination(MINUS) and
KeyCharacterCombination("-") match, so the runnable is executed twice.

When, on the other hand, I pres minus on numeric keypad, SUBTRACT
pressed event is fired, and only KeyCodeCombination(SUBTRACT) matches,
so the runnable is executed only once.

To test this explanation, can someone please run the following program
on a Mac and post its output?


import static javafx.scene.input.KeyCode.*;
import static javafx.scene.input.KeyEvent.*;
import javafx.application.Platform;
import javafx.embed.swing.JFXPanel;
import javafx.scene.input.KeyCharacterCombination;
import javafx.scene.input.KeyEvent;


public class KeyCodeForMinus {

public static void main(String[] args) {
new JFXPanel();

KeyCharacterCombination minusChar = new KeyCharacterCombination("-");
KeyEvent minusPressed = new KeyEvent(KEY_PRESSED, "", "",
MINUS, false, false, false, false);
KeyEvent subtractPressed = new KeyEvent(KEY_PRESSED, "", "",
SUBTRACT, false, false, false, false);

System.out.println("'-' matches MINUS: " +
minusChar.match(minusPressed));
System.out.println("'-' matches SUBTRACT: " +
minusChar.match(subtractPressed));

Platform.exit();
}

}

On Fri, Sep 26, 2014 at 7:44 PM, Scott Palmer  wrote:
> Please attach the test case I mailed earlier to the JIRA issue.
>
> On Fri, Sep 26, 2014 at 1:42 PM, Stephen F Northover <
> steve.x.northo...@oracle.com> wrote:
>
>> Agree.  Suggest that we move the discussion to the JIRA to capture the
>> background information for whoever will address the bug.
>>
>> Steve
>>
>>
>> On 2014-09-26, 1:41 PM, Kevin Rushforth wrote:
>>
>>> It may or may not be a bug, but it will be good to investigate.
>>>
>>> -- Kevin
>>>
>>>
>>> Stephen F Northover wrote:
>>>
 Two on Windows, one on Mac.  See https://javafx-jira.kenai.com/
 browse/RT-38830

 Steve

 On 2014-09-26, 1:25 PM, Stephen F Northover wrote:

> This is on Mac.  Will try Windows.
>
> Steve
>
> On 2014-09-26, 1:24 PM, Kevin Rushforth wrote:
>
>> Is this on a Mac or on Windows?  I just ran your test case and I get
>> two runnables, which is what I would expect.
>>
>> -- Kevin
>>
>>
>> Stephen F Northover wrote:
>>
>>> I am only seeing the runnable fired once in FX 8u40.
>>>
>>> Steve
>>>
>>> Steps:
>>>
>>> 1) Run TestKeyCombination
>>> 2) Press Control+-
>>>
>>> Here is the test code:
>>>
>>> import javafx.application.Application;
>>> import javafx.scene.Group;
>>> import javafx.scene.Scene;
>>> import javafx.scene.control.Button;
>>> import javafx.scene.input.KeyCharacterCombination;
>>> import javafx.scene.input.KeyCode;
>>> import javafx.scene.input.KeyCodeCombination;
>>> import javafx.scene.input.KeyCombination;
>>> import javafx.stage.Stage;
>>>
>>> public class TestKeyCombination extends Application {
>>> public static void main(String[] args) {
>>> Application.launch(args);
>>> }
>>>
>>> @Override public void start(Stage stage) {
>>> stage.setTitle("Test KeyCombination");
>>> Scene scene = new Scene(new Group(), 600, 450);
>>> Button button1 = new Button();
>>> button1.setText("Click Me");
>>> stage.setScene(scene);
>>> stage.show();
>>>
>>> KeyCombination cmdMinus = new KeyCodeCombination(KeyCode.MINUS,
>>> KeyCombination.CONTROL_DOWN);
>>> KeyCombination cmdMinusFromCharacter = new
>>> KeyCharacterCombination("-", KeyCombination.CONTROL_DOWN);
>>> Runnable runnable = () -> System.out.println("HI");
>>> scene.getAccelerators().put(cmdMinus, runnable);
>>> scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
>>> }
>>> }
>>>
>>>
>>> On 2014-09-26, 1:01 PM, Scott Palmer wrote:
>>>
 KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
 KeyCombination.CONTROL_DOWN);
 KeyCombination cmdMinusFromCharacter = new
 Key*Character*Combination("-",
 KeyCombination.CONTROL_DOWN);

 Using the above like this:
 scene.getAccelerators().put(cmdMinus, runnable);
 scene.getAccelerators().put(cmdMinusFromCharacter, runnable);

 Will result in the

Re: Accelerators - odd behavior

[Tomas Mikula]

The explanation could be that on some systems the
KeyCharacterCombination("-").match picks the same key code as the one
produced by key press (e.g. MINUS), while on other systems it picks
the other one (SUBTRACT).

On Fri, Sep 26, 2014 at 7:24 PM, Kevin Rushforth
 wrote:
> Is this on a Mac or on Windows?  I just ran your test case and I get two
> runnables, which is what I would expect.
>
> -- Kevin
>
>
>
> Stephen F Northover wrote:
>>
>> I am only seeing the runnable fired once in FX 8u40.
>>
>> Steve
>>
>> Steps:
>>
>> 1) Run TestKeyCombination
>> 2) Press Control+-
>>
>> Here is the test code:
>>
>> import javafx.application.Application;
>> import javafx.scene.Group;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.input.KeyCharacterCombination;
>> import javafx.scene.input.KeyCode;
>> import javafx.scene.input.KeyCodeCombination;
>> import javafx.scene.input.KeyCombination;
>> import javafx.stage.Stage;
>>
>> public class TestKeyCombination extends Application {
>> public static void main(String[] args) {
>> Application.launch(args);
>> }
>>
>> @Override public void start(Stage stage) {
>> stage.setTitle("Test KeyCombination");
>> Scene scene = new Scene(new Group(), 600, 450);
>> Button button1 = new Button();
>> button1.setText("Click Me");
>> stage.setScene(scene);
>> stage.show();
>>
>> KeyCombination cmdMinus = new KeyCodeCombination(KeyCode.MINUS,
>> KeyCombination.CONTROL_DOWN);
>> KeyCombination cmdMinusFromCharacter = new
>> KeyCharacterCombination("-", KeyCombination.CONTROL_DOWN);
>> Runnable runnable = () -> System.out.println("HI");
>> scene.getAccelerators().put(cmdMinus, runnable);
>> scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
>> }
>> }
>>
>>
>> On 2014-09-26, 1:01 PM, Scott Palmer wrote:
>>>
>>> KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
>>> KeyCombination.CONTROL_DOWN);
>>> KeyCombination cmdMinusFromCharacter = new Key*Character*Combination("-",
>>> KeyCombination.CONTROL_DOWN);
>>>
>>> Using the above like this:
>>> scene.getAccelerators().put(cmdMinus, runnable);
>>> scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
>>>
>>> Will result in the runnable being fired twice from the same keypress.
>>>
>>> I propose changing the accelerator processing logic so that only one
>>> runnable gets called as the intention appears to be that a KeyCombination
>>> can only have one runnable associated with it, but the logic in Map
>>> doesn't
>>> see the above two KeyCombinations as the same key in the Map.
>>>
>>> Note: With the second combination above I really wanted something that
>>> worked for both MINUS and SUBTRACT simultaneously - since they both type
>>> the same Character and only one accelerator can be set on a MenuItem.
>>>
>>> Scott
>>
>>
>

Re: Accelerators - odd behavior

[Tomas Mikula]

Hi Kevin,


On Fri, Sep 26, 2014 at 7:16 PM, Kevin Rushforth
 wrote:
> It seems to me that this is working as designed. You have created two
> different KeyCombinations and asked that both fire your runnable. Further,
> both of the KeyCombinations match your key input since both a KeyPressed and
> a KeyTyped event are sent when pressing a key that has an associated
> character. I'm not sure how we could change it in a way that wouldn't be
> surprising or difficult to specify or document.

The Javadoc for KeyCharacterCombination#match also says

"This means that the method can return true only for KEY_PRESSED
andKEY_RELEASED events, but not for KEY_TYPED events, which don't have
valid key codes."

Thus it is probably not related to KEY_TYPED events.

Tomas

>
> -- Kevin
>
>
>
> Scott Palmer wrote:
>>
>> KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
>> KeyCombination.CONTROL_DOWN);
>> KeyCombination cmdMinusFromCharacter = new Key*Character*Combination("-",
>> KeyCombination.CONTROL_DOWN);
>>
>> Using the above like this:
>> scene.getAccelerators().put(cmdMinus, runnable);
>> scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
>>
>> Will result in the runnable being fired twice from the same keypress.
>>
>> I propose changing the accelerator processing logic so that only one
>> runnable gets called as the intention appears to be that a KeyCombination
>> can only have one runnable associated with it, but the logic in Map
>> doesn't
>> see the above two KeyCombinations as the same key in the Map.
>>
>> Note: With the second combination above I really wanted something that
>> worked for both MINUS and SUBTRACT simultaneously - since they both type
>> the same Character and only one accelerator can be set on a MenuItem.
>>
>> Scott
>>

Re: Accelerators - odd behavior

[Tomas Mikula]

Hi Scott,

On Fri, Sep 26, 2014 at 7:01 PM, Scott Palmer  wrote:
> Note: With the second combination above I really wanted something that
> worked for both MINUS and SUBTRACT simultaneously - since they both type
> the same Character and only one accelerator can be set on a MenuItem.

according to Javadoc for KeyCharacterCombination#match (which I was
recently reminded to read), this would not work anyway, since

"The key character of this object is first translated to the key code
which is capable of producing the character in the current keyboard
layout and then the resulting key code together with the modifier keys
are matched against the key code and key modifiers from the KeyEvent."

It seems it just arbitrarily picks whatever key code can produce the character.

Best,
Tomas

Re: Subclassing behavior in JavaFX Controls

[Tomas Mikula]

Hi Pete,

On Wed, Sep 17, 2014 at 9:57 PM, Tomas Mikula  wrote:
>
> I believe that overriding keyboard shortcuts should be doable without
> subclassing the skin (or behavior). I'm working on something right now
> and hope to publish something soon.

have a look at https://github.com/TomasMikula/WellBehavedFX. Does it
satisfy your keyboard handling needs?

Regards,
Tomas

Re: Subclassing behavior in JavaFX Controls

[Tomas Mikula]

Hi Pete,

On Wed, Sep 17, 2014 at 9:35 PM, Pete Moss  wrote:
> Tomas,
>
> Thanks for the fast reply.
>
> I read your blog post that you referenced and I agree with you 100%. I am a
> crusty MVC person and I agree, that having the Skin class (View) hold a
> reference to the Behavior class (Controller) rubs me the wrong way from an
> MVC perspective.
>
> I was looking at the JavaFX source code and trying to figure out the easiest
> source code path to a fix. But I agree with you that a slight redesign would
> be better to bring it closer to a purer MVC approach (to loosely quote
> General Jack D. Ripper, we must strive for a Purity Of Essence). ;)
>
> Doing what you propose would provide a much greater degree of flexibility to
> subclass the skin, behavior or both.
>
> I read the back and forth between you and Jonathan Giles on your blog post,
> and although I agree with you that a refactoring and restructuring would be
> better, I understand Jonathan's point of view, given that the horse is out
> of the barn with the current APIs and what you are proposing is a little
> more invasive.

The only thing that is out is SkinBase, which is an encapsulation of
both the View and the Controller. Whether and how you separate the
view and the controller within your instance of SkinBase is left
completely up to you, as far as the current public API goes. This
means it is not too late for a change. It is not even invasive:
current controls can keep using the private BehaviorSkinBase, or be
moved to the new solution gradually.

>
> Which brings me back to my post and my desires to subclass skin, behavior or
> both for existing JavaFX Controls. It seems impossible to subclass skin and
> behavior. Replace, yes, but not subclass (augment).

I believe that overriding keyboard shortcuts should be doable without
subclassing the skin (or behavior). I'm working on something right now
and hope to publish something soon.

Best,
Tomas

>
> Again, any suggestions for workarounds would be appreciated.
>
>
>
> On Wed, Sep 17, 2014 at 3:02 PM, Tomas Mikula 
> wrote:
>>
>> Hi Pete,
>>
>> work on this is tracked in https://javafx-jira.kenai.com/browse/RT-21598
>>
>> In terms of the current API, I think the best solution is to add event
>> handlers and/or event filters on the TableView.
>>
>> Regarding your proposed fixes, I have a blog post where I argue that
>> the wiring between the Behavior and the ("View" aspect of the) Skin
>> should be reversed, i.e. that the Behavior should hold a reference to
>> the View, not vice versa. That is, for example, against both your
>> proposed fixes. (Note that the blog post represents my personal view
>> only.)
>> http://tomasmikula.github.io/blog/2014/06/11/separation-of-view-and-controller-in-javafx-controls.html
>>
>> Incidendally, I'm currently working on a solution to add/override
>> keyboard shortcuts. I should be able to publish something soon.
>>
>> Best,
>> Tomas
>>
>> On Wed, Sep 17, 2014 at 8:36 PM, Pete Moss  wrote:
>> > I am starting to work with the TableView JavaFX Control. I see that it
>> > has
>> > some nominal keyboard handling, but it is incomplete for my needs. From
>> > what I understand about the JavaFX Control architecture, all of the
>> > JavaFX
>> > Control-derived classes use a Skin class created via
>> > Control.createDefaultSkin() which, in turn, contains a behavior class
>> > that
>> > is derived from BehaviorSkinBase.
>> >
>> > However, an Oracle publication says that Control developers should NOT
>> > use
>> > BehaviorSkinBase since that is a private API.
>> >
>> > So here is the problem. I am trying to augment the behavior of the
>> > TableView class. The keyboard handling is done in TableViewBehavior so
>> > it
>> > would be nice for me to supply a subclassed version of TableViewBehavior
>> > to
>> > augment that behavior or override some of it. But I can't. If you look
>> > at
>> > the TableViewSkin class, here is the ctor that gets used:
>> >
>> > public TableViewSkin(final TableView tableView) {
>> > super(tableView, new TableViewBehavior(tableView));
>> >
>> >...
>> >}
>> >
>> > Because this is the only ctor available for TableViewSkin, I don't see
>> > any
>> > way I can subclass TableViewSkin and supply my own behavior instance. I
>> > can, of course, create my own skin, but then I would lose the code in
>> > TableViewSkin (unless I shamelessly copied it, which I don

Re: Subclassing behavior in JavaFX Controls

[Tomas Mikula]

Hi Pete,

work on this is tracked in https://javafx-jira.kenai.com/browse/RT-21598

In terms of the current API, I think the best solution is to add event
handlers and/or event filters on the TableView.

Regarding your proposed fixes, I have a blog post where I argue that
the wiring between the Behavior and the ("View" aspect of the) Skin
should be reversed, i.e. that the Behavior should hold a reference to
the View, not vice versa. That is, for example, against both your
proposed fixes. (Note that the blog post represents my personal view
only.) 
http://tomasmikula.github.io/blog/2014/06/11/separation-of-view-and-controller-in-javafx-controls.html

Incidendally, I'm currently working on a solution to add/override
keyboard shortcuts. I should be able to publish something soon.

Best,
Tomas

On Wed, Sep 17, 2014 at 8:36 PM, Pete Moss  wrote:
> I am starting to work with the TableView JavaFX Control. I see that it has
> some nominal keyboard handling, but it is incomplete for my needs. From
> what I understand about the JavaFX Control architecture, all of the JavaFX
> Control-derived classes use a Skin class created via
> Control.createDefaultSkin() which, in turn, contains a behavior class that
> is derived from BehaviorSkinBase.
>
> However, an Oracle publication says that Control developers should NOT use
> BehaviorSkinBase since that is a private API.
>
> So here is the problem. I am trying to augment the behavior of the
> TableView class. The keyboard handling is done in TableViewBehavior so it
> would be nice for me to supply a subclassed version of TableViewBehavior to
> augment that behavior or override some of it. But I can't. If you look at
> the TableViewSkin class, here is the ctor that gets used:
>
> public TableViewSkin(final TableView tableView) {
> super(tableView, new TableViewBehavior(tableView));
>
>...
>}
>
> Because this is the only ctor available for TableViewSkin, I don't see any
> way I can subclass TableViewSkin and supply my own behavior instance. I
> can, of course, create my own skin, but then I would lose the code in
> TableViewSkin (unless I shamelessly copied it, which I don't want to do).
>
> It seems to me there could be a couple of different ways to fix this:
> 1) Add an alternative ctor that takes a behavior instance as a second
> argument. Then refactor the original ctor to call this, eg,
> public TableViewSkin(final TableView tableView, BehaviorSkinBase
> behavior) {
> super(tableView, behavior);
>
>...
>}
>
>public TableViewSkin(final TableView tableView) {
> this(tableView, new TableViewBehavior(tableView));
>}
>
> 2) Add a factory method for the behavior instance:
> public TableViewSkin(final TableView tableView) {
>BehaviorSkinBase behavior = behaviorFactory(tableView);
>
>super(tableView, behavior);
>
>...
>}
>
> protected BehaviorSkinBase behaviorFactory(TableView tableView)
> {
>return new TableViewBehavior(tableView);
> }
>
> I see this as a shortcoming in the JavaFX architecture. If I were building
> a custom Control, it would not be so bad since I would provide an
> additional Skin ctor that takes a behavior class as an arg, but it seems
> that the way the code is currently structured, it is difficult to subclass
> a JavaFX Control and subclass its skin and behavior too.
>
> Any thoughts on how to workaround/solve this would be greatly appreciated.

Re: Does JavaFX lack a public Property.getObservable() method?

[Tomas Mikula]

Hi Randahl,

if on button click you only want to update an external boolean
property, bidirectional binding suggested by Martin should be all you
need.

If the problem is more complex, it might be useful to recognize that
your toggle button serves two distinct functions:
1. It reflects the state (on/off) of an external object.
2. It manipulates an external object.

Treat these functions separately, i.e. on button click, don't change
the button value (and thus appearance) directly, but manipulate the
observed object.

// observe external object
button.valueProperty().bind(externalObject.stateProperty());

// manipulate external object
button.setOnAction(event -> {
if(button.getValue()) {
externalObject.turnOff();
} else {
externalOBject.turnOn();
}
});

Your original button behavior of just changing the value (and thus
appearance) is achieved by

button.setOnAction(event -> button.setValue(!button.getValue()));

Best,
Tomas

On Fri, Sep 12, 2014 at 1:08 PM, Martin Sladecek
 wrote:
> Hi Randahl,
> why don't you use bidirectional binding for this purpose?
>
> -Martin
>
>
> On 09/12/2014 01:04 PM, Randahl Fink Isaksen wrote:
>>
>> I have noticed the lack of a getObservable() method of the property class,
>> and I have come across a use case which might justify such a method, so I
>> would like to discuss whether posting a new Jira issue for this is
>> justified.
>>
>> I have implemented a simple toggle button with two states, on and off. The
>> toggle button has a SimpleBooleanProperty value, and when the user switches
>> the toggle button the value is negated.
>>
>> Now, in some cases I would like to bind the valueProperty to some
>> observable boolean in my app, so that whenever that observable boolean is
>> true, the button reflects that by switching to on. However, the problem is
>> that if I bind the SimpleObjectProperty value to an observable boolean
>> value, and then click the button to toggle it, a JavaFX exception tells me
>> that I cannot negate the boolean value, since it is now bound.
>>
>> In such cases, I think it makes sense to have my toggle button change the
>> state of the value it is bound to instead. But since the
>> SimpleBooleanProperty does not have a getObservable() method, I have no way
>> of accessing the value observed.
>>
>> Does this justify adding a public getObservable method to class Property?
>>
>> Yours
>>
>> Randahl
>>
>>
>>
>

Re: CSS: Use "none" or "null"?

[Tomas Mikula]

Thanks for the quick answer.

Tomas

On Tue, Aug 26, 2014 at 10:24 PM, David Grieve  wrote:
> Either one.
>
>
> On 8/26/14, 4:21 PM, Tomas Mikula wrote:
>>
>> Just a quick question: Which one is correct,
>>
>>  -fx-fill: none;
>>
>> or
>>
>>  -fx-fill: null;
>>
>> ?
>>
>> Thanks,
>> Tomas
>
>

CSS: Use "none" or "null"?

[Tomas Mikula]

Just a quick question: Which one is correct,

-fx-fill: none;

or

-fx-fill: null;

?

Thanks,
Tomas

Re: Request to allow anonymous user access to Jira.

[Tomas Mikula]

Brian Beck  writes:

>
> Hi John:
>
> It's a reasonable idea and one that we're actually discussing right
> now.  There are related issues to consider which may take some time to
> sort out but I would hope to have it all figured out in a month or so.
> Will keep the list posted.
>
> Brian.  (JIRA guy)

Any progress on this?

Regards,
Tomas

>
> On 1/27/14 11:00 AM, John Smith wrote:
> > I'd like to be able to access Jira without logging in.
> > Such anonymous access would have limited privileges (for example only
able to view existing public issues).
> > I know such access has been requested before on this mailing list, but I
don't recall any response on why it
> has not been provided.
> >
> > The benefits of anonymous access to Jira are:
> >1. Search engines can index the information in Jira.
> >2. Lower barrier of entry for casual users to view the state of
issues in Jira.
> >
> > I don't really see any potential drawbacks to adding anonymous access to
Jira.
> >
> > Regards,
> > John
>
>

Re: Overhead for table columns.

[Tomas Mikula]

I like this kind of being wrong :-)

Tomas

On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles
 wrote:
> Actually this is slightly wrong. I was holding off replying until I had a
> bit more time to be thorough, but I'll respond now to prevent this
> misunderstanding from being discussed :-)
>
> It _is_ possible to virtualise the TableView in both directions. This
> doesn't necessarily help with the overhead entirely, but it should help
> substantially. I might be forgetting some important element as I have not
> referred back to the code, but I believe that the only thing that is
> necessary is for the developer to set a fixed cell size on the TableView
> (via TableView#setFixedCellSize). When this happens, the TableView can 1)
> reduce enormously the amount of computations it has to do for layout and 2)
> virtualise the columns. I suspect 2 is your primary goal, but 1 shouldn't be
> underestimated given the enormity of your table.
>
> Sean, it would be interesting if you could send me a sample application that
> demonstrates your problem. I am always trying to optimise these virtualised
> controls and would appreciate adding your specific use case to my suite of
> tests.
>
> Thanks,
>
> -- Jonathan
>
>
> On 15/08/2014 10:35 a.m., Tomas Mikula wrote:
>>
>> On Thu, Aug 14, 2014 at 9:01 PM, Sean True  wrote:
>>>
>>> We've been looking at very large tables for use in data grid display.
>>>
>>> Row count scales very nicely indeed, but column count is much more
>>> problematic.
>>
>> To explain your observation: TableView is based on VirtualFlow, which
>> optimizes the number of cells simultaneously attached to the scene
>> graph in one direction (horizontal or vertical). For TableView,
>> vertical VirtualFlow is used, which means rows are optimized
>> (invisible rows are not in the scene graph), while all columns for
>> each visible row are in the scene graph.
>>
>> To be able to scroll smoothly through the table, you would want a
>> two-dimensional virtual flow. You can look at VirtualFlow.java from
>> OpenJFX or from my alternative virtual flow implementation Flowless
>> [1] to get an idea about the complexity of the one-dimensional case.
>>
>> If you don't require smooth scrolling and are fine with scroll by one
>> row/column at a time, you could display a small table with fixed cell
>> count, say 30x20 (maybe calculated dynamically based on the available
>> area), and display your own scrollbars that will update the data model
>> behind this small table. Not the best solution, but much less work.
>>
>> Regards,
>> Tomas
>>
>> [1] https://github.com/TomasMikula/Flowless
>>
>>> In the March time frame, our tests showed that each column had
>>> approximately 100KB overhead (using VisualVM), which is negligible at 100
>>> columns, but at 10,000 columns becomes an issue. We have real world use
>>> cases of more columns than that .
>>>
>>> Is there planned effort to reduce the overhead, or are we looking at
>>> likely
>>> having to build our own table component to serve these large needs?
>>>
>>> -- Sean
>
>

Re: Overhead for table columns.

[Tomas Mikula]

On Thu, Aug 14, 2014 at 9:01 PM, Sean True  wrote:
> We've been looking at very large tables for use in data grid display.
>
> Row count scales very nicely indeed, but column count is much more
> problematic.

To explain your observation: TableView is based on VirtualFlow, which
optimizes the number of cells simultaneously attached to the scene
graph in one direction (horizontal or vertical). For TableView,
vertical VirtualFlow is used, which means rows are optimized
(invisible rows are not in the scene graph), while all columns for
each visible row are in the scene graph.

To be able to scroll smoothly through the table, you would want a
two-dimensional virtual flow. You can look at VirtualFlow.java from
OpenJFX or from my alternative virtual flow implementation Flowless
[1] to get an idea about the complexity of the one-dimensional case.

If you don't require smooth scrolling and are fine with scroll by one
row/column at a time, you could display a small table with fixed cell
count, say 30x20 (maybe calculated dynamically based on the available
area), and display your own scrollbars that will update the data model
behind this small table. Not the best solution, but much less work.

Regards,
Tomas

[1] https://github.com/TomasMikula/Flowless

>
> In the March time frame, our tests showed that each column had
> approximately 100KB overhead (using VisualVM), which is negligible at 100
> columns, but at 10,000 columns becomes an issue. We have real world use
> cases of more columns than that .
>
> Is there planned effort to reduce the overhead, or are we looking at likely
> having to build our own table component to serve these large needs?
>
> -- Sean

Re: Calculating the preferred size of a node before layout takes place?

[Tomas Mikula]

If you are interested in the preferred height, prefHeight(-1) should
get you what you want. If this is before the first layout pass takes
place, you will also want to call applyCss() before prefHeight(-1).

Note: prefHeight(-1) is what autosize() calls internally, but it does
not call applyCss().

On Mon, Aug 4, 2014 at 9:29 PM, Jeff Martin  wrote:
> I was thinking that certain nodes (e.g., TextField) won’t provide a valid 
> pref size until the window was made visible (and the CSS had been evaluated).
>
> A few times I’ve added code set Window Opacity to zero, do a Window 
> show/hide, then reset Window Opacity to one. Then you should get valid pref 
> sizes. I’m not proud of myself, but it seems to work in practice. :-)
>
> jeff
>
>
> On Aug 4, 2014, at 1:03 PM, Richard Bair  wrote:
>
>> autosize() on Node may be what you want (sizes it then afterward you can 
>> read values)?
>>
>> On Aug 4, 2014, at 10:56 AM, Mike Hearn  wrote:
>>
>>> I'd like to find the calculated height of a node in my window controllers
>>> initialise() method, so I can shrink the height to zero and then animate it
>>> to the right size later. However getHeight and getPrefHeight both return
>>> zero in this method, presumably because it's not been laid out yet.
>>>
>>> I tried calling layout() but that didn't help.
>>>
>>> I don't want any visual glitches caused by a node being visible and then
>>> immediately resized to invisibility. Is there a solution to my problem? I
>>> feel there must be an obvious one that I'm just overlooking somehow ...
>>>
>>> thanks!
>>
>

Re: How to pause service when it's not visible in TabPane

[Tomas Mikula]

On Thu, Jul 31, 2014 at 12:51 AM, Tomas Mikula  wrote:
> I'm not sure I understand: you have many service subclasses, each of
> them associated with a tab? If so, they can take the tab as an
> argument to the constructor:
>
> abstract class TabService extends Service {
> protected MyAbstractService(Tab tab) {

This should have been

protected TabService(Tab tab) {

> tab.selectedProperty().addListener((obs, old, selected) -> {
> if(selected) {
> restart();
> } else {
> cancel();
> }
> });
> }
> }
>
> class FooService extends TabService {
> public FooService(Tab tab) {
> super(tab);
> }
> }
>
> Alternatively, you can have a Tab subclass that takes Service as
> constructor argument.
>
> Alternatively, you can have a static helper method that binds the
> service to the tab and use it from any class:
>
> static bind(Service service, Tab tab) {
> tab.selectedProperty().addListener((obs, old, selected) -> {
> if(selected) {
> service.restart();
> } else {
> service.cancel();
> }
> });
> }
>
> Was that an answer to your question?
>
> Best,
> Tomas
>
> On Wed, Jul 30, 2014 at 3:44 PM, Peter Penzov  wrote:
>> Hi Tomas,
>>   I'm not 100% sure but I tested the proposed code and it seems that it's
>> working. One more question. I have too many Java Classes into which I need
>> to implement this. Is there a quick and easy way to get the Tab Object into
>> the service class where I need to implement this?
>>
>> BR,
>> Peter
>>
>>
>> On Wed, Jul 30, 2014 at 1:22 PM, Tomas Mikula 
>> wrote:
>>>
>>> What about
>>>
>>> tab.selectedProperty().addListener((obs, old, selected) -> {
>>> if(selected) {
>>> service.restart();
>>> } else {
>>> service.cancel();
>>> }
>>> });
>>>
>>> ?
>>>
>>> Best,
>>> Tomas
>>>
>>> On Wed, Jul 30, 2014 at 9:07 AM, Peter Penzov 
>>> wrote:
>>> > Hi All,
>>> >I have a TabPane with JavaFX service which displays some data. I'm
>>> > interested is there a way to pause the service when I switch the tabs
>>> > and
>>> > the service is not visible? It 'will same me a lot of CPU resources if
>>> > there is a way to implement this.
>>> >
>>> > BR,
>>> > Peter
>>
>>

Re: How to pause service when it's not visible in TabPane

[Tomas Mikula]

I'm not sure I understand: you have many service subclasses, each of
them associated with a tab? If so, they can take the tab as an
argument to the constructor:

abstract class TabService extends Service {
protected MyAbstractService(Tab tab) {
tab.selectedProperty().addListener((obs, old, selected) -> {
if(selected) {
restart();
} else {
cancel();
}
});
}
}

class FooService extends TabService {
public FooService(Tab tab) {
super(tab);
}
}

Alternatively, you can have a Tab subclass that takes Service as
constructor argument.

Alternatively, you can have a static helper method that binds the
service to the tab and use it from any class:

static bind(Service service, Tab tab) {
tab.selectedProperty().addListener((obs, old, selected) -> {
if(selected) {
service.restart();
} else {
service.cancel();
}
});
}

Was that an answer to your question?

Best,
Tomas

On Wed, Jul 30, 2014 at 3:44 PM, Peter Penzov  wrote:
> Hi Tomas,
>   I'm not 100% sure but I tested the proposed code and it seems that it's
> working. One more question. I have too many Java Classes into which I need
> to implement this. Is there a quick and easy way to get the Tab Object into
> the service class where I need to implement this?
>
> BR,
> Peter
>
>
> On Wed, Jul 30, 2014 at 1:22 PM, Tomas Mikula 
> wrote:
>>
>> What about
>>
>> tab.selectedProperty().addListener((obs, old, selected) -> {
>> if(selected) {
>> service.restart();
>> } else {
>> service.cancel();
>> }
>> });
>>
>> ?
>>
>> Best,
>> Tomas
>>
>> On Wed, Jul 30, 2014 at 9:07 AM, Peter Penzov 
>> wrote:
>> > Hi All,
>> >I have a TabPane with JavaFX service which displays some data. I'm
>> > interested is there a way to pause the service when I switch the tabs
>> > and
>> > the service is not visible? It 'will same me a lot of CPU resources if
>> > there is a way to implement this.
>> >
>> > BR,
>> > Peter
>
>

Re: How to pause service when it's not visible in TabPane

[Tomas Mikula]

What about

tab.selectedProperty().addListener((obs, old, selected) -> {
if(selected) {
service.restart();
} else {
service.cancel();
}
});

?

Best,
Tomas

On Wed, Jul 30, 2014 at 9:07 AM, Peter Penzov  wrote:
> Hi All,
>I have a TabPane with JavaFX service which displays some data. I'm
> interested is there a way to pause the service when I switch the tabs and
> the service is not visible? It 'will same me a lot of CPU resources if
> there is a way to implement this.
>
> BR,
> Peter

Re: Mirrored observable collections

[Tomas Mikula]

On Wed, Jul 23, 2014 at 1:16 PM, Mike Hearn  wrote:
> Thanks Tomas! I'm a big fan of your work and blog.
>
> I learned about ReactFX after I started writing my current project, seems
> like a very useful abstraction indeed, although so far I've found the basic
> JFX stuff to be nearly sufficient (a few more transformers and mirrored
> observables were so far all I needed).
>
> Actually I didn't realise ReactFX could do this. I learned about what it can
> do by reading the github page which covers many features but doesn't mention
> threading anywhere, so I figured it didn't have any support for it. I should
> have dug deeper! Maybe you could add a discussion of threading and how to
> manage asynchronous state using ReactFX?

Yeah, this information is missing on the project site.

> Additionally a discussion of debugging would be helpful. My experience so
> far is that reactive/streaming code is fun to write and painful to debug
> compared to traditional imperative code.

In a debugger, yes. On the other hand, I find it easy to write tests for.

>
> In my UI I use content bindings, so I'd need to (I think) use
> EventStreams.merge() to merge the event stream back into a copy of the set,
> and at that point the API would be more verbose than
> MirroredObservableSet/List. Still ReactFX is clearly a lot more general and
> I might well switch to it at some point.

My suggestion was for the case "if you only care about changes and not
full content". If you want the full collection on both sides, then
your mirrored collections make sense. You could still use the
mentioned threadBridge method to transfer change events, but that's
just a minor part of the implementation.

>
> Incidentally the lack of a uni-directional string binding utility in JavaFX
> is really annoying: converting a read only observable value into a string is
> a really common thing to want to do!

You can use EasyBind:

ObservableValue src = ...;
ObservableValue str = EasyBind.map(src, t -> format(t));

although it's not as concise and fluent as

ObservableValue src = ...;
ObservableValue str = src.map(t -> format(t));

would be.

Re: Mirrored observable collections

[Tomas Mikula]

Nice!

On Tue, Jul 22, 2014 at 6:09 PM, Mike Hearn  wrote:
> I have what I imagine is a fairly typical JavaFX application (once it's
> released I'll post more about it). It has a GUI, some mostly asynchronous
> state management, and interactions with various servers that can change the
> apps state.
>
> At first I tried the simple and obvious approach in which the backend would
> schedule closures onto the UI thread using Platform.runLater() when things
> changed, sometimes via ad-hoc event handlers or callbacks. But it ended up
> getting more and more complicated and unclear. So I ended up rewriting
> things to be more actor-ish in which the backend code ran mostly in its own
> thread and vended "mirrored observables".
>
> I figured mirrored observables are a generally useful concept that probably
> JavaFX should have itself.
>
> The idea is simple enough. Given an ObservableList or ObservableSet (I
> didn't need map yet), calling a static utility function with that list and
> an Executor returns a new list in which all updates run in the context of
> that executor. This means a piece of code that's responding to changes in
> state held elsewhere e.g. via a network connection which receives updates
> from a server can have its own thread, and update its own
> ObservableLists/Sets/Maps without thinking about threading as long as the
> only public accessors for these collections vend mirrored versions. Note
> that mirrors are read-only, I don't attempt to do two-way sync (with
> conflict resolution?!). If you want to update the "real" list you have to
> schedule a closure onto the backend thread to do it and wait for the change
> to re-propagate to the frontend thread.
>
> Once this is in place, you can then bind the collections to UI controls
> using some extra transformers in the standard manner, and everything hangs
> together nicely.
>
> The code I'm using is here (Apache licensed, go wild)
>
>https://gist.github.com/mikehearn/4781ce7f00228762adfb
>
> There are three files. AffinityExecutor is an extended version of the
> Executor interface which has a notion of thread ownership (supports short
> circuiting and assertions), along with static methods to create:
>
>1. AffinityExecutors that are bound to a dedicated new thread with a
>task queue.
>2. An AffinityExecutor that queues up tasks but doesn't execute them
>until explicitly requested, this is useful for unit testing.
>3. An AffinityExecutor that wraps Platform.runLater and
>Platform.isFxApplicationThread
>4. An executor that just runs closures immediately on the same thread.
>
> Then ObservableMirrors creates sets/lists in the same way a content binding
> would, but which re-applies changes in the given thread or short-circuits
> and does so immediately if the listener on the mirror is running on the
> same thread as the caller.
>
> There's also a set of static addListener methods in MarshallingObservers
> that just relays into the right thread as well, if you only care about
> changes and not full content.

You can also use ReactFX streams to transfer events (here list
changes) to another thread:

ObservableList list = ...;
EventStream> changesOnFxThread =
EventStreams.changesOf(list)
.threadBridgeToFx(backendExecutor);

See 
http://www.reactfx.org/javadoc/org/reactfx/EventStream.html#threadBridgeToFx-java.util.concurrent.Executor-

>
> Of course you could have an ObservableMirrors equivalent that uses a
> regular Java executor, you'd just lose some safety and short circuiting.

RichTextFX news

[Tomas Mikula]

Hi all,

I would like to briefly inform about the recent additions in
RichTextFX [1]. RichTextFX is a text area that supports styled text.
Its original goal is to support code editing. To this end, it now
features:

1) Displaying line numbers and, more generally, any graphic in front
of each line. This can be used to implement, for example, breakpoint
toggles on lines of code.

2) Positioning a popup window relative to the caret or selection. Can
be used to position an autocompletion box.

3) Getting the index of a character under the mouse, when the mouse
stays still for a specified period of time. Can be used to display
custom tooltips whose content depends on the word/code under the
mouse.

Best Regards,
Tomas

[1] http://www.fxmisc.org/richtext/

Re: Is JavaFX keyboard event handling too rigid?

[Tomas Mikula]

Hi Randahl,

I think the general advice is to avoid subclassing controls if
possible. You can create your custom control that embeds a text field
and filter events on your custom control so they never reach the
embedded text field.

Tomas

On Fri, Jun 13, 2014 at 10:11 AM, Randahl Fink Isaksen
 wrote:
> I have noticed that quite many developers are having trouble avoiding 
> triggering of focus navigation occurring when a user presses the UP and DOWN 
> arrow keys. From a number of different forum posts I have seen how people are 
> jumping through hoops to avoid this.
>
> I myself have the challenge, that I need to use the UP and DOWN keys for 
> changing the selected autocompletion in a text field, and it seems that no 
> matter how greedily I try to consume or filter out these KeyEvents, JavaFX 
> still insists on moving the focus from one field to the next.
>
> This got me thinking: Why is JavaFX keyboard event handling so rigid? If you 
> implement a control which listens for keyboard events on itself and does some 
> cool stuff, that is fine. But once you implement a subclass that wishes to 
> replace some of that behaviour you are in trouble, because once the 
> EventHandlers are registered, there is no public API to replace them.
>
> Is this a conscious design decision? Is it something that I should file a 
> feature request on, or have I overlooked a part of the API which could be 
> used here?
>
> Randahl
>

Re: Double skin addition

[Tomas Mikula]

Hi Randahl,

you should override your Skin's dispose() method that removes the label.

Possible reasons I can imagine why JavaFX does not clear the child list itself:
1. The control could have some children on it's own, which shouldn't
be deleted when applying a skin. This will be the case for a control
that does not have a default skin.
2. Some third party code may add some nodes (e.g. a lightweight popup
or a "close" button) to your control. These should not be removed when
switching skins either.

Regards,
Tomas

On Wed, Jun 11, 2014 at 9:57 AM, Randahl Fink Isaksen  wrote:
> I have noticed that if I create a skin which adds a label like this
>
> public MySkin(MyControl control) {
> super(control);
> pane.getChildren().add(label);
> getChildren().add(pane);
> }
>
> the label is actually added twice in my application. I suspect this is 
> because I am switching style sheets during startup, which means my 
> createDefaultSkin method might be invoked twice.
>
> I found out, I can easily solve this by changing my code to using a 
> getChildren().setAll(label) rather than getChildren().add(label), but I am 
> surprised that JavaFX would not by itself clear the control’s children when 
> applying a new skin.
>
> Has anyone else experienced this?
>
> Thanks
>
> Randahl

Re: monitor mouse events but not capture them

[Tomas Mikula]

Somehow I didn't get your previous email that you are quoting now.

Listening to MOUSE_MOVED events on the Scene seemed to work for me.
Didn't it work for you? You may as well install the menu to a Scene
instead of a Node. That will also simplify listening to scene's
events, because you don't have to worry about the case when the node
is not yet attached to the scene (when node.getScene() returns null).

By the way, you should probably use addEventHandler instead of
addEventFilter, to allow child nodes to consume the event if they want
to override the right click.

Tomas

On Tue, Jun 10, 2014 at 6:50 PM, Tom Eugelink  wrote:
>
> Ah, attaching to Node is a good idea after all!
>
> Tom
>
>
> On 2014-6-10 17:44, Tom Eugelink wrote:
>>
>>
>> Thanks for all the help, you've given me a lot of helpful tips. I already
>> was working on a popup based version and I see you ran into the same
>> problems as I did (initial popup had no width for the circularPane, etc),
>> the difference is that I bind the menu to Stage, since I do not envision
>> CirclePopupMenu as a context menu to a specific node. It could of course...
>> Uncertain about that.
>>
>> Anyhow, the only remaining problem is hiding when the mouse exits. Stage
>> does not send the mouse events to addEventFilter. The node.addEventFilter
>> does not solve that and on scene I'm not getting the events either. But I
>> like the way it is going.
>>
>> Thanks!
>>
>> Tom
>>
>>
>> On 2014-6-10 16:26, Tomas Mikula wrote:
>>>
>>> Here it is, using a Popup:
>>>
>>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu2.java
>>>
>>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample2.java
>>>
>>> The nice thing about popup window is that it can extend beyond the
>>> bounds of the owner window.
>>> Just let me know if transparency works for you as expected. Some time
>>> ago transparency stopped working on my system and I didn't care to
>>> find out why, so my Popup has white background instead of transparent,
>>> but should be transparent on a healthy system.
>>>
>>> On Tue, Jun 10, 2014 at 3:57 PM, Tomas Mikula 
>>> wrote:
>>>>
>>>> Just because I wanted to make minimal changes to your code, which was
>>>> already using StackPane. Yes, Popup would remove the need for a
>>>> StackPane.
>>>>
>>>> On Tue, Jun 10, 2014 at 3:52 PM, Tom Eugelink  wrote:
>>>>>
>>>>> You're way ahead of me. Why use stackpane and not popup as suggested?
>>>>> Wouldn't Popup remove the need for a stackpane?
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2014-6-10 15:38, Tomas Mikula wrote:
>>>>>>
>>>>>> Since talk is cheap, I slightly reworked your code (not using
>>>>>> PopupWindow) and it seems to work.
>>>>>>
>>>>>> CircularPopupMenu:
>>>>>>
>>>>>>
>>>>>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu1.java
>>>>>>
>>>>>> Sample:
>>>>>>
>>>>>>
>>>>>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample1.java
>>>>>>
>>>>>> Main points:
>>>>>> * No "canvas" pane used, CircularPane is added directly to the stack
>>>>>> pane.
>>>>>> * CircularPane is added as the last child to the stack pane in order
>>>>>> to be on top.
>>>>>> * CircularPane is an "unmanaged" child of the stack pane, in order to
>>>>>> allow custom positioning (at mouse pointer)
>>>>>> * Since setPickOnBounds(false) causes the mouse exit the circular pane
>>>>>> as soon as it opens, there's slightly more logic to hide the menu
>>>>>> instead of just listening to MOUSE_EXITED events:
>>>>>>
>>>>>>   stackPane.addEventHandler(MouseEvent.MOUSE_MOVED, e -> {
>>>>>>  if(isShown()) {
>>>>>>  Bounds localBounds = circularPane.getBoundsInLocal();
>>>>>>  Bounds screenBounds =
>>>>>> cir

Re: monitor mouse events but not capture them

[Tomas Mikula]

Here it is, using a Popup:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu2.java
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample2.java

The nice thing about popup window is that it can extend beyond the
bounds of the owner window.
Just let me know if transparency works for you as expected. Some time
ago transparency stopped working on my system and I didn't care to
find out why, so my Popup has white background instead of transparent,
but should be transparent on a healthy system.

On Tue, Jun 10, 2014 at 3:57 PM, Tomas Mikula  wrote:
> Just because I wanted to make minimal changes to your code, which was
> already using StackPane. Yes, Popup would remove the need for a
> StackPane.
>
> On Tue, Jun 10, 2014 at 3:52 PM, Tom Eugelink  wrote:
>>
>> You're way ahead of me. Why use stackpane and not popup as suggested?
>> Wouldn't Popup remove the need for a stackpane?
>>
>> Tom
>>
>>
>>
>>
>> On 2014-6-10 15:38, Tomas Mikula wrote:
>>>
>>> Since talk is cheap, I slightly reworked your code (not using
>>> PopupWindow) and it seems to work.
>>>
>>> CircularPopupMenu:
>>>
>>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu1.java
>>>
>>> Sample:
>>>
>>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample1.java
>>>
>>> Main points:
>>> * No "canvas" pane used, CircularPane is added directly to the stack pane.
>>> * CircularPane is added as the last child to the stack pane in order
>>> to be on top.
>>> * CircularPane is an "unmanaged" child of the stack pane, in order to
>>> allow custom positioning (at mouse pointer)
>>> * Since setPickOnBounds(false) causes the mouse exit the circular pane
>>> as soon as it opens, there's slightly more logic to hide the menu
>>> instead of just listening to MOUSE_EXITED events:
>>>
>>>  stackPane.addEventHandler(MouseEvent.MOUSE_MOVED, e -> {
>>> if(isShown()) {
>>> Bounds localBounds = circularPane.getBoundsInLocal();
>>> Bounds screenBounds = circularPane.localToScreen(localBounds);
>>> if(!screenBounds.contains(e.getScreenX(), e.getScreenY())) {
>>> hide();
>>> }
>>> }
>>>  });
>>>
>>> Cheers,
>>> Tomas
>>>
>>> On Tue, Jun 10, 2014 at 1:45 PM, Tomas Mikula 
>>> wrote:
>>>>
>>>> What about using Popup, which is a subclass of PopupWindow? You just need
>>>> to
>>>> populate its content
>>>>
>>>>  popup.getContent().addAll(Node...);
>>>>
>>>> and then show it at the right position, relative to any node
>>>>
>>>>      popup.show(canvas, x, y);
>>>>
>>>> Tomas
>>>>
>>>> On Jun 10, 2014 8:49 AM, "Tom Eugelink"  wrote:
>>>>>
>>>>>
>>>>> Looking at PopupWindow; that is an abstract class and I'm not finding
>>>>> much
>>>>> examples on how to use it. Maybe extending PopupControl would be a
>>>>> better
>>>>> choice.
>>>>>
>>>>> Been looking at the ContextMenu source code (which is extending
>>>>> PopupControl), but it is somewhat mysterious how those MenuItems get
>>>>> rendered. I would expect maybe a skin, but I'm not finding it.
>>>>>
>>>>>
>>>>> On 2014-6-9 13:48, Tomas Mikula wrote:
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> I am in favor of the menu being a PopupWindow, but alternatively,
>>>>>> could your "canvas" be a Group instead of a Pane?
>>>>>>
>>>>>> The code would look like this:
>>>>>>
>>>>>>   StackPane stack = new StackPane();
>>>>>>
>>>>>>   Group canvas = new Group();
>>>>>>   canvas.setManaged(false);
>>>>>>
>>>>>>   stack.setOnMousePressed(e -> {
>>>>>>   // layout in the top left corner of the stack pane
>>>>>>   canvas.setLayoutX(0);
>>>>>>   canvas.setLayoutY(0);
>>>>

Re: monitor mouse events but not capture them

[Tomas Mikula]

Just because I wanted to make minimal changes to your code, which was
already using StackPane. Yes, Popup would remove the need for a
StackPane.

On Tue, Jun 10, 2014 at 3:52 PM, Tom Eugelink  wrote:
>
> You're way ahead of me. Why use stackpane and not popup as suggested?
> Wouldn't Popup remove the need for a stackpane?
>
> Tom
>
>
>
>
> On 2014-6-10 15:38, Tomas Mikula wrote:
>>
>> Since talk is cheap, I slightly reworked your code (not using
>> PopupWindow) and it seems to work.
>>
>> CircularPopupMenu:
>>
>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu1.java
>>
>> Sample:
>>
>> https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample1.java
>>
>> Main points:
>> * No "canvas" pane used, CircularPane is added directly to the stack pane.
>> * CircularPane is added as the last child to the stack pane in order
>> to be on top.
>> * CircularPane is an "unmanaged" child of the stack pane, in order to
>> allow custom positioning (at mouse pointer)
>> * Since setPickOnBounds(false) causes the mouse exit the circular pane
>> as soon as it opens, there's slightly more logic to hide the menu
>> instead of just listening to MOUSE_EXITED events:
>>
>>  stackPane.addEventHandler(MouseEvent.MOUSE_MOVED, e -> {
>> if(isShown()) {
>> Bounds localBounds = circularPane.getBoundsInLocal();
>> Bounds screenBounds = circularPane.localToScreen(localBounds);
>> if(!screenBounds.contains(e.getScreenX(), e.getScreenY())) {
>> hide();
>> }
>> }
>>  });
>>
>> Cheers,
>> Tomas
>>
>> On Tue, Jun 10, 2014 at 1:45 PM, Tomas Mikula 
>> wrote:
>>>
>>> What about using Popup, which is a subclass of PopupWindow? You just need
>>> to
>>> populate its content
>>>
>>>  popup.getContent().addAll(Node...);
>>>
>>> and then show it at the right position, relative to any node
>>>
>>>  popup.show(canvas, x, y);
>>>
>>> Tomas
>>>
>>> On Jun 10, 2014 8:49 AM, "Tom Eugelink"  wrote:
>>>>
>>>>
>>>> Looking at PopupWindow; that is an abstract class and I'm not finding
>>>> much
>>>> examples on how to use it. Maybe extending PopupControl would be a
>>>> better
>>>> choice.
>>>>
>>>> Been looking at the ContextMenu source code (which is extending
>>>> PopupControl), but it is somewhat mysterious how those MenuItems get
>>>> rendered. I would expect maybe a skin, but I'm not finding it.
>>>>
>>>>
>>>> On 2014-6-9 13:48, Tomas Mikula wrote:
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>> I am in favor of the menu being a PopupWindow, but alternatively,
>>>>> could your "canvas" be a Group instead of a Pane?
>>>>>
>>>>> The code would look like this:
>>>>>
>>>>>   StackPane stack = new StackPane();
>>>>>
>>>>>   Group canvas = new Group();
>>>>>   canvas.setManaged(false);
>>>>>
>>>>>   stack.setOnMousePressed(e -> {
>>>>>   // layout in the top left corner of the stack pane
>>>>>   canvas.setLayoutX(0);
>>>>>   canvas.setLayoutY(0);
>>>>>
>>>>>   stack.getChildren().add(canvas);
>>>>>   });
>>>>>
>>>>> Regards,
>>>>> Tomas
>>>>>
>>>>> On Mon, Jun 9, 2014 at 11:01 AM, Tom Eugelink  wrote:
>>>>>>
>>>>>> But a PopupWindow would be detached from the pane? Not sure if that is
>>>>>> what
>>>>>> I envision, but I'll give it a go and see what it looks like.
>>>>>>
>>>>>> Your event filter does work though for what I need now.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> On 2014-6-9 10:41, Martin Sladecek wrote:
>>>>>>>
>>>>>>> Oh, I see. So it's not a PopupWindow at all.
>>>>>>> Events can pass only though parent-child hierarchy, so you can't
>>>>>>> catch

Re: monitor mouse events but not capture them

[Tomas Mikula]

Since talk is cheap, I slightly reworked your code (not using
PopupWindow) and it seems to work.

CircularPopupMenu:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/CirclePopupMenu1.java

Sample:
https://github.com/TomasMikula/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/scene/menu/Sample1.java

Main points:
* No "canvas" pane used, CircularPane is added directly to the stack pane.
* CircularPane is added as the last child to the stack pane in order
to be on top.
* CircularPane is an "unmanaged" child of the stack pane, in order to
allow custom positioning (at mouse pointer)
* Since setPickOnBounds(false) causes the mouse exit the circular pane
as soon as it opens, there's slightly more logic to hide the menu
instead of just listening to MOUSE_EXITED events:

stackPane.addEventHandler(MouseEvent.MOUSE_MOVED, e -> {
   if(isShown()) {
   Bounds localBounds = circularPane.getBoundsInLocal();
   Bounds screenBounds = circularPane.localToScreen(localBounds);
   if(!screenBounds.contains(e.getScreenX(), e.getScreenY())) {
   hide();
   }
   }
});

Cheers,
Tomas

On Tue, Jun 10, 2014 at 1:45 PM, Tomas Mikula  wrote:
> What about using Popup, which is a subclass of PopupWindow? You just need to
> populate its content
>
> popup.getContent().addAll(Node...);
>
> and then show it at the right position, relative to any node
>
> popup.show(canvas, x, y);
>
> Tomas
>
> On Jun 10, 2014 8:49 AM, "Tom Eugelink"  wrote:
>>
>>
>> Looking at PopupWindow; that is an abstract class and I'm not finding much
>> examples on how to use it. Maybe extending PopupControl would be a better
>> choice.
>>
>> Been looking at the ContextMenu source code (which is extending
>> PopupControl), but it is somewhat mysterious how those MenuItems get
>> rendered. I would expect maybe a skin, but I'm not finding it.
>>
>>
>> On 2014-6-9 13:48, Tomas Mikula wrote:
>>>
>>> Hi Tom,
>>>
>>> I am in favor of the menu being a PopupWindow, but alternatively,
>>> could your "canvas" be a Group instead of a Pane?
>>>
>>> The code would look like this:
>>>
>>>  StackPane stack = new StackPane();
>>>
>>>  Group canvas = new Group();
>>>  canvas.setManaged(false);
>>>
>>>  stack.setOnMousePressed(e -> {
>>>  // layout in the top left corner of the stack pane
>>>  canvas.setLayoutX(0);
>>>  canvas.setLayoutY(0);
>>>
>>>  stack.getChildren().add(canvas);
>>>  });
>>>
>>> Regards,
>>> Tomas
>>>
>>> On Mon, Jun 9, 2014 at 11:01 AM, Tom Eugelink  wrote:
>>>>
>>>> But a PopupWindow would be detached from the pane? Not sure if that is
>>>> what
>>>> I envision, but I'll give it a go and see what it looks like.
>>>>
>>>> Your event filter does work though for what I need now.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> On 2014-6-9 10:41, Martin Sladecek wrote:
>>>>>
>>>>> Oh, I see. So it's not a PopupWindow at all.
>>>>> Events can pass only though parent-child hierarchy, so you can't catch
>>>>> an
>>>>> Event in your "circular menu" pane and then pass it to some other
>>>>> children
>>>>> of the parent StackPane. The menu pane would have to be parent of the
>>>>> controls in the StackPane.
>>>>> So again, you'd need RT-20184 to determine the target again by
>>>>> temporarily
>>>>> making the menu pane mouse transparent, doing Scene.pick and then
>>>>> redirecting the Event by Event.fireEvent().
>>>>>
>>>>> But I think reworking you menu to be a PopupWindow should work. The
>>>>> transparent areas in the circular menu should pass mouse events to the
>>>>> underlying window.
>>>>>
>>>>> -Martin
>>>>>
>>>>> On 06/09/2014 10:20 AM, Tom Eugelink wrote:
>>>>>>
>>>>>>
>>>>>> Or to see in in action with a single java -jar statement, download the
>>>>>> samples from.
>>>>>> http://jfxtras.org/
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2014-6-9 10:13, Martin Sladecek wrote:
>>>>>>>
>>>>>>&g

Re: monitor mouse events but not capture them

[Tomas Mikula]

What about using Popup, which is a subclass of PopupWindow? You just need
to populate its content

popup.getContent().addAll(Node...);

and then show it at the right position, relative to any node

popup.show(canvas, x, y);

Tomas
On Jun 10, 2014 8:49 AM, "Tom Eugelink"  wrote:

>
> Looking at PopupWindow; that is an abstract class and I'm not finding much
> examples on how to use it. Maybe extending PopupControl would be a better
> choice.
>
> Been looking at the ContextMenu source code (which is extending
> PopupControl), but it is somewhat mysterious how those MenuItems get
> rendered. I would expect maybe a skin, but I'm not finding it.
>
>
> On 2014-6-9 13:48, Tomas Mikula wrote:
>
>> Hi Tom,
>>
>> I am in favor of the menu being a PopupWindow, but alternatively,
>> could your "canvas" be a Group instead of a Pane?
>>
>> The code would look like this:
>>
>>  StackPane stack = new StackPane();
>>
>>  Group canvas = new Group();
>>  canvas.setManaged(false);
>>
>>  stack.setOnMousePressed(e -> {
>>  // layout in the top left corner of the stack pane
>>  canvas.setLayoutX(0);
>>  canvas.setLayoutY(0);
>>
>>  stack.getChildren().add(canvas);
>>  });
>>
>> Regards,
>> Tomas
>>
>> On Mon, Jun 9, 2014 at 11:01 AM, Tom Eugelink  wrote:
>>
>>> But a PopupWindow would be detached from the pane? Not sure if that is
>>> what
>>> I envision, but I'll give it a go and see what it looks like.
>>>
>>> Your event filter does work though for what I need now.
>>>
>>> Thanks!
>>>
>>>
>>> On 2014-6-9 10:41, Martin Sladecek wrote:
>>>
>>>> Oh, I see. So it's not a PopupWindow at all.
>>>> Events can pass only though parent-child hierarchy, so you can't catch
>>>> an
>>>> Event in your "circular menu" pane and then pass it to some other
>>>> children
>>>> of the parent StackPane. The menu pane would have to be parent of the
>>>> controls in the StackPane.
>>>> So again, you'd need RT-20184 to determine the target again by
>>>> temporarily
>>>> making the menu pane mouse transparent, doing Scene.pick and then
>>>> redirecting the Event by Event.fireEvent().
>>>>
>>>> But I think reworking you menu to be a PopupWindow should work. The
>>>> transparent areas in the circular menu should pass mouse events to the
>>>> underlying window.
>>>>
>>>> -Martin
>>>>
>>>> On 06/09/2014 10:20 AM, Tom Eugelink wrote:
>>>>
>>>>>
>>>>> Or to see in in action with a single java -jar statement, download the
>>>>> samples from.
>>>>> http://jfxtras.org/
>>>>>
>>>>>
>>>>>
>>>>> On 2014-6-9 10:13, Martin Sladecek wrote:
>>>>>
>>>>>> OK, so to avoid further confusion, you have a PopupWindow with a Pane
>>>>>> and you want to capture Events on the Pane and sent those events to
>>>>>> the
>>>>>> underlying controls (in a parent window) if those events are not
>>>>>> relevant to
>>>>>> that popup?
>>>>>>
>>>>>> Thanks,
>>>>>> -Martin
>>>>>>
>>>>>> On 06/09/2014 10:07 AM, Tom Eugelink wrote:
>>>>>>
>>>>>>>
>>>>>>> Hm, maybe I chose bad words; I'm not using Canvas, but just a Pane.
>>>>>>> Since the Pane is only used to draw the menu on when it need to
>>>>>>> appear, I'm
>>>>>>> calling it the canvas pane, as in "what is painted on".
>>>>>>>
>>>>>>>
>>>>>>> On 2014-6-9 9:46, Martin Sladecek wrote:
>>>>>>>
>>>>>>>> Just looked at the code and it seems Canvas does pick on bounds
>>>>>>>> independently of the pickOnBounds value. There's currently no logic
>>>>>>>> for
>>>>>>>> picking only when over an opaque pixel ( worth filing a JIRA issue
>>>>>>>> maybe?).
>>>>>>>> This makes Canvas to consume everything as it's always picked
>>>>>>>> instead of
>>>>>>>> some cont