Drag and touch gestures
Hello, We tried to perform something as in iOS or Android where there is several active widgets, which can be selected by touch gestures, or dragged by drag gestures. However it seems that if we allow these two gestures on the same widget, the touch gesture takes precedence and the drag is never detected. Is there a way to allow drag AND touch gestures (for simple selections) in JavaFX ? We tried this in 2.2. Hervé
Re: How to use OpenJFX for Android?
Hello, gradle build for Android is not ready yet, but we're working on it intensively. Linux will come first this week. On 06/29/2013 03:09 PM, Tobias Bley wrote: Hi, we learned how to use OpenJFX with RoboVM... but how can we build an Android app with the new gradle based OpenJFX? best, Tobi
[API Review]: Add 'fxml.version' to System Properties (Was: FXML version number)
Hello, I propose to add 'fxml.version' property to JVM System Properties to store version of FXML specific version that is supported by FXML Loader. The property would be more specific equivalent of 'javafx.version' because these two versions won't advance simultaneously. Details about versioning and proposed namespaces are described in issue: https://javafx-jira.kenai.com/browse/RT-28599 Thanks for comments Milan Dne 7.6.2013 10:49, Milan Kubec napsal(a): Hello, I have implemented simple versioning for FXML documents in FXMLLoader, but without support in tools it won't be very useful. I have agreed with NetBeans and Scene Builder folks that they will include support for versioning too. Support means that they will produce document with two XML namespaces - one defines version of fx: prefixed elements and attributes (xmlns:fx; it's already there, just the version is appended) and the other of actual JavaFX API used to produce document (xmlns; default, no prefix). The first will be checked, because wrong version can cause failure. The latter is only informational, no strict checking of version is possible, but tools can suggest to upgrade runtime, translate document etc. JavaFX API version is stored in System Properties as javafx.version. The open question is still where and how to store fxml version in code. I think that we could have also property for this purpose, e.g. fxml.version in System Properties. So far it's part of FXMLLoader API, which is probably not very fortunate. What do you think? Issue details: https://javafx-jira.kenai.com/browse/RT-28599 Milan
Re: Native font rendering in JFX8 b96?
Hi John, I believe Phil and Kevin already answered your question. Currently I'm not using DirectWrite to render glyphs at subpixel positions (thus it still looks similar to what we had in past) but I hope to enable it in another week or two. If you happen to care for complex text (Indic, Arabic, etc), it is also better now using DirectWrite instead of ICU. Cheers Felipe On Jun 28, 2013, at 9:30 PM, Phil Race wrote: For most Windows users and use cases the main differences are that 1) Previously GDI produced the LCD glyphs, now its DW. 2) Previously T2K produced the grayscale glyphs, now its DW. T2K doesn't do layout. It just does rasterisation. Most users won't hit the layout path (for complex text). -phil. On 6/28/13 8:52 PM, Richard Bair wrote: Fonts do look good but I thought they always looked pretty good on Windows! With the old code we were using Windows to create the glyphs, so the rendering should look just as good for each glyph. T2K was doing the layout of glyphs, now it should be using DirectWrite on Windows. Not sure if it is b96 -- Felipe? Richard
Re: OpenJFX and iOS
Thanks Danno, reading the patch now. Richard On Jun 29, 2013, at 8:01 AM, Danno Ferrin danno.fer...@shemnon.com wrote: Here's a patch that copies all the file types if variants are present, so now all .a files show up in ios-sdk: https://bitbucket.org/narya/jfx78/commits/e69d574206cf59ed25e215cfd2479c9aae2ab296 From my reading, .a files are static libraries, and dylib are dynamic libraries. iOS requires static linking if I read the docs correctly. On Sat, Jun 29, 2013 at 1:17 AM, Richard Bair richard.b...@oracle.com wrote: I haven't been this low level on building iOS, so I'm not sure how this works. On iOS we don't have dynamic libraries, so why does changing the name of the dynamic libraries to be .a make a difference? Or are you really looking for the .o files? What happens to those .a's? I like the patch to push the dynamic library names into the .gradle files (except it should be dylib instead of dynlib, right?) Richard On Jun 28, 2013, at 11:14 PM, Danno Ferrin danno.fer...@shemnon.com wrote: Here's a more general solution that pushes the naming into the compile target build files (not tried on all paths, but works for iOS) https://bitbucket.org/narya/jfx78/commits/3a05c03810657d827d92d422fdadc3f2a60f9c62 On Fri, Jun 28, 2013 at 11:51 PM, Danno Ferrin danno.fer...@shemnon.com wrote: So it looks like the first step is to set the COMPILE_TARGETS to include ios. However, the script it spits out .dynlib instead of .a files, just a naming thing. Here's a fix it now patch: https://bitbucket.org/narya/jfx78/commits/1df1b31cb9618560551fb43cebe5dacb678f0c7f but a better patch would be to make a function in each platform build file. So this spits out some .a files if you know where to dig for them... gradle sdk -PCOMPILE_TARGETS=ios On Wed, Jun 26, 2013 at 10:45 AM, Richard Bair richard.b...@oracle.com wrote: At the moment the first P0 is to make sure that when we switch to gradle the rest of the development team is able to continue on with their work. It is going to be bumpy for a few days, and we might miss the weekly integration for example next week depending on how it goes. However I would encourage anybody working on iOS to supply patches as soon as you have them -- we're applying an Android patch today for instance. Richard On Jun 26, 2013, at 8:26 AM, Danno Ferrin danno.fer...@shemnon.com wrote: RoboVM + libs is the goal here, on iOS. The ant based libs worked before. My brief read of the scripts indicates to me it is mostly a question of modifying some of the guard conditions in the build, but making it work for the supported platforms first is more of a priority. On Wed, Jun 26, 2013 at 8:58 AM, Tobias Bley t...@ultramixer.com wrote: The problem is: a working gradle based iOS build isn’t of help to you because you’ll have to statically compile the JDK and OpenJFX together in one library - maybe with Avian+OpenJDK or RoboVM (android based) + OpenJFX. Am 26.06.2013 um 03:41 schrieb Daniel Zwolenski zon...@gmail.com: How do we go about building OpenJFX for iOS? Does it work now and/or will the switch over to Gradle this friday/monday include support for an iOS build? I'll want to build from Danno's JFX78 backport but as I understand it, he is hooking into the official gradle build scripts so one should hopefully lead to the other. Cheers, Dan
RE: How are Mnemonics On Buttons Supposed To Work?
Are you using OS X? For me, mnemonics in JavaFX work on Windows, but not at all in OS X (which is perhaps by undocumented design?). Apple's platform integration guide contains a section on Mnemonics, it based on Swing but I think the concepts translate to JavaFX: https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html The JMenuItem class inherits the concept of mnemonics from the JAbstractButton class. In the context of menus, mnemonics are shortcuts to menus and their contents, which are executed by using a modifier key in conjunction with a single letter. When you set a mnemonic in a menu item, Java underscores the mnemonic letter in the title of the JMenuItem or JMenu component when the Option key is held down. Using mnemonics is discouraged in OS X, because mnemonics violate the principles of OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. How then do you get the functionality of mnemonics without using Java's mnemonics? If you have defined a keystroke sequence in the setAccelerator() method for a menu item, that key sequence is automatically entered into your menus. Accelerators work on both Windows and OS X (http://stackoverflow.com/questions/12710468/using-javafx-2-2-mnemonic). -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mark Fortner Sent: Monday, July 01, 2013 10:35 AM To: openjfx-dev@openjdk.java.net Subject: How are Mnemonics On Buttons Supposed To Work? Recently, I added mnemonics to some buttons and enabled mnemonic parsing, and noticed that the mnemonic isn't rendered. I came across this issue: https://javafx-jira.kenai.com/browse/RT-18849 which seems to indicate that NOT showing mnemonics is the expected behavior. If that's correct, how are user's supposed to know what mnemonics are available? Cheers, Mark
Re: How are Mnemonics On Buttons Supposed To Work?
Hi John, Yes, I am using OS X. Thanks for the link. I ended up creating a window level key listener to listen for single key press events (don't really need a modifier). I'll have to rethink my approach. It would be nice if there was a note in the javadoc about this. Regards, Mark Cheers, Mark On Mon, Jul 1, 2013 at 1:29 PM, John Smith john_sm...@symantec.com wrote: Are you using OS X? For me, mnemonics in JavaFX work on Windows, but not at all in OS X (which is perhaps by undocumented design?). Apple's platform integration guide contains a section on Mnemonics, it based on Swing but I think the concepts translate to JavaFX: https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html The JMenuItem class inherits the concept of mnemonics from the JAbstractButton class. In the context of menus, mnemonics are shortcuts to menus and their contents, which are executed by using a modifier key in conjunction with a single letter. When you set a mnemonic in a menu item, Java underscores the mnemonic letter in the title of the JMenuItem or JMenu component when the Option key is held down. Using mnemonics is discouraged in OS X, because mnemonics violate the principles of OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. How then do you get the functionality of mnemonics without using Java's mnemonics? If you have defined a keystroke sequence in the setAccelerator() method for a menu item, that key sequence is automatically entered into your menus. Accelerators work on both Windows and OS X ( http://stackoverflow.com/questions/12710468/using-javafx-2-2-mnemonic). -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto: openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mark Fortner Sent: Monday, July 01, 2013 10:35 AM To: openjfx-dev@openjdk.java.net Subject: How are Mnemonics On Buttons Supposed To Work? Recently, I added mnemonics to some buttons and enabled mnemonic parsing, and noticed that the mnemonic isn't rendered. I came across this issue: https://javafx-jira.kenai.com/browse/RT-18849 which seems to indicate that NOT showing mnemonics is the expected behavior. If that's correct, how are user's supposed to know what mnemonics are available? Cheers, Mark
