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]

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 

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 felix.bembr...@gmail.com 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

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]

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 fbrunnerl...@gmx.ch 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$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

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:

 configuration
...
additionalparam-javafx/additionalparam
...
/configuration

-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

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: 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 ListChangeListenerDockingSplitPaneChildBase 
  dockingSplitPaneChildrenListener = new 
  ListChangeListenerDockingSplitPaneChildBase() {
   @Override
   public void onChanged(Change? extends DockingSplitPaneChildBase 
  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: 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 ListChangeListenerDockingSplitPaneChildBase 
dockingSplitPaneChildrenListener = new 
ListChangeListenerDockingSplitPaneChildBase() {
@Override
public void onChanged(Change? extends DockingSplitPaneChildBase 
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: 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 richard.b...@oracle.com:
 
  Yes, definitely.
  
  On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com 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 
  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 place, a skin 
  node looks back at siblings etc to determine if it can be placed in the 
  same layer as something before it. If so, then it 

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