Re: Removal of apps/scenebuilder from OpenJFX repo

[Florian Brunner]

OK, this still comes a bit as a surprise as the source code has been kept in 
the repo and was not just provided as a ZIP file.

I'm currently working on a tool based on the SceneBuilder Kit. I needed to work 
on the code a bit and was planning to donate the code back to OpenJFX once 
released, as I was under the impression OpenJFX would serve as the master / 
upstream-repo for all SceneBuilder forks. I was also under the impression that 
OpenJFX at least would make sure the code works with any new JDK / JavaFX 
version and hoped it would get support for new controls, if any were added to 
JavaFX.

-Florian

Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth:
> I filed the following JBS isuse to remova the SceneBuilder sources from 
> the OpenJFX repo.
> 
> https://bugs.openjdk.java.net/browse/JDK-8198961
> 
> As mentioned in the Description of that issue, the OpenJFX repo contains 
> the source code for a no-longer-maintained version of the SceneBuilder 
> tool. Active development on SceneBuilder in the OpenJFX repo was stopped 
> over three years ago. Since that time, the only changes have been either 
> jigsaw-related changes to keep it buildable and runnable, or global 
> changes that happened to touch some of the files in apps/scenebuilder.
> 
> A fork of SceneBuilder is maintained by Gluon, so anyone wanting to get 
> the latest SceneBuilder should go there.
> 
> Before I proceed, I wanted to poll the list to see whether anyone has a 
> concern with this. I don't plan to take any action for at least a week.
> 
> -- Kevin
> 
> 

Style a Popup in a Skin

[Florian Brunner]

Hi,

Sorry to bother this list with this question, but I didn' receive any answer on 
Stackoverflow and I'm not sure if or how this is supported at all:
https://stackoverflow.com/questions/45467626/custom-skin-style-popup
https://stackoverflow.com/questions/14610639/custom-control-opaque-popup

In a Skin implementation of a custom control I want to style a Popup.

I guess I have to use the PopupControl[1], not Popup[2]. 
PopupControl popup = new PopupControl();
popup.getScene().setRoot(popupContentPane);
popup.setAutoHide(true);
popup.setAnchorLocation(PopupWindow.AnchorLocation.WINDOW_BOTTOM_LEFT);
popup.setStyle("-fx-background-color: red;");
popup.getStyleClass().add("my-popup");
popup.show(getSkinnable(), screenLocation.getX(), screenLocation.getY()); 
The skinnable overrides the userAgentStylesheet: 
@Override
public String getUserAgentStylesheet() {
return Stylesheets.getDefaultStylesheet();
} 
But neither the style, nor the styleClass nor any styleClass applied to any 
child node of popupContentPane has some effect. 
If I understand the documentation[3] correctly the popup should use the 
stylesheet of the ownerNode (here the skinnable). 
How can I style a popup in a skin? 
Or should I file an enhancement request?

Kind regards,Florian


[1] 
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/PopupControl.html
[2] http://docs.oracle.com/javase/8/javafx/api/javafx/stage/Popup.html
[3] 
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/PopupControl.html#getStyleableParent--

Module dependencies

[Florian Brunner]

Hi,

I'm still new to the Jigsaw module system, but I've found some documentation 
which is strange:
The Javadoc states that javafx.base depends on java.base:
http://download.java.net/java/jdk9/docs/api/javafx.base-summary.html

But when we look at the source code, we see that javafx.base depends on 
java.desktop:
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/module-info.java

This sounds more logical as javafx.base depends on the package java.beans which 
is in the java.desktop module, e.g.:
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java

So I guess, the info in the Javadoc, which was generated, I think, is 
misleading!

That said, as far as I remember, one of the original goals of JavaFX regarding 
to Java SE 8 Compact Profiles/ Java SE 9 modules was to be able to generate a 
tailored JRE, which only includes the JavaFX stack without the AWT/ Swing 
stack. With the module dependency from javafx.base to java.desktop this won't 
be possible now, I think.
This is really bad news for  JavaFX on mobiles and embedded systems, but also 
for desktop applications which ship with a tailored, embedded JRE.

Are there any plans to make JavaFX available without the AWT/ Swing stack?
Will it be possible to change the module dependencies once they are published? 
(Depending on how transitive dependencies are handled and regarded, this could 
be a breaking change.)

Kind regards,
Florian

Re: Future of JavaFX

[Florian Brunner]

I think actually the 2nd point (State-of-the-art code collaboration platform) 
is not comfortable enough how I described it.

Firstly, it should be a CI server, not a person, who synchronizes the 
repositories whenever there is a change on a non-feature branch of the main 
repository.

Secondly, try to work with pull requests
 For this to work in such an environment the collaborations platform needs the 
following features, I think:
- restrict write access to the non-feature branchens (in Gitflow based Git 
repositories these are usually at least the "master" and "develop" branch),
Only the CI server (or maybe the platform) should have write access to these 
branches, but no developer.
- provide the possibility to define a reviewer group and set up a rule that at 
least one member of this reviewer group needs to approve the pull request
- the reviewer should get an email (push notfication) whenever there is a new 
pull request or whenever a pull request changed

At least for Git, Atlassian Stash can provide such features, AFAIK. Maybe 
BitBucket does provide some similar features for Mercurial repositories?

If such a collaboration platform can be established/ configured it should even 
be possible to set-up another CI server job for 2 way synchronization, as it 
can be made sure everything has been reviewed by an accepted reviewer.

-Florian

Am Mittwoch, 2. Dezember 2015, 23.43:44 schrieb Florian Brunner:
> Some time ago there actaully was a OpenJFX mirror repository on BitBucket.
> 
> I'm not totally sure anymore why this was stopped. I think it needs someone
> who keeps the repositories in sync and there were some concerns that it's
> harder to control who wrote a patch. But maybe the idea with CLA signers
> only members would solve this issue?
> 
> So I see 3 pain points being raised.
> 
> 1. Signing the CLA.
>   - Personally, I don't see any way around this. If there is no CLA then 
> you
> end up with a project _nobody_ is in control of.
> - Basically it envolves the following steps:
>-- Download it from the website
>  -- print it
>  -- sign it
>  -- send it off
>  -- you only have to do this once
>  -- you don't have to wait for Oracle to receive it to start working
> on the issue you like to solve
> 
>Can this be presented in a way it doesn't scare people away as according
> to some statements it seems to do now?
> 
> 2. State-of-the-art code collaboration platform.
>   -- This would have to be something like GitHub or BitBucket
> -- Only CLA signers can be members of the project
> -- Someone has to be in charge to synchronize the repositories
> (probably one way only)
> -- personally I like to work with feature branches in Git but I
> think you can get something similar with Mercurial bookmarks. So
> --- pick an issue you would like to work on
> --- consider to announce it on this mailing list
> --- create a feature branch
> --- start pushing your changes to the feature branch
> --- other developers of the projects (all CLA signers) might chime
> in as they like
>--- once you think you're finished create a patch from the feature
> branch and add it to the issue or (if you don't have enough rights) send it
> to the mailing list
>--- take the feedback from the review, do the fixes an create another
> patch etc.
> 
> So the main benefit would be that several developers could work on the same
> issue until it gets to a high enough qualiy state to be merged into the main
> repository and not requiring one developer to do it all on his/ her own.
> 
> 
> 3. Filing and commenting on issues
>   - if you don't have enough rights, file it on bugs.java.com
>   - ask on this mailing list (or ask someone you know on this mailing list
> to do it for you) about the corresponding issue on bugs.openjdk.java.net -
> someone from Oracle should give anyone who filed an issue that made it to
> bugs.openjdk.java.net the enough rights so he/ she can join on the
> discussion in the issue
> 
> Any better way?
> 
> 
> -Florian
> 
> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb 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:t

Re: Future of JavaFX

[Florian Brunner]

Some time ago there actaully was a OpenJFX mirror repository on BitBucket.

I'm not totally sure anymore why this was stopped. I think it needs someone 
who keeps the repositories in sync and there were some concerns that it's 
harder to control who wrote a patch. But maybe the idea with CLA signers only 
members would solve this issue?

So I see 3 pain points being raised.

1. Signing the CLA.
- Personally, I don't see any way around this. If there is no CLA then 
you 
end up with a project _nobody_ is in control of.
- Basically it envolves the following steps:
 -- Download it from the website
 -- print it
 -- sign it 
 -- send it off
 -- you only have to do this once
 -- you don't have to wait for Oracle to receive it to start working 
on the issue you like to solve

   Can this be presented in a way it doesn't scare people away as according to 
some statements it seems to do now?

2. State-of-the-art code collaboration platform.
-- This would have to be something like GitHub or BitBucket
-- Only CLA signers can be members of the project
-- Someone has to be in charge to synchronize the repositories 
(probably one way only)
-- personally I like to work with feature branches in Git but I think 
you can get something similar with Mercurial bookmarks. So
--- pick an issue you would like to work on
--- consider to announce it on this mailing list
--- create a feature branch
--- start pushing your changes to the feature branch
--- other developers of the projects (all CLA signers) might chime in 
as they like
   --- once you think you're finished create a patch from the feature 
branch and add it to the issue or (if you don't have enough rights) send it to 
the mailing list
   --- take the feedback from the review, do the fixes an create another 
patch etc.

So the main benefit would be that several developers could work on the same 
issue until it gets to a high enough qualiy state to be merged into the main 
repository and not requiring one developer to do it all on his/ her own.


3. Filing and commenting on issues
  - if you don't have enough rights, file it on bugs.java.com
  - ask on this mailing list (or ask someone you know on this mailing list to 
do it for you) about the corresponding issue on bugs.openjdk.java.net
 - someone from Oracle should give anyone who filed an issue that made it to 
bugs.openjdk.java.net the enough rights so he/ she can join on the discussion 
in the issue

Any better way?


-Florian

Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb 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 JavaF

Re: Future of JavaFX

[Florian Brunner]

I read this article as well some days ago. It has some very valid points, but 
all in all I think JavaFX is still the best option out there.

That said I was quite surprised that I got confronted today with the very same 
article by colleagues of mine who are in charge with company-wide adoption of 
various technologies. They tend to agree with the article. Currently JavaFX is 
still just on our technology radar, but not promoted yet. And now they start 
thinking JavFX (and probably thus Java on desktop not even speaking about 
mobile platforms) won't make it and it's getting hard to convince them that 
JavaFX is actually a great option.

Now reading this mail of yours, this article really seems to make waves.

-Florian

 
Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google:
> 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
> ).
> 
> 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

JavaFX community site

[Florian Brunner]

Hi,

There used to be a JavaFX community site with a nice blog aggregator and other 
useful information: http://community.java.net/community/javafx

Now this gets redirected to a seemingly new platform: 
https://community.oracle.com/community/java

The actual new sub-site for JavaFX can be found at (quite hidden, 
unfortunately): 
https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later

Please fix the redirect link.

Unfortunately, this site only seems to aggragte forum posts - no blog 
aggregator or other information.

It would be great if you could bring those back.

-Florian

Re: JavaFX features in JDK 9

[Florian Brunner]

Hi Kevin,

Thanks for the update.

Back in 2012 there was the following statement from Oracle:

"Oracle intends to standardize relevant parts of JavaFX through the JCP in the 
Java SE 9 time frame."

http://www.oracle.com/us/corporate/press/1854982

What about this plan?

-Florian

Am Samstag, 27. Juni 2015, 08.07:44 schrieb Kevin Rushforth:
> Hi Felix,
> 
> Sorry for the delay. Most of us were still pretty focused on 8u60, but
> we are turning our attention to JDK 9 now.
> 
> The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs)
> for FX in JDK 9 are these:
> 
> JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization
> JEP 257: Update JavaFX/Media to Newer Version of GStreamer
> 
> Related to Jigasw, we intend to look into new API for heavily used
> internal methods / classes since they will no longer be accessible
> otherwise. We also plan to update WebKit at least one more time, and
> will likely do a few RFEs such as better Hi-DPI support (with API
> control) on Mac, Windows, Linux.
> 
> We don't currently plan any other big features for 9, but will consider
> additional RFEs if they are important to enough developers and if they
> fit into the time frame.
> 
> -- Kevin
> 
> Felix Bembrick wrote:
> > Anyone got anything or is there a link somewhere that talks about these?
> > 
> > On 15 June 2015 at 22:00, Felix Bembrick  wrote:
> >> I realise we are a long way off JDK 9 still and with crucial features
> >> such
> >> as Jigsaw still a little up in the air but is it possible someone could
> >> itemise the most likely new features, enhancements and bug fixes that we
> >> will see in JavaFX when JDK 9 is released?
> >> 
> >> Of course it's purely speculation at this point but it would assist me
> >> greatly to have some of idea of where JavaFX is heading and which areas
> >> are
> >> seen as most important.
> >> 
> >> Thanks,
> >> 
> >> Felix

Re: OpenJFX mirror at BitBucket?

[Florian Brunner]

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

OpenJFX mirror at BitBucket?

[Florian Brunner]

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: JDK 8u33 for ARM and JavaFX

[Florian Brunner]

Indeed, this is really bad news then. :-( 

JavaFX gets further from "write once run anywhere" instead of closer. :-(

-Florian

Am Mittwoch, 21. Januar 2015, 06.52:58 schrieb Ladislav Török:
> Hi,
> from Release Notes for JDK 8u33 for ARM (see:
> http://www.oracle.com/technetwork/java/javase/jdk-8u33-arm-relnotes-2406696.
> html ):
> 
> 1 New and Changed Features
> 
> In addition, JDK 8u33 for ARM contains the following change:
> 
> * Starting with JDK 8u33, JavaFX Embedded is removed from the ARM bundle
> and is not supported.
> 
> This means that JavaFX is not running on Raspberry PI and when I want to
> use JavaFX on Raspberry Pi, I must be built OpenJFX and result .jar/jars
> copy to JDK 8u33 for ARM directories structure on Raspberrry PI?

Re: SplitPane layout question

[Florian Brunner]

I've cross-posted the question here: 
http://stackoverflow.com/questions/27953751/splitpane-layout-issue

I'm still looking for solutions.

-Florian

Am Montag, 5. Januar 2015, 22.35:48 schrieb Florian Brunner:
> Hi Scott,
> 
> Thanks for your answer.
> 
> Unfortunatly, I still couldn't fix this issue.
> 
> I tried several things including setting the prefWidth/ prefHeight of the
> items to the expected value, but I couldn't stop the SplitPane to
> effectively "hide" the first and the third (last) item during a re-layout.
> 
> The two dividers changed during the layoutChildren call as follows:
> 
> Divider position changed: old value: 0.10857763300760044, new value:
> 0.004343105320304018
> 
> Divider position changed: old value: 0.8914223669923995, new value:
> 0.995656894679696
> 
> I had a look at the com.sun.javafx.scene.control.skin.SplitPaneSkin (source
> code provided with the JDK), but unfortunatly it's not easy there to see how
> the areas are calculated in this situation.
> 
> You mentioned the min/ max sizes. Just for testing purposes I also set the
> minHeight/ minWidth but this only had the effect that I couldn't readjust
> the divider with the mouse anymore. During the re-layout the issue still
> persisted.
> 
> What else could I try?
> 
> -Florian
> 
> Am Montag, 22. Dezember 2014, 07.19:37 schrieb Scott Palmer:
> > The min/max sizes of the children are probably being respected.
> > 
> > Scott
> > 
> > > On Dec 22, 2014, at 7:13 AM, Florian Brunner 
> > > wrote:
> > > 
> > > Hi,
> > > 
> > > Sometimes when I'm setting the divider positions of a SplitPane
> > > programmatically my value get overridden again by some JavaFX internal
> > > layout code.
> > > 
> > > For debugging purposes I've added a listener to the position property of
> > > the divider and have thrown a RuntimeException to see the stack trace.
> > > It
> > > looks like this:
> > > 
> > > 
> > > --
> > >  at
> > > com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(Ex
> > > pr
> > > essionHelper.java:361)>
> > > 
> > >at
> > > 
> > > com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(Expression
> > > He
> > > lper.java:81)>
> > > 
> > >at
> > > 
> > > javafx.beans.property.DoublePropertyBase.fireValueChangedEvent(DoublePro
> > > pe
> > > rtyBase.java:106)>
> > > 
> > >at
> > > 
> > > javafx.beans.property.DoublePropertyBase.markInvalid(DoublePropertyBase.
> > > ja
> > > va:113)>
> > > 
> > >at
> > > 
> > > javafx.beans.property.DoublePropertyBase.set(DoublePropertyBase.java:146
> > > )
> > > 
> > >at
> > >javafx.scene.control.SplitPane$Divider.setPosition(SplitPane.java:486
> > >)
> > >at
> > > 
> > > com.sun.javafx.scene.control.skin.SplitPaneSkin.setAbsoluteDividerPos(Sp
> > > li
> > > tPaneSkin.java:310)>
> > > 
> > >at
> > > 
> > > com.sun.javafx.scene.control.skin.SplitPaneSkin.setupContentAndDividerFo
> > > rL
> > > ayout(SplitPaneSkin.java:502)>
> > > 
> > >at
> > > 
> > > com.sun.javafx.scene.control.skin.SplitPaneSkin.layoutChildren(SplitPane
> > > Sk
> > > in.java:817)>
> > > 
> > >at javafx.scene.control.Control.layoutChildren(Control.java:589)
> > >at javafx.scene.Parent.layout(Parent.java:1074)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Parent.layout(Parent.java:1080)
> > >at javafx.scene.Scene.doLayoutPass(Scene.java:532)
> > >at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2363)
> > >at com.sun.javafx.tk.Toolkit.lambda$runPulse$28(Toolkit.java:314)
> > >at com.sun.javafx.tk.Toolkit$$Lambda$230/25595560.run(Unknown Source)

Re: SplitPane layout question

[Florian Brunner]

Hi Scott,

Thanks for your answer.

Unfortunatly, I still couldn't fix this issue.

I tried several things including setting the prefWidth/ prefHeight of the 
items to the expected value, but I couldn't stop the SplitPane to effectively 
"hide" the first and the third (last) item during a re-layout.

The two dividers changed during the layoutChildren call as follows:

Divider position changed: old value: 0.10857763300760044, new value: 
0.004343105320304018

Divider position changed: old value: 0.8914223669923995, new value: 
0.995656894679696

I had a look at the com.sun.javafx.scene.control.skin.SplitPaneSkin (source 
code provided with the JDK), but unfortunatly it's not easy there to see how 
the areas are calculated in this situation.

You mentioned the min/ max sizes. Just for testing purposes I also set the 
minHeight/ minWidth but this only had the effect that I couldn't readjust the 
divider with the mouse anymore. During the re-layout the issue still 
persisted.

What else could I try?

-Florian

Am Montag, 22. Dezember 2014, 07.19:37 schrieb Scott Palmer:
> The min/max sizes of the children are probably being respected.
> 
> Scott
> 
> > On Dec 22, 2014, at 7:13 AM, Florian Brunner  wrote:
> > 
> > Hi,
> > 
> > Sometimes when I'm setting the divider positions of a SplitPane
> > programmatically my value get overridden again by some JavaFX internal
> > layout code.
> > 
> > For debugging purposes I've added a listener to the position property of
> > the divider and have thrown a RuntimeException to see the stack trace. It
> > looks like this:
> > 
> > --
> >  at
> > com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(Expr
> > essionHelper.java:361)> 
> >at
> > 
> > com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHe
> > lper.java:81)> 
> >at
> > 
> > javafx.beans.property.DoublePropertyBase.fireValueChangedEvent(DoublePrope
> > rtyBase.java:106)> 
> >at
> > 
> > javafx.beans.property.DoublePropertyBase.markInvalid(DoublePropertyBase.ja
> > va:113)> 
> >at
> > 
> > javafx.beans.property.DoublePropertyBase.set(DoublePropertyBase.java:146)
> > 
> >at
> >javafx.scene.control.SplitPane$Divider.setPosition(SplitPane.java:486)
> >at
> > 
> > com.sun.javafx.scene.control.skin.SplitPaneSkin.setAbsoluteDividerPos(Spli
> > tPaneSkin.java:310)> 
> >at
> > 
> > com.sun.javafx.scene.control.skin.SplitPaneSkin.setupContentAndDividerForL
> > ayout(SplitPaneSkin.java:502)> 
> >at
> > 
> > com.sun.javafx.scene.control.skin.SplitPaneSkin.layoutChildren(SplitPaneSk
> > in.java:817)> 
> >at javafx.scene.control.Control.layoutChildren(Control.java:589)
> >at javafx.scene.Parent.layout(Parent.java:1074)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Parent.layout(Parent.java:1080)
> >at javafx.scene.Scene.doLayoutPass(Scene.java:532)
> >at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2363)
> >at com.sun.javafx.tk.Toolkit.lambda$runPulse$28(Toolkit.java:314)
> >at com.sun.javafx.tk.Toolkit$$Lambda$230/25595560.run(Unknown Source)
> >at java.security.AccessController.doPrivileged(Native Method)
> >at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:313)
> >at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:340)
> >at
> >com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:451
> >)
> >at
> >com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:431
> >)
> >at
> > 
> > com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$363(QuantumTool
> > kit.java:298)> 
> >at
> > 
> > com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$59/174792896.run(Unknown
> > Source)
> > 
> >at
> > 
> > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.ja
> > va:95)> 
> >at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
> >at
> > 
> > com.sun.glass.ui.gtk.GtkApplication.lambda$null

SplitPane layout question

[Florian Brunner]

Hi, 

Sometimes when I'm setting the divider positions of a SplitPane 
programmatically my value get overridden again by some JavaFX internal layout 
code.

For debugging purposes I've added a listener to the position property of the 
divider and have thrown a RuntimeException to see the stack trace. It looks 
like this:

--
at 
com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:361)
at 
com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:81)
at 
javafx.beans.property.DoublePropertyBase.fireValueChangedEvent(DoublePropertyBase.java:106)
at 
javafx.beans.property.DoublePropertyBase.markInvalid(DoublePropertyBase.java:113)
at 
javafx.beans.property.DoublePropertyBase.set(DoublePropertyBase.java:146)
at 
javafx.scene.control.SplitPane$Divider.setPosition(SplitPane.java:486)
at 
com.sun.javafx.scene.control.skin.SplitPaneSkin.setAbsoluteDividerPos(SplitPaneSkin.java:310)
at 
com.sun.javafx.scene.control.skin.SplitPaneSkin.setupContentAndDividerForLayout(SplitPaneSkin.java:502)
at 
com.sun.javafx.scene.control.skin.SplitPaneSkin.layoutChildren(SplitPaneSkin.java:817)
at javafx.scene.control.Control.layoutChildren(Control.java:589)
at javafx.scene.Parent.layout(Parent.java:1074)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Parent.layout(Parent.java:1080)
at javafx.scene.Scene.doLayoutPass(Scene.java:532)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2363)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$28(Toolkit.java:314)
at com.sun.javafx.tk.Toolkit$$Lambda$230/25595560.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:313)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:340)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:451)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:431)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$363(QuantumToolkit.java:298)
at 
com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$59/174792896.run(Unknown 
Source)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at 
com.sun.glass.ui.gtk.GtkApplication.lambda$null$45(GtkApplication.java:126)
at 
com.sun.glass.ui.gtk.GtkApplication$$Lambda$55/1472148546.run(Unknown 
Source)
at java.lang.Thread.run(Thread.java:745)
--

It doesn't seem to get triggered by some code of mine (at least not directly 
according to the stack trace).

Why is this re-layout happing here?
Why does it override the values I've set for the divider positions?
How can stop this?

Thanks for some insights.

-Florian

Tutorials for Custom Controls?

[Florian Brunner]

Hi,

Earlier this year I added some Jira issues asking for more tutorials on how to 
write custom controls:
https://javafx-jira.kenai.com/browse/RT-36437

Any chance we could get such tutorials?

-Florian

Re: Javadoc: docklet, properties, getters and setters

[Florian Brunner]

Yes, that did the trick. Thanks!

For Maven this would be:

 
...
-javafx
...


-Florian


Am Freitag, 16. Mai 2014, 17.31:54 schrieb Kevin Rushforth:
> Try:
> 
> javadoc -javafx ...
> 
> -- Kevin
> 
> Florian Brunner wrote:
> > As far as I'm aware, with Java SE 8 you don't have to specify a docklet
> > anymore. The default docklet already supprts JavaFX properties.
> > 
> > But when I generate the Javadoc, the section "Property description: ..."
> > is
> > missing in the getters and the setters.
> > 
> > I noticed however, that the JavaFX 8 Javadoc does have these sections
> > (e.g.
> > see Button.setDefaultButton:
> > http://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/Button.htm
> > l#setDefaultButton-boolean- )
> > 
> > How did you manage to generate these sections?
> > 
> > Thanks for some hints.
> > 
> > -Florian

Javadoc: docklet, properties, getters and setters

[Florian Brunner]

As far as I'm aware, with Java SE 8 you don't have to specify a docklet 
anymore. The default docklet already supprts JavaFX properties.

But when I generate the Javadoc, the section "Property description: ..." is 
missing in the getters and the setters.

I noticed however, that the JavaFX 8 Javadoc does have these sections (e.g. 
see Button.setDefaultButton: 
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/Button.html#setDefaultButton-boolean-
 )

How did you manage to generate these sections?

Thanks for some hints.

-Florian

Re: Launching JavaFX apps

[Florian Brunner]

Could someone elaborate on this?

Thanks!

-Florian

Am Samstag, 18. Januar 2014, 13.27:07 schrieb Florian Brunner:
> Hi Kevin,
> 
> Thanks for this clarifiacation! I'm also interested in this kind of 
> information as I'm in the process of upgrading Drombler FX to JavaFX 8 and 
> Drombler FX comes with a custom Maven Plugin, which makes sure the 
> application can start.
> 
> Another related question:
> 
> While the Ant task for JavaFX 2.x added the following Manifest entries:
> 
> JavaFX-Version: 2.2
> JavaFX-Application-Class: myPackage.MyApplication
> JavaFX-Class-Path: 
> Main-Class: com/javafx/main/Main
> 
> 
> the Ant task for JavaFX 8 added the following Manifest entries:
> JavaFX-Version: 2.2
> Class-Path: 
> Main-Class: myPackage.MyApplication
> 
> So it seems "JavaFX-Application-Class" is not used anymore if one doesn't use 
> com.javafx.main.Main to start the JavaFX application, and "JavaFX-Class-Path" 
> has been replaced with the standard "Class-Path" entry.
> 
> The "JavaFX-Version" seems still to be needed, however. For what is it used? 
> An why is this version set to "2.2" for JavaFX 8 applications? Shouldn't it 
> be "8.0" or something?
> Can I get this version from somewhere? Either the JavaFX API or from the 
> ant-javafx.jar?
> 
> -Florian
> 
> Am Mittwoch, 8. Januar 2014, 06.45:36 schrieb Kevin Rushforth:
> > Hi Scott,
> > 
> > The Java 8 launcher has been modified to recognize JavaFX applications 
> > -- that is, classes that extend javafx.application.Application -- and 
> > launch them directly by calling into the JavaFX launcher code. See 
> > JDK-8001533 <https://bugs.openjdk.java.net/browse/JDK-8001533>. This is 
> > why the com.javafx.main.Main class is no longer needed.
> > 
> > Somewhat independent of this, for standalone applications (but not 
> > applets or web start applications) the JavaFX launcher code will now 
> > call the main() method if it is present (see RT-28755 
> > <https://javafx-jira.kenai.com/browse/RT-28755>), but will still happily 
> > launch the application if it isn't. So the main() method is still 
> > optional. If present, it must call Application.launch() in order to 
> > launch the application.
> > 
> > So yes, it does seem that Netbeans should modify the wording of their 
> > javadoc comment for the main() method of a JavaFX application.
> > 
> > -- Kevin
> > 
> > 
> > Scott Palmer wrote:
> > > Based on the discussion I saw in the comments for RT-34236 I discovered
> > > that using com.javafx.main.Main is not the way JavaFX 8 is supposed to
> > > work. There are comments that read, "...making sure their Application 
> > > class
> > > has a main that calls launcher(String[] args)."
> > >
> > > This seems to imply that a main method is now required in the Application
> > > class when writing apps for JavaFX 8.
> > >
> > > Is this correct?
> > >
> > > If so. Somebody should tell NetBeans to stop injecting this comment in the
> > > generated application class for JavaFX projects:
> > > /**
> > >  * The main() method is ignored in correctly deployed JavaFX application.
> > >  * main() serves only as fallback in case the application can not be
> > >  * launched through deployment artifacts, e.g., in IDEs with limited FX
> > >  * support. NetBeans ignores main().
> > >  *
> > >  * @param args the command line arguments
> > >  */
> > >
> > > Are the changes to the launching of JavaFX apps docuemtned somewhere?  Is
> > > using javafxpackager or the ant task the *only* supported way of creating
> > > JavaFX applications?  I'm currently using my own stub that runs on Java 7
> > > and adds the jfxrt.jar to the classpath if required and then calls the
> > > launch method on the Applicaiton class.
> > >
> > > Regards,
> > >
> > > Scott
> > >   
> 

Re: Launching JavaFX apps

[Florian Brunner]

Hi Kevin,

Thanks for this clarifiacation! I'm also interested in this kind of information 
as I'm in the process of upgrading Drombler FX to JavaFX 8 and Drombler FX 
comes with a custom Maven Plugin, which makes sure the application can start.

Another related question:

While the Ant task for JavaFX 2.x added the following Manifest entries:

JavaFX-Version: 2.2
JavaFX-Application-Class: myPackage.MyApplication
JavaFX-Class-Path: 
Main-Class: com/javafx/main/Main


the Ant task for JavaFX 8 added the following Manifest entries:
JavaFX-Version: 2.2
Class-Path: 
Main-Class: myPackage.MyApplication

So it seems "JavaFX-Application-Class" is not used anymore if one doesn't use 
com.javafx.main.Main to start the JavaFX application, and "JavaFX-Class-Path" 
has been replaced with the standard "Class-Path" entry.

The "JavaFX-Version" seems still to be needed, however. For what is it used? An 
why is this version set to "2.2" for JavaFX 8 applications? Shouldn't it be 
"8.0" or something?
Can I get this version from somewhere? Either the JavaFX API or from the 
ant-javafx.jar?

-Florian

Am Mittwoch, 8. Januar 2014, 06.45:36 schrieb Kevin Rushforth:
> Hi Scott,
> 
> The Java 8 launcher has been modified to recognize JavaFX applications 
> -- that is, classes that extend javafx.application.Application -- and 
> launch them directly by calling into the JavaFX launcher code. See 
> JDK-8001533 . This is 
> why the com.javafx.main.Main class is no longer needed.
> 
> Somewhat independent of this, for standalone applications (but not 
> applets or web start applications) the JavaFX launcher code will now 
> call the main() method if it is present (see RT-28755 
> ), but will still happily 
> launch the application if it isn't. So the main() method is still 
> optional. If present, it must call Application.launch() in order to 
> launch the application.
> 
> So yes, it does seem that Netbeans should modify the wording of their 
> javadoc comment for the main() method of a JavaFX application.
> 
> -- Kevin
> 
> 
> Scott Palmer wrote:
> > Based on the discussion I saw in the comments for RT-34236 I discovered
> > that using com.javafx.main.Main is not the way JavaFX 8 is supposed to
> > work. There are comments that read, "...making sure their Application class
> > has a main that calls launcher(String[] args)."
> >
> > This seems to imply that a main method is now required in the Application
> > class when writing apps for JavaFX 8.
> >
> > Is this correct?
> >
> > If so. Somebody should tell NetBeans to stop injecting this comment in the
> > generated application class for JavaFX projects:
> > /**
> >  * The main() method is ignored in correctly deployed JavaFX application.
> >  * main() serves only as fallback in case the application can not be
> >  * launched through deployment artifacts, e.g., in IDEs with limited FX
> >  * support. NetBeans ignores main().
> >  *
> >  * @param args the command line arguments
> >  */
> >
> > Are the changes to the launching of JavaFX apps docuemtned somewhere?  Is
> > using javafxpackager or the ant task the *only* supported way of creating
> > JavaFX applications?  I'm currently using my own stub that runs on Java 7
> > and adds the jfxrt.jar to the classpath if required and then calls the
> > launch method on the Applicaiton class.
> >
> > Regards,
> >
> > Scott
> >   

Re: Regression: JavaFX 8 doesn't call listeners in Skin implementations

[Florian Brunner]

Hi Steve,

Ok, I've reported the issue here:
https://javafx-jira.kenai.com/browse/RT-35208

I even have a small sample application with a small custom control showing the 
issue, but I don't have an option to add an attachement to the issue in Jira...

-Florian

Am Freitag, 3. Januar 2014, 11.23:03 schrieb Stephen F Northover:
> Hi Florian,
> 
> I would enter a JIRA with the steps to make the problem happen and the 
> smallest possible example code that shows it.
> 
> Thanks,
> Steve
> 
> On 2014-01-02 5:10 PM, Florian Brunner wrote:
> > I also tried to add a listener directly to 
> > control.getDockingSplitPaneChildren() in case the issue is with 
> > Bindings.bindContent, but also this listener doesn't get called.
> >
> > member:
> >
> >  private final ListChangeListener 
> > dockingSplitPaneChildrenListener = new 
> > ListChangeListener() {
> >  @Override
> >  public void onChanged(Change 
> > change) {
> >  System.out.println("Change!");
> >  }
> >  };
> >
> >   ...
> >
> > in constructor:
> >
> >   
> > control.getDockingSplitPaneChildren().addListener(dockingSplitPaneChildrenListener);
> >
> > -Florian
> >
> > Am Donnerstag, 2. Januar 2014, 22.51:23 schrieb Florian Brunner:
> >> Hi,
> >>
> >> I'm in the process of upgrading Drombler FX to JavaFX 8 and hit another 
> >> regression issue: JavaFX 8 doesn't call listeners in my Skin 
> >> implementation (it used to work with JavaFX 2.x !)
> >>
> >> Here is the Skin implementation:
> >>
> >> https://sourceforge.net/p/drombler/drombler-fx/ci/default/tree/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/skin/DockingSplitPaneSkin.java
> >>
> >> When I add something to
> >>
> >> control.getDockingSplitPaneChildren()
> >>
> >> what should trigger the listeners, then with a debugger I can trace the 
> >> call up to the WeakListChangeListener where on line 87 the listener is 
> >> null.
> >>
> >> Note that I'm not using a WeakListChangeListener explicitly - JavaFX 8 
> >> must have created this somewhere and for some reason the listener from the 
> >> Skin got lost!
> >>
> >> I also tried to keep a reference to my listeners as a member variable in 
> >> the Skin implementation, but this didn't work either.
> >>
> >> I haven't filed an issue yet because I guess there is already a new way 
> >> how to solve this.
> >>
> >> Note that I would like to solve this first with this "basic" Skin 
> >> implementation and not with the new SkinBase class just yet, as I'm not 
> >> familiar with that new class yet. One refactoring step at a time. ;-)
> >>
> >> -Florian
> >>
> >>
> 

Re: Regression: JavaFX 8 doesn't call listeners in Skin implementations

[Florian Brunner]

I also tried to add a listener directly to 
control.getDockingSplitPaneChildren() in case the issue is with 
Bindings.bindContent, but also this listener doesn't get called.

member:

private final ListChangeListener 
dockingSplitPaneChildrenListener = new 
ListChangeListener() {
@Override
public void onChanged(Change 
change) {
System.out.println("Change!");
}
};

 ...

in constructor:

 
control.getDockingSplitPaneChildren().addListener(dockingSplitPaneChildrenListener);

-Florian

Am Donnerstag, 2. Januar 2014, 22.51:23 schrieb Florian Brunner:
> Hi,
> 
> I'm in the process of upgrading Drombler FX to JavaFX 8 and hit another 
> regression issue: JavaFX 8 doesn't call listeners in my Skin implementation 
> (it used to work with JavaFX 2.x !)
> 
> Here is the Skin implementation:
> 
> https://sourceforge.net/p/drombler/drombler-fx/ci/default/tree/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/skin/DockingSplitPaneSkin.java
> 
> When I add something to 
> 
> control.getDockingSplitPaneChildren()
> 
> what should trigger the listeners, then with a debugger I can trace the call 
> up to the WeakListChangeListener where on line 87 the listener is null.
> 
> Note that I'm not using a WeakListChangeListener explicitly - JavaFX 8 must 
> have created this somewhere and for some reason the listener from the Skin 
> got lost!
> 
> I also tried to keep a reference to my listeners as a member variable in the 
> Skin implementation, but this didn't work either.
> 
> I haven't filed an issue yet because I guess there is already a new way how 
> to solve this.
> 
> Note that I would like to solve this first with this "basic" Skin 
> implementation and not with the new SkinBase class just yet, as I'm not 
> familiar with that new class yet. One refactoring step at a time. ;-)
> 
> -Florian
> 
> 

Regression: JavaFX 8 doesn't call listeners in Skin implementations

[Florian Brunner]

Hi,

I'm in the process of upgrading Drombler FX to JavaFX 8 and hit another 
regression issue: JavaFX 8 doesn't call listeners in my Skin implementation (it 
used to work with JavaFX 2.x !)

Here is the Skin implementation:

https://sourceforge.net/p/drombler/drombler-fx/ci/default/tree/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/skin/DockingSplitPaneSkin.java

When I add something to 

control.getDockingSplitPaneChildren()

what should trigger the listeners, then with a debugger I can trace the call up 
to the WeakListChangeListener where on line 87 the listener is null.

Note that I'm not using a WeakListChangeListener explicitly - JavaFX 8 must 
have created this somewhere and for some reason the listener from the Skin got 
lost!

I also tried to keep a reference to my listeners as a member variable in the 
Skin implementation, but this didn't work either.

I haven't filed an issue yet because I guess there is already a new way how to 
solve this.

Note that I would like to solve this first with this "basic" Skin 
implementation and not with the new SkinBase class just yet, as I'm not 
familiar with that new class yet. One refactoring step at a time. ;-)

-Florian

Re: JavaFX on iOS and Android: The real problem and challenge

[Florian Brunner]

, 2013 at 10:36 PM, Richard Bair wrote:
> 
> > Totally, I think the normal process for this is to create a new OpenJDK
> > project, is it not? Can you take a look at the OpenJDK bylaws and report
> > back on the process? I think it would be awesome to do a port. Note that
> > there are a few OpenJDK ports already which have ARM support, you might
> > want to look there as a starting point?
> >
> > Richard
> >
> > On Nov 8, 2013, at 1:29 PM, Florian Brunner  wrote:
> >
> > > Yes, I agree, we need professional JVM ports for iOS, Android and
> > Windows 8.
> > >
> > > @Oracle: Could you set up the according project sites for these 3
> > platforms on openjdk.java.net and document what exactly has to be done to
> > port OpenJDK (at least some kind of JavaFX compact profile e.g. without the
> > AWT stack) to these platforms? Also the Mercurial repository and the build
> > should be prepared.
> > >
> > > I think if there were an easy starting point it would lower the barrier
> > to work on these ports.
> > >
> > > -Florian
> > >
> > > Am Donnerstag, 24. Oktober 2013, 08.41:32 schrieb Tobias Bley:
> > >> Hello to the community,
> > >>
> > >> I read the last discussion about „JavaFX native look and feel“ and have
> > to get out of my mind the following:
> > >>
> > >> In my opinion the MAIN point is not „how to bring the native look and
> > feel to iOS/Android“, the real MAIN issue is: we need a professional JVM(!)
> > which works performant and reliable on iOS, Android and Windows 8! Only if
> > we have such a JVM, developers and companies are motivated to develop real
> > commercial apps with JavaFX and contribute stuff back to OpenJFX!
> > >>
> > >> RoboVM is a good „prototype“. Niklas is currently one of the most
> > important people for the JavaFX community. He and his company has build the
> > first and one and only real solution to deploy Java and JavaFX code to the
> > iOS platform! His work is really great! But: He is only one(!) person! This
> > kind of complex task I would expect from big companies like Oracle, IBM,
> > SAP or Twitter. But from this direction we don’t hear anything about it.
> > >>
> > >> It is not enough that people like Niklas (Trillian AB) or Matthias and
> > me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all
> > experimental stuff! Yes, currently we can start JavaFX apps on a real
> > iPhone and iPad. And yes, we have managed to start JavaFX on a real Android
> > device using the Dalvik VM. BUT: this is not a long term solution and only
> > experimental! RoboVM on iOS uses the android class library instead of the
> > real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM
> > and the Android class library as well! So both solutions use the real Java
> > platform (=OpenJDK)!
> > >>
> > >> In my opinion there are only two solutions: 1) Oracle releases their
> > JVM for iOS and Android. 2) The „community“ starts a new company who
> > develops a professional, performant and reliable solution for „JavaFX on
> > iOS and Android“ which contains of a JVM and the 6 degrees Felix described
> > in his blog post, mainly native integration (API) and look and feel (skins,
> > native controls).
> > >>
> > >> Cheers,
> > >> Tobi
> > >>
> > >>
> > >>
> > >> Am 23.10.2013 um 22:30 schrieb Richard Bair :
> > >>
> > >>> Yes, definitely.
> > >>>
> > >>>> On Oct 23, 2013, at 11:52 AM, Scott Palmer 
> > wrote:
> > >>>>
> > >>>> This is starting to sound like it may also partially address the
> > issue in the desktop space of supplying a native surface (the heavyweight)
> > to draw in that is part of the scene graph.  It may not be the ideal
> > solution, but could be useful for specific use cases, like a video preview
> > overlay. Would that make any sense?
> > >>>>
> > >>>>
> > >>>> Scott
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair <
> > richard.b...@oracle.com> wrote:
> > >>>>> To do this we need to either solve the auto-layer problem in the NG
> > nodes / Glass / Quantum, or we need to ask the app developer to use
> > SubScene and put all the native stuff in a single SubScene, and all
> > lightweight con

Re: JavaFX on iOS and Android: The real problem and challenge

[Florian Brunner]

Hi Dalibor,

Thanks for the link. I've read now the process described at 
http://openjdk.java.net/projects/#new-project

I'm fine to start the discussion (Step 0), but I think it would help if we 
could find here some initial contributors/ leaders.

I, myself, won't be able to activly work on the ports. For one thing I'm not 
really familiar with native programming and for another I'm already spending a 
lot of my spare time at the other end of the JavaFX ecosystem: I'm developing a 
modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first) 
(see: http://wiki.drombler.org/DromblerFX ).

-Florian

Am Freitag, 8. November 2013, 22.53:26 schrieb Dalibor Topic:
> On 11/8/13 10:30 PM, Florian Brunner wrote:
> > @Oracle: Could you set up the according project sites for these 3 platforms 
> > on openjdk.java.net
> 
> Please see http://openjdk.java.net/projects/ for how Projects work.
> 
> cheers,
> dalibor topic
> 

Re: JavaFX on iOS and Android: The real problem and challenge

[Florian Brunner]

Yes, I agree, we need professional JVM ports for iOS, Android and Windows 8.

@Oracle: Could you set up the according project sites for these 3 platforms on 
openjdk.java.net and document what exactly has to be done to port OpenJDK (at 
least some kind of JavaFX compact profile e.g. without the AWT stack) to these 
platforms? Also the Mercurial repository and the build should be prepared.

I think if there were an easy starting point it would lower the barrier to work 
on these ports.

-Florian

Am Donnerstag, 24. Oktober 2013, 08.41:32 schrieb Tobias Bley:
> Hello to the community,
> 
> I read the last discussion about „JavaFX native look and feel“ and have to 
> get out of my mind the following:
> 
> In my opinion the MAIN point is not „how to bring the native look and feel to 
> iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which 
> works performant and reliable on iOS, Android and Windows 8! Only if we have 
> such a JVM, developers and companies are motivated to develop real commercial 
> apps with JavaFX and contribute stuff back to OpenJFX!
> 
> RoboVM is a good „prototype“. Niklas is currently one of the most important 
> people for the JavaFX community. He and his company has build the first and 
> one and only real solution to deploy Java and JavaFX code to the iOS 
> platform! His work is really great! But: He is only one(!) person! This kind 
> of complex task I would expect from big companies like Oracle, IBM, SAP or 
> Twitter. But from this direction we don’t hear anything about it.
> 
> It is not enough that people like Niklas (Trillian AB) or Matthias and me 
> (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all 
> experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone 
> and iPad. And yes, we have managed to start JavaFX on a real Android device 
> using the Dalvik VM. BUT: this is not a long term solution and only 
> experimental! RoboVM on iOS uses the android class library instead of the 
> real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM 
> and the Android class library as well! So both solutions use the real Java 
> platform (=OpenJDK)!
> 
> In my opinion there are only two solutions: 1) Oracle releases their JVM for 
> iOS and Android. 2) The „community“ starts a new company who develops a 
> professional, performant and reliable solution for „JavaFX on iOS and 
> Android“ which contains of a JVM and the 6 degrees Felix described in his 
> blog post, mainly native integration (API) and look and feel (skins, native 
> controls).
> 
> Cheers,
> Tobi
> 
> 
> 
> Am 23.10.2013 um 22:30 schrieb Richard Bair :
> 
> > Yes, definitely.
> > 
> >> On Oct 23, 2013, at 11:52 AM, Scott Palmer  wrote:
> >> 
> >> This is starting to sound like it may also partially address the issue in 
> >> the desktop space of supplying a native surface (the heavyweight) to draw 
> >> in that is part of the scene graph.  It may not be the ideal solution, but 
> >> could be useful for specific use cases, like a video preview overlay. 
> >> Would that make any sense?
> >> 
> >> 
> >> Scott
> >> 
> >> 
> >> 
> >>> On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair  
> >>> wrote:
> >>> To do this we need to either solve the auto-layer problem in the NG nodes 
> >>> / Glass / Quantum, or we need to ask the app developer to use SubScene 
> >>> and put all the native stuff in a single SubScene, and all lightweight 
> >>> content above and below it. For the short term, we could use the SubScene 
> >>> approach ("Just be careful and don't draw lightweight on top of 
> >>> heavyweights unless you layer an entire sub scene above them") which is 
> >>> probably a perfectly workable solution in the short term. Then somebody 
> >>> just needs to write a set of skins (which can be done in an external 
> >>> project) that map various UI controls directly to native controls. This 
> >>> approach would allow people to have completely native controls while 
> >>> using the FX API, or they can use the lightweight controls (with Modena 
> >>> or with an iOS 7 skin or iOS 6 skin etc).
> >>> 
> >>> I'm thinking about how to implement the auto-layer, and I'm not sure of 
> >>> the best approach. It seems like you need to hook into the sync-time to 
> >>> determine which nodes can be batched into the same layer, reusing 
> >>> previous layers where possible. If there is a way to then setup the NG 
> >>> peer side so that it thinks it was setup in sub scenes etc, although it 
> >>> really wasn't, then that would leave prism out of the problem (which 
> >>> makes this an easier thing to pull off). hmmm. SubScene itself has a 
> >>> peer. So what I'm thinking is, suppose I have a package:
> >>> 
> >>> com.sun.javafx.ext.ios.controls
> >>> 
> >>> and in this package you have all the skins. There is also someplace in 
> >>> here a map of skin -> sub scene peer, indicating which of the nodes is in 
> >>> which sub scene peer ("layer"). Then when the sync takes p

Re: FXMLLoader & BuilderFactory

[Florian Brunner]

Hi Daniel,

Thanks for your response.

> When you say 'instance' what do you mean? A controller or a node or something 
> else?
I'm looking for a way to get notified when a Node gets created.

Regards,
Florian

Am Donnerstag, 30. Mai 2013, 08.25:23 schrieb Daniel Zwolenski:
> When you say 'instance' what do you mean? A controller or a node or something 
> else?
> 
> A controller can be notified when it is initialized (and all the associated 
> nodes will be initialized by this point):
> 
> http://docs.oracle.com/javafx/2/api/javafx/fxml/Initializable.html
> 
> Does that give you the hook ins you need?
> 
> On 30/05/2013, at 8:03 AM, Florian Brunner  wrote:
> 
> > Hi,
> > 
> > I'm experimenting with FXMLLoader. Is there a way to get notified, when an 
> > instance gets created?
> > 
> > I tried to work with a wrapper class for BuilderFactory, like this:
> > 
> > public class WrapperBuilderFactory implements BuilderFactory {
> > 
> >private final BuilderFactory builderFactory;
> > 
> >public WrapperBuilderFactory(BuilderFactory builderFactory) {
> >this.builderFactory = builderFactory;
> >}
> > 
> >@Override
> >public Builder getBuilder(Class type) {
> >Builder builder = builderFactory.getBuilder(type);
> >return new WrapperBuilder<>(builder);
> >}
> > 
> >private static class WrapperBuilder implements Builder {
> > 
> >private final Builder builder;
> > 
> >public WrapperBuilder(Builder builder) {
> >this.builder = builder;
> >}
> > 
> >@Override
> >public T build() {
> >T t = builder.build();
> >doSomething();
> >return t;
> >}
> > 
> >private void doSomething(){
> >// do something
> >}
> >}
> > } 
> > 
> > and then call:
> > FXMLLoader loader = new FXMLLoader();
> > loader.setBuilderFactory(new 
> > FXMLControllerBuilderFactory(loader.getBuilderFactory()));
> > 
> > 
> > But it seems that BuilderFactory.getBuilder usually returns null, which 
> > gets treaded completely differently (instance created at XML start tag) 
> > than when a Builder gets returned (instance created at XML end tag).
> > 
> > Is there another way to get notified when an instance gets created?
> > 
> > Otherwise I will file an enhancement request.
> > 
> > Kind regards,
> > Florian
> > 

FXMLLoader & BuilderFactory

[Florian Brunner]

Hi,

I'm experimenting with FXMLLoader. Is there a way to get notified, when an 
instance gets created?

I tried to work with a wrapper class for BuilderFactory, like this:

public class WrapperBuilderFactory implements BuilderFactory {

private final BuilderFactory builderFactory;

public WrapperBuilderFactory(BuilderFactory builderFactory) {
this.builderFactory = builderFactory;
}

@Override
public Builder getBuilder(Class type) {
Builder builder = builderFactory.getBuilder(type);
return new WrapperBuilder<>(builder);
}

private static class WrapperBuilder implements Builder {

private final Builder builder;

public WrapperBuilder(Builder builder) {
this.builder = builder;
}

@Override
public T build() {
T t = builder.build();
doSomething();
return t;
}

private void doSomething(){
// do something
}
}
} 

and then call:
 FXMLLoader loader = new FXMLLoader();
 loader.setBuilderFactory(new 
FXMLControllerBuilderFactory(loader.getBuilderFactory()));


But it seems that BuilderFactory.getBuilder usually returns null, which gets 
treaded completely differently (instance created at XML start tag) than when a 
Builder gets returned (instance created at XML end tag).

Is there another way to get notified when an instance gets created?

Otherwise I will file an enhancement request.

Kind regards,
Florian

FXMLLoader, Custom Controls and Controller

[Florian Brunner]