hg: openjfx/8u-dev/rt: Follow-up fix for RT-38418 - copy paste error when splitting the line length.
Changeset: 27e5fd37a940 Author:Martin Sladecek Date: 2014-09-18 08:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27e5fd37a940 Follow-up fix for RT-38418 - copy paste error when splitting the line length. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
[8u40] Code Review Request For RT-38651: ES2: Need to provide query and print out (on verbose) support for OpenGL ES2 implementation dependent limits
Hi Kevin and Jim, Please review the proposed enhancement: https://javafx-jira.kenai.com/browse/RT-38651 Thanks, - Chien
8u40 review request: RT-37356 SW pipeline renders progress bar too darkly
webrev: http://cr.openjdk.java.net/~flar/RT-37356/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-37356 Details in the Jira comments... ...jim
[8u40] Request for review: RT-34893: [Media] Use of QuickTime prevents Mac AppStore Submission
JIRA issue: https://javafx-jira.kenai.com/browse/RT-34893 Webrev: http://cr.openjdk.java.net/~ddehaven/RT-34893/rt.1/ Overview: - Added AVFoundation based player class, implemented as a standalone module that will load only on 10.8 or later - Refactored some classes that were hard wired for GStreamer (namely: Audio EQ and spectrum) - Removed a couple unused/unnecessary internal media APIs - Changed how video data is sent to prism, instead of using a single buffer and offsets for planes, now we have a buffer for each plane since it's possible we could get frames that have non-contiguous plane buffers. Chunky formats just use plane 0. - Added planar Y'CbCr 4:2:0 rendering support - Added a convenience Xcode project, not used for building but it helps with development significantly - Added Xcode/OSX droppings to .hgignore, plus a couple other things that should be in there - Performed some needed media code cleanup: + modernized some for loops + lambda-ified a few places in media that sorely needed it + updated copyright dates + marked a bunch of fields final that should have been originally + added @Override annotations as appropriate to remove annoying yellow marks in Netbeans Jim and Lisa, please check the prism changes. Those will affect all platforms. Alexander and Kirill will review the media changes. Kevin, Steve please take a look at everything else like the build system. -DrD-
hg: openjfx/8u-dev/rt: Fix RT-38556: LinearGradient with large number of stops can cause error on Scene background fill
Changeset: b5c3e59824b8 Author:flar Date: 2014-09-17 14:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b5c3e59824b8 Fix RT-38556: LinearGradient with large number of stops can cause error on Scene background fill Reviewed by: chien ! modules/graphics/src/main/java/com/sun/prism/impl/BaseContext.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderContext.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java
hg: openjfx/8u/rt: Added tag 8u40-b06 for changeset 957060db6fa5
Changeset: dc7dc0fa856b Author:hudson Date: 2014-09-17 13:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8u/rt/rev/dc7dc0fa856b Added tag 8u40-b06 for changeset 957060db6fa5 ! .hgtags
Close all ContextMenu with mouse button
Hi All, Is there a way to close all opened context menus opened on the scene? When I press a button I would like to close all Context menus opened by right muse click. BR, Peter
Re: Subclassing behavior in JavaFX Controls
Hi Pete,
On Wed, Sep 17, 2014 at 9:35 PM, Pete Moss wrote:
> Tomas,
>
> Thanks for the fast reply.
>
> I read your blog post that you referenced and I agree with you 100%. I am a
> crusty MVC person and I agree, that having the Skin class (View) hold a
> reference to the Behavior class (Controller) rubs me the wrong way from an
> MVC perspective.
>
> I was looking at the JavaFX source code and trying to figure out the easiest
> source code path to a fix. But I agree with you that a slight redesign would
> be better to bring it closer to a purer MVC approach (to loosely quote
> General Jack D. Ripper, we must strive for a Purity Of Essence). ;)
>
> Doing what you propose would provide a much greater degree of flexibility to
> subclass the skin, behavior or both.
>
> I read the back and forth between you and Jonathan Giles on your blog post,
> and although I agree with you that a refactoring and restructuring would be
> better, I understand Jonathan's point of view, given that the horse is out
> of the barn with the current APIs and what you are proposing is a little
> more invasive.
The only thing that is out is SkinBase, which is an encapsulation of
both the View and the Controller. Whether and how you separate the
view and the controller within your instance of SkinBase is left
completely up to you, as far as the current public API goes. This
means it is not too late for a change. It is not even invasive:
current controls can keep using the private BehaviorSkinBase, or be
moved to the new solution gradually.
>
> Which brings me back to my post and my desires to subclass skin, behavior or
> both for existing JavaFX Controls. It seems impossible to subclass skin and
> behavior. Replace, yes, but not subclass (augment).
I believe that overriding keyboard shortcuts should be doable without
subclassing the skin (or behavior). I'm working on something right now
and hope to publish something soon.
Best,
Tomas
>
> Again, any suggestions for workarounds would be appreciated.
>
>
>
> On Wed, Sep 17, 2014 at 3:02 PM, Tomas Mikula
> wrote:
>>
>> Hi Pete,
>>
>> work on this is tracked in https://javafx-jira.kenai.com/browse/RT-21598
>>
>> In terms of the current API, I think the best solution is to add event
>> handlers and/or event filters on the TableView.
>>
>> Regarding your proposed fixes, I have a blog post where I argue that
>> the wiring between the Behavior and the ("View" aspect of the) Skin
>> should be reversed, i.e. that the Behavior should hold a reference to
>> the View, not vice versa. That is, for example, against both your
>> proposed fixes. (Note that the blog post represents my personal view
>> only.)
>> http://tomasmikula.github.io/blog/2014/06/11/separation-of-view-and-controller-in-javafx-controls.html
>>
>> Incidendally, I'm currently working on a solution to add/override
>> keyboard shortcuts. I should be able to publish something soon.
>>
>> Best,
>> Tomas
>>
>> On Wed, Sep 17, 2014 at 8:36 PM, Pete Moss wrote:
>> > I am starting to work with the TableView JavaFX Control. I see that it
>> > has
>> > some nominal keyboard handling, but it is incomplete for my needs. From
>> > what I understand about the JavaFX Control architecture, all of the
>> > JavaFX
>> > Control-derived classes use a Skin class created via
>> > Control.createDefaultSkin() which, in turn, contains a behavior class
>> > that
>> > is derived from BehaviorSkinBase.
>> >
>> > However, an Oracle publication says that Control developers should NOT
>> > use
>> > BehaviorSkinBase since that is a private API.
>> >
>> > So here is the problem. I am trying to augment the behavior of the
>> > TableView class. The keyboard handling is done in TableViewBehavior so
>> > it
>> > would be nice for me to supply a subclassed version of TableViewBehavior
>> > to
>> > augment that behavior or override some of it. But I can't. If you look
>> > at
>> > the TableViewSkin class, here is the ctor that gets used:
>> >
>> > public TableViewSkin(final TableView tableView) {
>> > super(tableView, new TableViewBehavior(tableView));
>> >
>> >...
>> >}
>> >
>> > Because this is the only ctor available for TableViewSkin, I don't see
>> > any
>> > way I can subclass TableViewSkin and supply my own behavior instance. I
>> > can, of course, create my own skin, but then I would lose the code in
>> > TableViewSkin (unless I shamelessly copied it, which I don't want to
>> > do).
>> >
>> > It seems to me there could be a couple of different ways to fix this:
>> > 1) Add an alternative ctor that takes a behavior instance as a second
>> > argument. Then refactor the original ctor to call this, eg,
>> > public TableViewSkin(final TableView tableView, BehaviorSkinBase
>> > behavior) {
>> > super(tableView, behavior);
>> >
>> >...
>> >}
>> >
>> >public TableViewSkin(final TableView tableView) {
>> > this(tableView, new TableViewBehavior(tableView));
>> >}
>> >
>> > 2) Add a factory method for the behavio
Re: Subclassing behavior in JavaFX Controls
Tomas,
Thanks for the fast reply.
I read your blog post that you referenced and I agree with you 100%. I am a
crusty MVC person and I agree, that having the Skin class (View) hold a
reference to the Behavior class (Controller) rubs me the wrong way from an
MVC perspective.
I was looking at the JavaFX source code and trying to figure out the
easiest source code path to a fix. But I agree with you that a slight
redesign would be better to bring it closer to a purer MVC approach (to
loosely quote General Jack D. Ripper, we must strive for a Purity Of
Essence). ;)
Doing what you propose would provide a much greater degree of flexibility
to subclass the skin, behavior or both.
I read the back and forth between you and Jonathan Giles on your blog post,
and although I agree with you that a refactoring and restructuring would be
better, I understand Jonathan's point of view, given that the horse is out
of the barn with the current APIs and what you are proposing is a little
more invasive.
Which brings me back to my post and my desires to subclass skin, behavior
or both for existing JavaFX Controls. It seems impossible to subclass skin
and behavior. Replace, yes, but not subclass (augment).
Again, any suggestions for workarounds would be appreciated.
On Wed, Sep 17, 2014 at 3:02 PM, Tomas Mikula
wrote:
> Hi Pete,
>
> work on this is tracked in https://javafx-jira.kenai.com/browse/RT-21598
>
> In terms of the current API, I think the best solution is to add event
> handlers and/or event filters on the TableView.
>
> Regarding your proposed fixes, I have a blog post where I argue that
> the wiring between the Behavior and the ("View" aspect of the) Skin
> should be reversed, i.e. that the Behavior should hold a reference to
> the View, not vice versa. That is, for example, against both your
> proposed fixes. (Note that the blog post represents my personal view
> only.)
> http://tomasmikula.github.io/blog/2014/06/11/separation-of-view-and-controller-in-javafx-controls.html
>
> Incidendally, I'm currently working on a solution to add/override
> keyboard shortcuts. I should be able to publish something soon.
>
> Best,
> Tomas
>
> On Wed, Sep 17, 2014 at 8:36 PM, Pete Moss wrote:
> > I am starting to work with the TableView JavaFX Control. I see that it
> has
> > some nominal keyboard handling, but it is incomplete for my needs. From
> > what I understand about the JavaFX Control architecture, all of the
> JavaFX
> > Control-derived classes use a Skin class created via
> > Control.createDefaultSkin() which, in turn, contains a behavior class
> that
> > is derived from BehaviorSkinBase.
> >
> > However, an Oracle publication says that Control developers should NOT
> use
> > BehaviorSkinBase since that is a private API.
> >
> > So here is the problem. I am trying to augment the behavior of the
> > TableView class. The keyboard handling is done in TableViewBehavior so it
> > would be nice for me to supply a subclassed version of TableViewBehavior
> to
> > augment that behavior or override some of it. But I can't. If you look at
> > the TableViewSkin class, here is the ctor that gets used:
> >
> > public TableViewSkin(final TableView tableView) {
> > super(tableView, new TableViewBehavior(tableView));
> >
> >...
> >}
> >
> > Because this is the only ctor available for TableViewSkin, I don't see
> any
> > way I can subclass TableViewSkin and supply my own behavior instance. I
> > can, of course, create my own skin, but then I would lose the code in
> > TableViewSkin (unless I shamelessly copied it, which I don't want to do).
> >
> > It seems to me there could be a couple of different ways to fix this:
> > 1) Add an alternative ctor that takes a behavior instance as a second
> > argument. Then refactor the original ctor to call this, eg,
> > public TableViewSkin(final TableView tableView, BehaviorSkinBase
> > behavior) {
> > super(tableView, behavior);
> >
> >...
> >}
> >
> >public TableViewSkin(final TableView tableView) {
> > this(tableView, new TableViewBehavior(tableView));
> >}
> >
> > 2) Add a factory method for the behavior instance:
> > public TableViewSkin(final TableView tableView) {
> >BehaviorSkinBase behavior = behaviorFactory(tableView);
> >
> >super(tableView, behavior);
> >
> >...
> >}
> >
> > protected BehaviorSkinBase behaviorFactory(TableView tableView)
> > {
> >return new TableViewBehavior(tableView);
> > }
> >
> > I see this as a shortcoming in the JavaFX architecture. If I were
> building
> > a custom Control, it would not be so bad since I would provide an
> > additional Skin ctor that takes a behavior class as an arg, but it seems
> > that the way the code is currently structured, it is difficult to
> subclass
> > a JavaFX Control and subclass its skin and behavior too.
> >
> > Any thoughts on how to workaround/solve this would be greatly
> appreciated.
>
[8u40] post-commit review: : RT-38481: [Logger] JavaFX apps fail to start if jfr.jar is removed from JRE
Post-commit review for: https://javafx-jira.kenai.com/browse/RT-38481 Simple change to catch NCDFE when loading the JFR-based pulse logger in addition to the exceptions already caught. -- Kevin --- Begin Message --- Changeset: 3cc103a35bee Author:kcr Date: 2014-09-17 11:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3cc103a35bee RT-38481: [Logger] JavaFX apps fail to start if jfr.jar is removed from JRE ! modules/base/src/main/java/com/sun/javafx/logging/PulseLogger.java --- End Message ---
hg: openjfx/8u-dev/rt: RT-38481: [Logger] JavaFX apps fail to start if jfr.jar is removed from JRE
Changeset: 3cc103a35bee Author:kcr Date: 2014-09-17 11:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3cc103a35bee RT-38481: [Logger] JavaFX apps fail to start if jfr.jar is removed from JRE ! modules/base/src/main/java/com/sun/javafx/logging/PulseLogger.java
Re: Subclassing behavior in JavaFX Controls
Hi Pete,
work on this is tracked in https://javafx-jira.kenai.com/browse/RT-21598
In terms of the current API, I think the best solution is to add event
handlers and/or event filters on the TableView.
Regarding your proposed fixes, I have a blog post where I argue that
the wiring between the Behavior and the ("View" aspect of the) Skin
should be reversed, i.e. that the Behavior should hold a reference to
the View, not vice versa. That is, for example, against both your
proposed fixes. (Note that the blog post represents my personal view
only.)
http://tomasmikula.github.io/blog/2014/06/11/separation-of-view-and-controller-in-javafx-controls.html
Incidendally, I'm currently working on a solution to add/override
keyboard shortcuts. I should be able to publish something soon.
Best,
Tomas
On Wed, Sep 17, 2014 at 8:36 PM, Pete Moss wrote:
> I am starting to work with the TableView JavaFX Control. I see that it has
> some nominal keyboard handling, but it is incomplete for my needs. From
> what I understand about the JavaFX Control architecture, all of the JavaFX
> Control-derived classes use a Skin class created via
> Control.createDefaultSkin() which, in turn, contains a behavior class that
> is derived from BehaviorSkinBase.
>
> However, an Oracle publication says that Control developers should NOT use
> BehaviorSkinBase since that is a private API.
>
> So here is the problem. I am trying to augment the behavior of the
> TableView class. The keyboard handling is done in TableViewBehavior so it
> would be nice for me to supply a subclassed version of TableViewBehavior to
> augment that behavior or override some of it. But I can't. If you look at
> the TableViewSkin class, here is the ctor that gets used:
>
> public TableViewSkin(final TableView tableView) {
> super(tableView, new TableViewBehavior(tableView));
>
>...
>}
>
> Because this is the only ctor available for TableViewSkin, I don't see any
> way I can subclass TableViewSkin and supply my own behavior instance. I
> can, of course, create my own skin, but then I would lose the code in
> TableViewSkin (unless I shamelessly copied it, which I don't want to do).
>
> It seems to me there could be a couple of different ways to fix this:
> 1) Add an alternative ctor that takes a behavior instance as a second
> argument. Then refactor the original ctor to call this, eg,
> public TableViewSkin(final TableView tableView, BehaviorSkinBase
> behavior) {
> super(tableView, behavior);
>
>...
>}
>
>public TableViewSkin(final TableView tableView) {
> this(tableView, new TableViewBehavior(tableView));
>}
>
> 2) Add a factory method for the behavior instance:
> public TableViewSkin(final TableView tableView) {
>BehaviorSkinBase behavior = behaviorFactory(tableView);
>
>super(tableView, behavior);
>
>...
>}
>
> protected BehaviorSkinBase behaviorFactory(TableView tableView)
> {
>return new TableViewBehavior(tableView);
> }
>
> I see this as a shortcoming in the JavaFX architecture. If I were building
> a custom Control, it would not be so bad since I would provide an
> additional Skin ctor that takes a behavior class as an arg, but it seems
> that the way the code is currently structured, it is difficult to subclass
> a JavaFX Control and subclass its skin and behavior too.
>
> Any thoughts on how to workaround/solve this would be greatly appreciated.
Subclassing behavior in JavaFX Controls
I am starting to work with the TableView JavaFX Control. I see that it has
some nominal keyboard handling, but it is incomplete for my needs. From
what I understand about the JavaFX Control architecture, all of the JavaFX
Control-derived classes use a Skin class created via
Control.createDefaultSkin() which, in turn, contains a behavior class that
is derived from BehaviorSkinBase.
However, an Oracle publication says that Control developers should NOT use
BehaviorSkinBase since that is a private API.
So here is the problem. I am trying to augment the behavior of the
TableView class. The keyboard handling is done in TableViewBehavior so it
would be nice for me to supply a subclassed version of TableViewBehavior to
augment that behavior or override some of it. But I can't. If you look at
the TableViewSkin class, here is the ctor that gets used:
public TableViewSkin(final TableView tableView) {
super(tableView, new TableViewBehavior(tableView));
...
}
Because this is the only ctor available for TableViewSkin, I don't see any
way I can subclass TableViewSkin and supply my own behavior instance. I
can, of course, create my own skin, but then I would lose the code in
TableViewSkin (unless I shamelessly copied it, which I don't want to do).
It seems to me there could be a couple of different ways to fix this:
1) Add an alternative ctor that takes a behavior instance as a second
argument. Then refactor the original ctor to call this, eg,
public TableViewSkin(final TableView tableView, BehaviorSkinBase
behavior) {
super(tableView, behavior);
...
}
public TableViewSkin(final TableView tableView) {
this(tableView, new TableViewBehavior(tableView));
}
2) Add a factory method for the behavior instance:
public TableViewSkin(final TableView tableView) {
BehaviorSkinBase behavior = behaviorFactory(tableView);
super(tableView, behavior);
...
}
protected BehaviorSkinBase behaviorFactory(TableView tableView)
{
return new TableViewBehavior(tableView);
}
I see this as a shortcoming in the JavaFX architecture. If I were building
a custom Control, it would not be so bad since I would provide an
additional Skin ctor that takes a behavior class as an arg, but it seems
that the way the code is currently structured, it is difficult to subclass
a JavaFX Control and subclass its skin and behavior too.
Any thoughts on how to workaround/solve this would be greatly appreciated.
[8u40] Review request: RT-36449 [WebView] URLLoader throws an exception on 401 HTTP error with no body
Hi Leonid, Kevin, Please review a fix: https://javafx-jira.kenai.com/browse/RT-36449 http://cr.openjdk.java.net/~ant/RT-36449/webrev.0 Thanks, Anton.
Re: RichTextEditor in 8u40
Hi Peter, There was never an intent to have a RichTextEditor for 8u40. The wiki is tracking milestones for committed work and the possibility of starting work on a RichTextEditor prototype. At this point, given the bug backlog and other work that is targeted to 8u40, it's looking very unlikely that we will get to this. Steve On 2014-09-17, 8:11 AM, Peter Penzov wrote: Hi All, Looking at the 8u40 road map there are plans for RichTextEdito: https://wiki.openjdk.java.net/display/OpenJFX/8u40 Is there any code example that I can test? BR, Peter
Re: Time spinner in 8u40
Hi Peter, There are no plans to make the time spinner public for 8u40 as we are past FF (Feature Freeze). Originally, the time spinner was intended to be part of the new spinner control but there were some issues with it involving tracking the caret. It's all discussed in: https://javafx-jira.kenai.com/browse/RT-37968 Steve On 2014-09-17, 6:22 AM, Peter Penzov wrote: Hi All, I successfully tested Spinner control in 8u40. final Spinner spinner = new Spinner(); spinner.setValueFactory(new SpinnerValueFactory.IntegerSpinnerValueFactory(0, 1)); spinner.setEditable(true); I noticed that there is a Java method for time spinner LocalDateSpinnerValueFactory in SpinnerValueFactory. But the Java Method is not public. Are there plans to release time spinner in 8u40? BR, Peter
RichTextEditor in 8u40
Hi All, Looking at the 8u40 road map there are plans for RichTextEdito: https://wiki.openjdk.java.net/display/OpenJFX/8u40 Is there any code example that I can test? BR, Peter
Time spinner in 8u40
Hi All, I successfully tested Spinner control in 8u40. final Spinner spinner = new Spinner(); spinner.setValueFactory(new SpinnerValueFactory.IntegerSpinnerValueFactory(0, 1)); spinner.setEditable(true); I noticed that there is a Java method for time spinner LocalDateSpinnerValueFactory in SpinnerValueFactory. But the Java Method is not public. Are there plans to release time spinner in 8u40? BR, Peter
hg: openjfx/8u-dev/rt: RT-38667 [SpltPane] Cannot set divider position in multiple splitpanes at once under certain conditions
Changeset: 26b2ed1d5d5b Author:Martin Sladecek Date: 2014-09-17 09:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/26b2ed1d5d5b RT-38667 [SpltPane] Cannot set divider position in multiple splitpanes at once under certain conditions Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! modules/controls/src/test/java/javafx/scene/control/SplitPaneTest.java
hg: openjfx/8u-dev/rt: RT-38418 Dashed border with width is broken
Changeset: f73646deab84 Author:Martin Sladecek Date: 2014-09-17 09:31 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f73646deab84 RT-38418 Dashed border with width is broken RT-38493 [Region] After RT-38297, rectangular Region borders are drawn incorrectly Reviewed by: flar ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
