hg: openjfx/8u-dev/rt: RT-35180 Scrolling by touch (sliding) is not possible on horizontal list view on embedded systems

2014-02-11 Thread hang . vo
Changeset: 0a78ff236166
Author:Martin Sladecek martin.slade...@oracle.com
Date:  2014-02-11 08:31 +
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0a78ff236166

RT-35180 Scrolling by touch (sliding) is not possible on horizontal list view 
on embedded systems
Reviewed by: jgiles

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java



hg: openjfx/8u-dev/rt: RT-21656 Touch : TextArea : while scrolling down, contents sometimes jumps to the top.

2014-02-11 Thread hang . vo
Changeset: e174b39cc4f1
Author:Martin Sladecek martin.slade...@oracle.com
Date:  2014-02-11 08:33 +
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e174b39cc4f1

RT-21656 Touch : TextArea : while scrolling down, contents sometimes jumps to 
the top.
Reviewed by: jgiles

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java



Re: SVG in CSS

2014-02-11 Thread Pedro Duque Vieira
Done: https://javafx-jira.kenai.com/browse/RT-35799

Sorry for the delay.

Thanks, best regards,


On Mon, Jan 27, 2014 at 9:36 PM, David Grieve david.gri...@oracle.comwrote:

 Great idea. You should create an issue on javafx-jira.kenai.com.

 On Jan 27, 2014, at 3:58 PM, Pedro Duque Vieira 
 pedro.duquevie...@gmail.com wrote:

  Hi,
 
  I recall having a conversation with a javafx team member and him saying
 it
  wasn't possible to input an url of an svg image as the background-image
 of
  a Region.
 
  If that is the case, I think it would be beneficial to add this feature -
  set the background-image of a region to be an svg file. Right now the
  process is a bit cumbersome: you have to convert an svg file to the svg
  path notation and then insert it into the -fx-shape field. So every time
  you want to change an svg image you have to go through this process, plus
  the fact that you can't see what is the image in the -fx-shape field
 unless
  you have some super processor inside your brain that can process svg path
  notation :-)
 
  Also, it would be good if the svg file could be styled via css as you can
  now do with the svg path in the -fx-shape property.
 
  Thanks, regards,
 
  --
  Pedro Duque Vieira




-- 
Pedro Duque Vieira


[8u20] Review request: RT-23406 RT-21664

2014-02-11 Thread Martin Sladecek

Hi Jonathan,

please review the following:

https://javafx-jira.kenai.com/browse/RT-23406
http://cr.openjdk.java.net/~msladecek/rt-23406/webrev.00/

https://javafx-jira.kenai.com/browse/RT-21664
http://cr.openjdk.java.net/~msladecek/rt-21664/webrev.00/

Thanks,
-Martin


hg: openjfx/8u-dev/rt: [RT-35537] [Lens] Enable multitouch by default

2014-02-11 Thread hang . vo
Changeset: c637c399d1f4
Author:Assaf Yavnai
Date:  2014-02-11 16:49 +0200
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c637c399d1f4

[RT-35537] [Lens] Enable multitouch by default

Summary: Multi touch is now enabled by default. Changed property 
com.sun.javafx.experimental.embedded.multiTouch to 
lens.input.forceSingleTouch, that will allow ST only mode.
Also update tests to ignore multi touch support flag

Tested-by: running LinuxInputTests, HelloSanity, HelloMultitouch

Reviewed by: dblaukopf

! 
modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java
! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c
! tests/system/src/test/java/com/sun/glass/ui/monocle/input/MultiTouch2Test.java
! tests/system/src/test/java/com/sun/glass/ui/monocle/input/MultiTouch3Test.java
! tests/system/src/test/java/com/sun/glass/ui/monocle/input/TestApplication.java
! tests/system/src/test/java/com/sun/glass/ui/monocle/input/TouchLagTest.java



hg: openjfx/8u-dev/rt: RT-35777: workaround for an old issue was no longer working. Apply new workaround.

2014-02-11 Thread hang . vo
Changeset: bf1fc37a1924
Author:David Grievedavid.gri...@oracle.com
Date:  2014-02-11 10:06 -0500
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bf1fc37a1924

RT-35777: workaround for an old issue was no longer working. Apply new 
workaround.

! modules/controls/src/main/java/javafx/scene/control/ContextMenu.java



hg: openjfx/8u-dev/rt: RT-35629: IDE Tooling for JavaFX Packager

2014-02-11 Thread hang . vo
Changeset: 063dd1a8e87d
Author:shemnon
Date:  2014-02-11 09:14 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/063dd1a8e87d

RT-35629: IDE Tooling for JavaFX Packager
Summary: Changes include adding a packager only access class, tools to add 
custom bundlers, I18N of messages, and moving to a 'bag of values' 
configuration style for the bundlers
Reviewed-by: mhowe, kcr

! .idea/fxpackager.iml
! .idea/rt.iml
! build.gradle
+ modules/fxpackager/src/main/java/com/oracle/bundlers/AbstractBundler.java
+ modules/fxpackager/src/main/java/com/oracle/bundlers/Bundler.java
+ modules/fxpackager/src/main/java/com/oracle/bundlers/BundlerParamInfo.java
+ modules/fxpackager/src/main/java/com/oracle/bundlers/Bundlers.java
+ 
modules/fxpackager/src/main/java/com/oracle/bundlers/EnumeratedBundlerParam.java
+ 
modules/fxpackager/src/main/java/com/oracle/bundlers/InvalidBundlerParamException.java
+ modules/fxpackager/src/main/java/com/oracle/bundlers/StandardBundlerParam.java
+ 
modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacAppStoreBundler.java
+ 
modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacBaseInstallerBundler.java
+ modules/fxpackager/src/main/java/com/oracle/bundlers/mac/MacPKGBundler.java
+ 
modules/fxpackager/src/main/java/com/oracle/bundlers/windows/WindowsBundlerParam.java
! modules/fxpackager/src/main/java/com/sun/javafx/tools/ant/DeployFXTask.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/DeployParams.java
! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/Log.java
! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/Main.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/PackagerLib.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/BundleParams.java
+ 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/BundleType.java
- 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/Bundler.java
+ 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/ConfigException.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/IOUtils.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxAppBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxDebBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxRPMBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/MacAppBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/MacDMGBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/RelativeFileSet.java
+ 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/UnsupportedPlatformException.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/WinAppBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/WinExeBundler.java
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/WinMsiBundler.java
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/AbstractBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/StandardBundlerParam.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxAppBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxDebBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxRpmBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/windows/WinAppBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/windows/WinExeBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/windows/WinMsiBundler.properties
+ 
modules/fxpackager/src/main/resources/com/oracle/bundlers/windows/WindowsBundlerParam.properties
! 
modules/fxpackager/src/main/resources/com/sun/javafx/tools/packager/Bundle.properties
! 
modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/windows/template.iss
! 
modules/fxpackager/src/main/resources/com/sun/javafx/tools/resource/windows/template.wxs
+ modules/fxpackager/src/test/java/com/oracle/bundlers/BundlersTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxAppBundlerTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxDebBundlerTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxRpmBundlerTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacAppBundlerTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacDMGBundlerTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacPKGBundlerTest.java
+ 
modules/fxpackager/src/test/java/com/oracle/bundlers/windows/RuntimeFlagsParserTest.java
+ 

Layout issue

2014-02-11 Thread John Hendrikx
From an earlier posting on this list, I came to understand that in 
JavaFX 8 it is no longer allowed to modify the children list in 
layoutChildren, and that such modifications may need to be moved to the 
computerPref* methods.


However, I get a different odd issue, and I'm wondering exactly what is 
allowed and what isn't when it comes to layout (any documentation on this?)


What's happening is the following:

I got a (subclass of) BorderPane, at the top I have a tab-like control 
(let's call it a FilterControl).  At the center I got a TreeView.


When the BorderPane gets laid out, I set up the content for both the 
TreeView and the FilterControl.  I do this in layoutChildren or in 
computerPref* of the BorderPane -- it makes no difference.  Setting up 
the content for the FilterControl involves changing its children list.  
The TreeView probably will do the same (adding/removing Cells as needed).


Now, I'm seeing layout issues.  The BorderPane for example is often 
putting the TreeView right on top of the FilterControl (stuff is 
transparent, so I can see it).  With other attempts, the FilterControl 
is not visible at all (zero height).  Forcing an update (by changing 
focus) usually clears up the issue and the FilterControl will take its 
rightful spot and force the TreeView to be a little less high.


I'm thinking this is somekind of issue with layout and that I'm 
approaching this wrong causing the layout problems.  However, I don't 
quite understand what I'm possibly doing wrong -- modifying the children 
of the Top node of the BorderPane during BorderPane's own 
computePref/layoutChildren call should be perfectly fine right?


Any help appreciated!

--John



hg: openjfx/8u-dev/rt: RT-35629: IDE Tooling for JavaFX Packager

2014-02-11 Thread hang . vo
Changeset: 9cd11a2481e7
Author:shemnon
Date:  2014-02-11 10:01 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9cd11a2481e7

RT-35629: IDE Tooling for JavaFX Packager

undo stray IDE file change

! .idea/rt.iml



Re: Layout issue

2014-02-11 Thread Martin Sladecek
The rule of thumb in case you modify content during the layout is that 
content should depend on layout pane size, not the other way around. It 
means that changing the content won't modify the min/pref/max size of 
the pane as that would trigger another layout pass (possibly falling 
into a loop).


This is why it's not recommended to change children during the layout, 
as default computation of min/pref/max size depends on the children. But 
if you modify compute* methods and return something that is not 
dependent on the children, you can safely modify them while doing the 
layout.


So, e.g. your filter control might return pref size that is approx. for 
2-3 tabs (or whatnot). Since BorderPane resizes top to the full width, 
you would always get the maximum width you can get. Based on the 
assigned width, you can then compute the layout and add as much tabs as 
you can. Since that would not change the pref width, the layout is done.


Anyway, as Jonathan already noted, a JIRA issue with some sample would 
be great.


Thanks,
-Martin

On 02/11/2014 05:50 PM, John Hendrikx wrote:
From an earlier posting on this list, I came to understand that in 
JavaFX 8 it is no longer allowed to modify the children list in 
layoutChildren, and that such modifications may need to be moved to 
the computerPref* methods.


However, I get a different odd issue, and I'm wondering exactly what 
is allowed and what isn't when it comes to layout (any documentation 
on this?)


What's happening is the following:

I got a (subclass of) BorderPane, at the top I have a tab-like control 
(let's call it a FilterControl).  At the center I got a TreeView.


When the BorderPane gets laid out, I set up the content for both the 
TreeView and the FilterControl.  I do this in layoutChildren or in 
computerPref* of the BorderPane -- it makes no difference. Setting up 
the content for the FilterControl involves changing its children 
list.  The TreeView probably will do the same (adding/removing Cells 
as needed).


Now, I'm seeing layout issues.  The BorderPane for example is often 
putting the TreeView right on top of the FilterControl (stuff is 
transparent, so I can see it).  With other attempts, the FilterControl 
is not visible at all (zero height).  Forcing an update (by changing 
focus) usually clears up the issue and the FilterControl will take its 
rightful spot and force the TreeView to be a little less high.


I'm thinking this is somekind of issue with layout and that I'm 
approaching this wrong causing the layout problems.  However, I don't 
quite understand what I'm possibly doing wrong -- modifying the 
children of the Top node of the BorderPane during BorderPane's own 
computePref/layoutChildren call should be perfectly fine right?


Any help appreciated!

--John





Dragboard setDragView in JFXPanel?

2014-02-11 Thread Jeff Martin
Is the JavaFX 8 Dragboard.setDragView() api supposed to work in JFXPanel?

I couldn't find a jira bug - if it should work, I'll file one.

jeff


Re: Dragboard setDragView in JFXPanel?

2014-02-11 Thread Anthony Petrov

Please file a bug.

--
best regards,
Anthony

On 2/12/2014 2:59 AM, Jeff Martin wrote:

Is the JavaFX 8 Dragboard.setDragView() api supposed to work in JFXPanel?

I couldn't find a jira bug - if it should work, I'll file one.

jeff



Re: Dragboard setDragView in JFXPanel?

2014-02-11 Thread Jeff Martin
Okay, it's filed: https://javafx-jira.kenai.com/browse/RT-35812

I'd appreciate any additional info: Was it expected to work? Any thoughts on a 
work around?

Let me know if you want me to post my sample code in the jira.

jeff


On Feb 11, 2014, at 5:13 PM, Anthony Petrov anthony.pet...@oracle.com wrote:

 Please file a bug.
 
 --
 best regards,
 Anthony
 
 On 2/12/2014 2:59 AM, Jeff Martin wrote:
 Is the JavaFX 8 Dragboard.setDragView() api supposed to work in JFXPanel?
 
 I couldn't find a jira bug - if it should work, I'll file one.
 
 jeff