Re: Disabling JavaFX minimise/maximise/etc buttons
Hi Jonathan, I believe this has been neither requested nor discussed so far. I don't see why this couldn't be added, it just might have to be a conditional feature, we'll have to check. Feel free to file a feature request. Regards, Pavel On 21.7.2013 4:44, Jonathan Giles wrote: Hi all, For once this is a request for more information from another JavaFX team, rather than a review request, etc! :-) I'm keen to see support in JavaFX Stage / Window classes for an API that would allow for the minimize / maximize / full screen / etc buttons to be disabled. I'm aware of the StageStyle.UTLITY option (which does disable the minimize button), but sometimes you don't want a utility stage style, but you do want to prevent minimizing a stage. My particular use case is dialogs - you can see a discussion of the issue at [1]. For example, I note that Stage has an iconfied property to represent whether the stage is minimized, but no property to specify whether the stage should be allowed to be iconified (setIconifiable(boolean), boolean isIconifiable(), for example). Is there a reason for this or just that this API hasn't been required yet? In short, I would love API to allow me to specify whether a stage can be minimised, maximised and made full screen, and for this to follow through to the buttons available in the native titlebar area of the stage. Does such an API exist, is there a valid reason why it doesn't, or should I file a jira to request such API? [1] https://bitbucket.org/controlsfx/controlsfx/issue/49/dialogs-should-use-native-title-bars Thanks! -- Jonathan
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 23dceeb90d32 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-22 11:15 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/23dceeb90d32 RT-26892 Deploy code calls GlassAppletWindows.getRemoteLayerId() from thread other than FX application thread Reviewed-by: art, anthony ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassAppletWindow.java Changeset: 8d3d5313f667 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-22 11:28 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8d3d5313f667 RT-31750 Mac: NPE when quitting a JavaFX app Reviewed-by: art, anthony ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassStage.java
Re: Thread checks in Glass
Seems as if the ticket isn't public... On 22.07.2013 11:06, Petr Pchelko wrote: You can follow progress inhttps://javafx-jira.kenai.com/browse/RT-26891
Re: Thread checks in Glass
Seems as if the ticket isn't public... Sorry for that. Fixed. With best regards. Petr. On Jul 22, 2013, at 1:22 PM, Werner Lehmann wrote: Seems as if the ticket isn't public... On 22.07.2013 11:06, Petr Pchelko wrote: You can follow progress inhttps://javafx-jira.kenai.com/browse/RT-26891
hg: openjfx/8/graphics/rt: 3 new changesets
Changeset: 920f414235bd Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-22 13:32 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/920f414235bd RT-28487 Add @FunctionalInterface to EventHandler, Callback ! modules/base/src/main/java/javafx/beans/InvalidationListener.java ! modules/base/src/main/java/javafx/beans/value/ChangeListener.java ! modules/base/src/main/java/javafx/collections/ListChangeListener.java ! modules/base/src/main/java/javafx/collections/MapChangeListener.java ! modules/base/src/main/java/javafx/collections/SetChangeListener.java ! modules/base/src/main/java/javafx/event/EventHandler.java ! modules/base/src/main/java/javafx/util/Builder.java ! modules/base/src/main/java/javafx/util/BuilderFactory.java ! modules/base/src/main/java/javafx/util/Callback.java ! modules/graphics/src/main/java/javafx/animation/Interpolatable.java ! modules/graphics/src/main/java/javafx/animation/Interpolator.java Changeset: b3fa631870e6 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-22 13:33 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b3fa631870e6 Automated merge with file:///home/martin/work/jfx-80-sync/rt Changeset: 4c672a0142c4 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-22 13:34 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4c672a0142c4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfxrt
hg: openjfx/8/graphics/rt: SW pipeline: proportional gradients were badly applied (RT-31396)
Changeset: 99c1c7b7260a Author:Martin Soch martin.s...@oracle.com Date: 2013-07-22 14:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/99c1c7b7260a SW pipeline: proportional gradients were badly applied (RT-31396) ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java
hg: openjfx/8/graphics/rt: RT-31823: IllegalStateException on shutdown
Changeset: a2325b6406bc Author:Alexander Zvegintsev Date: 2013-07-22 19:06 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a2325b6406bc RT-31823: IllegalStateException on shutdown ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java
Re: Disabling JavaFX minimise/maximise/etc buttons
On 7/22/2013 11:14 AM, Pavel Safrata wrote: Hi Jonathan, I believe this has been neither requested nor discussed so far. I don't see why this couldn't be added, it just might have to be a conditional feature, we'll have to check. Feel free to file a feature request. Some native platforms (mostly, X window managers) don't provide direct APIs to enable/disable certain window decoration buttons. A library or an application may provides some hints, which may or may not be respected by WM. I like what we have right now, StageStyle approach. Application defines the purpose of the window and let the platform decide, what are available actions for it. Thanks, Artem Regards, Pavel On 21.7.2013 4:44, Jonathan Giles wrote: Hi all, For once this is a request for more information from another JavaFX team, rather than a review request, etc! :-) I'm keen to see support in JavaFX Stage / Window classes for an API that would allow for the minimize / maximize / full screen / etc buttons to be disabled. I'm aware of the StageStyle.UTLITY option (which does disable the minimize button), but sometimes you don't want a utility stage style, but you do want to prevent minimizing a stage. My particular use case is dialogs - you can see a discussion of the issue at [1]. For example, I note that Stage has an iconfied property to represent whether the stage is minimized, but no property to specify whether the stage should be allowed to be iconified (setIconifiable(boolean), boolean isIconifiable(), for example). Is there a reason for this or just that this API hasn't been required yet? In short, I would love API to allow me to specify whether a stage can be minimised, maximised and made full screen, and for this to follow through to the buttons available in the native titlebar area of the stage. Does such an API exist, is there a valid reason why it doesn't, or should I file a jira to request such API? [1] https://bitbucket.org/controlsfx/controlsfx/issue/49/dialogs-should-use-native-title-bars Thanks! -- Jonathan
hg: openjfx/8/graphics/rt: RT-31763 EGLFB: Incorrect DPI reported on platforms with unknown screen size
Changeset: 8f42ebbbef9d Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2013-07-22 19:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8f42ebbbef9d RT-31763 EGLFB: Incorrect DPI reported on platforms with unknown screen size ! modules/graphics/src/main/native-glass/lens/wm/screen/fbdevScreen.c
Re: Mixing 2D and 3D
I'm a little confused, are this changes still going to be present in JavaFX8? I thought JavaFX8 was feature freeze (1 month ago), but I see that some major API discussions are still taking place. Regards, -- Pedro Duque Vieira
Re: Mixing 2D and 3D
Feature freeze doesn't mean that there won't be changes -- just that every major feature has an implementation and is ready for testing. Inevitably, as we use new features, we'll find that there needs to be modifications or clarifications. Once we ship, the possibility to refine is greatly reduced. Richard On Jul 22, 2013, at 9:10 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: I'm a little confused, are this changes still going to be present in JavaFX8? I thought JavaFX8 was feature freeze (1 month ago), but I see that some major API discussions are still taking place. Regards, -- Pedro Duque Vieira
Re: Disabling JavaFX minimise/maximise/etc buttons
Hi Artem, Do you propose to add another StageStyle - namely, a DIALOG? Note that styles cannot be combined in a mask, meaning that developers won't be able to create e.g. transparent dialogs, or utility dialogs. Generally, I like the idea of defining the purpose of a window and letting the OS/GUI toolkit decide what works best for it, but I'm not sure if we can apply it for this particular use case. Also, I think that ability to disable maximization/minimization of a window might be useful for purposes other than just displaying dialogs. BTW, isn't the setResizable(false) a good approximation for our requirements? You can still minimize such a window, but I think this is reasonable. E.g. OS X will minimize both the dialog and its owner window, allowing a user to perform other tasks unrelated to the dialog and windows it blocks. Why do we want to disable minimization? -- best regards, Anthony On 07/22/2013 07:20 PM, Artem Ananiev wrote: On 7/22/2013 11:14 AM, Pavel Safrata wrote: Hi Jonathan, I believe this has been neither requested nor discussed so far. I don't see why this couldn't be added, it just might have to be a conditional feature, we'll have to check. Feel free to file a feature request. Some native platforms (mostly, X window managers) don't provide direct APIs to enable/disable certain window decoration buttons. A library or an application may provides some hints, which may or may not be respected by WM. I like what we have right now, StageStyle approach. Application defines the purpose of the window and let the platform decide, what are available actions for it. Thanks, Artem Regards, Pavel On 21.7.2013 4:44, Jonathan Giles wrote: Hi all, For once this is a request for more information from another JavaFX team, rather than a review request, etc! :-) I'm keen to see support in JavaFX Stage / Window classes for an API that would allow for the minimize / maximize / full screen / etc buttons to be disabled. I'm aware of the StageStyle.UTLITY option (which does disable the minimize button), but sometimes you don't want a utility stage style, but you do want to prevent minimizing a stage. My particular use case is dialogs - you can see a discussion of the issue at [1]. For example, I note that Stage has an iconfied property to represent whether the stage is minimized, but no property to specify whether the stage should be allowed to be iconified (setIconifiable(boolean), boolean isIconifiable(), for example). Is there a reason for this or just that this API hasn't been required yet? In short, I would love API to allow me to specify whether a stage can be minimised, maximised and made full screen, and for this to follow through to the buttons available in the native titlebar area of the stage. Does such an API exist, is there a valid reason why it doesn't, or should I file a jira to request such API? [1] https://bitbucket.org/controlsfx/controlsfx/issue/49/dialogs-should-use-native-title-bars Thanks! -- Jonathan
Re: Thread checks in Glass
The first part of the checking is being done at the Glass level. More checking is under consideration but making native calls from the wrong thread can cause crashes and these are the most important things to fix first. Steve On 22/07/2013 12:08 PM, Pedro Duque Vieira wrote: You mean like checking every possible call to ensure it is made in the UI thread? Or just some? I think this is great! Regards, Hello all, FX is a single threaded UI toolkit. Well written FX applications should not access FX objects from outside the UI thread. There are exceptions to this rule and these are well documented. Documentation is great, but enforcing thread checks in code is better. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. This is goodness. Many threading issues in FX, Quantum and Prism have been found and fixed as a result of this change. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 Petr Steve
hg: openjfx/8/graphics/rt: RT-31798 remove GRADLE_BUILD workaround
Changeset: 869e80daa186 Author:ddhill Date: 2013-07-22 17:09 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/869e80daa186 RT-31798 remove GRADLE_BUILD workaround ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/linux.gradle ! buildSrc/mac.gradle ! buildSrc/win.gradle ! buildSrc/x86egl.gradle ! modules/graphics/src/main/native-prism-es2/PrismES2Defs.h ! modules/graphics/src/main/native-prism-es2/macosx/MacOSXWindowSystemInterface.m
hg: openjfx/8/graphics/rt: 13 new changesets
Changeset: aa1f69d49266 Author:hudson Date: 2013-07-18 11:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/aa1f69d49266 Added tag 8.0-b99 for changeset 34fab9fcc574 ! .hgtags Changeset: be8d3ccdc6d7 Author:mv157916 Date: 2013-07-18 23:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/be8d3ccdc6d7 RT-31773: Update the JDK build number to b99 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 64763d7be26b Author:jgiles Date: 2013-07-17 10:51 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/64763d7be26b RT-31675: TableViewSkinBase : make scrollHorizontally protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java Changeset: 558c220f61c7 Author:jgiles Date: 2013-07-17 11:27 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/558c220f61c7 RT-31674: NestedTableColumnHeader : Make Label / setHeadersNeedUpdate() protected (I've not made label protected, that can be accessed by subclasses via getChildren()). ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: 17b663243c52 Author:jgiles Date: 2013-07-18 10:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/17b663243c52 RT-31206: [TableView] custom skin replacements fails, when columns or data is added. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java Changeset: c5ca616dfee5 Author:jgiles Date: 2013-07-18 11:30 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c5ca616dfee5 RT-31489: Label width is often off by one. Bounds calculation results in poor right alignment. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 1740c1d19cc1 Author:jgiles Date: 2013-07-18 14:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1740c1d19cc1 RT-31200: ListView and possibly TableView and TreeView call Cell.updateItem() when the item hasn't changed. ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxListCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/ListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/CheckBoxListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/CheckBoxTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/CheckBoxTreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/CheckBoxTreeTableCellTest.java Changeset: 537ed8141418 Author:jgiles Date: 2013-07-18 14:31 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/537ed8141418 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: fe5ae99c078b Author:David Grievedavid.gri...@oracle.com Date: 2013-07-18 15:22 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fe5ae99c078b [UNIT TEST] RT-31305: remove @Ignore ! modules/graphics/src/stub/java/com/sun/javafx/css/FontTypeTest.java Changeset: fd774bff36a7 Author:David Grievedavid.gri...@oracle.com Date: 2013-07-18 15:22 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fd774bff36a7 RT-31745: fix css font lookup ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/stub/java/com/sun/javafx/css/FontTypeTest.java Changeset: 2d4ac2c93594 Author:jgiles Date: 2013-07-23 08:15 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2d4ac2c93594 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: e1d01c02a7b3 Author:jgiles Date: 2013-07-23 09:41 +1200 URL:
Re: Mixing 2D and 3D
Hi August, I will attempt some kind of answer although what we end up doing has a lot to do with where the community wants to take things, so some things we've talked about, some things we haven't, and the conversation is needed and good. Whatever the use case will be JavaFX 3D will be measured against the business needs and certainly against the capabilities of the latest releases of the native 3D APIs Direct3D (11.1) and OpenGL (4.3). This might be unfair or not helpful, but it is legitimate because they are the upper limits. So, even an object-oriented scene-graph-based 3D implementation should in principle be able to benefit from almost all native 3D features and should provide access to them. If the JavaFX architecture enables this approach then a currently minor implementation state will be rather accepted. Potential features are currently determined and limited by JavaFX' underlying native APIs Direct3D 9 and OpenGL ES 2. Correct? Java 8 doesn't support Windows XP, so in theory we can start taking advantage of DirectX 10+. At this time we are limited to OpenGL ES 2 for the sake of mobile and embedded. Also the cost of supporting multiple pipelines is significant. I think the first thing we would need to work through, before we could support DX 10, 11+, is to make it as easy as we can to write maintain multiple pipelines. So we have been looking at moving off of DX 9, but not off of ES 2 (until ES 3 is widespread). - core, e.g.: primitives (points, lines, line-strip, triangle-strip, patches, corresponding adjacency types), vertex attributes, double-precision, shaders (vertex, tessalation, geometry, fragment, compute), 3D-/cubemap-texture, multitextures, compressed texture, texture properties, multipass rendering, occlusion queries, stencil test, offscreen rendering into image, multiple active cameras, stereo? I think some of these are relatively easy things -- a line strip or triangle strip for example could be Mesh subclasses? We need to talk about how to handle shaders. I agree this is something that is required (people must have some way of supplying a custom shader). This will require work in Prism to support, but conceptually seems rather fine to me. I think different texture types could be supported by extending API in Image. The worst case would be to introduce a Texture class and setup some kind of relationship if possible between an Image and a Texture (since images are just textures, after all). The harder things are things like multi-pass rendering. Basically, features that we can add where prism is in control and picks a rendering strategy for you are relatively straightforward to think about. But giving a hook that allows the developer to pick the rendering strategy is quite a bit more complicated. I was reading up on order independent transparency algorithms and thinking how would this be exposed in API?. I haven't had any good brain-waves on that yet. I think we already do multiple active cameras? - APIs, e.g.: user input for scene navigation and model interaction (keyboard, mouse, touchpad/screen), geometry utilies, skinning, physics engine interface (kinematics), shadows Key/ mouse / touch / etc should be there already? Skinning and physics are both interesting. Skinning and boning is interesting because of different ways to go about this. Last JavaOne we did this with special shaders all in hardware. Ideally the custom shader support (that doesn't exist) mentioned above would give a way to do this. There is a balance, I think, between what we want to provide built-in and what 3rd parties such as yourself could layer above the basic support with additional libraries. For example, physics. I don't think we're going to add a physics engine of our own (probably ever), but it should be relatively easy for a framework to be built on top of JavaFX that did so. I was reading over the Unity docs for example to get a taste for how they setup their system, and was thinking that a GameObject is basically a type of Parent which has the ability to take multiple Components, including a MeshView. So a Unity-like API could be built on top of FX Nodes, including unity-like physics engine integration. The core thing for our 3D support, I think, is to expose enough of the drawing system so that additional libraries can be built on top. Obviously that will include needing a way to let developers set shaders and manipulate various state. Right now we just expose depthTest, but we don't differentiate testing from depth-writing. The more GL / D3D specific functionality we expose in API the more treacherous the waters become. I think this is the main design problem to be navigated. Will JavaOne 2013 highlight the JavaFX 3D strategy extensively? I don't expect so. We'll show 3D but you're getting the cutting edge information now :-). II. Mixing 2D and 3D - to tease apart the scene graph into Node, Node3D, and
Re: Mixing 2D and 3D
Hi, Java 8 doesn't support Windows XP, so in theory we can start taking advantage of DirectX 10+. At this time we are limited to OpenGL ES 2 for... Richard did you mean Java8 won't run on Windows XP, or that 3D features won't be supported in Windows XP? Thanks, best regards, -- Pedro Duque Vieira
Re: Mixing 2D and 3D
Java 8 (not JavaFX 8 specifically, although we're part of Java 8 so it also applies to us) is not supported on XP. It may or may not work, but we're not testing that configuration. Richard On Jul 22, 2013, at 5:41 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi, Java 8 doesn't support Windows XP, so in theory we can start taking advantage of DirectX 10+. At this time we are limited to OpenGL ES 2 for... Richard did you mean Java8 won't run on Windows XP, or that 3D features won't be supported in Windows XP? Thanks, best regards, -- Pedro Duque Vieira
