Re: Glass Robot and getSCreenCapture
We should be consistent about what we return, although I agree that that the actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable. On Mar 21, 2014, at 7:05 PM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi David, I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing. In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen). So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff00 - both look good. However, I agree that a stricter specification and a check might be the best solution. -- best regards, Anthony On 3/21/2014 8:53 PM, David Hill wrote: I have been working on a problem with Robot.getScreenCapture() on a 565 ARM device, and while doing so, encountered a couple of questions which I will bring up: Pixxls getScreenCapture(int x, int y, int width, int height, boolean isHiDPI) I don't seem any real documentation that says how x,y + width,height should be treated when compared to the reality of the Screen. What values of x,y + width,height are reasonable ? I can picture any number of scenarios with them that would result in a box that does not fit within the Screen dimensions. The only implementing code I have seen checks to that the width height are = 1. Can I/Should I handle -x values ? What if the requested bounds exceed the screen ? If we are making assumptions that the requested box is inside the screen then why don't we document that fact and add a check in the Robot class (instead of relying on the native impls). If we are assuming the requested box does not have to lie within the screen bounds - what should the returned values be for the pixels outside the screen ? Pixel Black ? (Currently I think Lens would return 0x instead of 0xff00) My recommendation would be modify the JavaDoc contract to specify that the x,y and x+width, y+height must be within the screen bounds, with an IllegalArgumentException if out of bounds. This would be checked in Robot, prior to calling the native impls. This code is internal API, so I expect the real impact would be on SQE.
Re: Adding GStreamer plugins
I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. However, I'm not sure if I'm going about including the matroska plugin in the right way - I've currently done the following: - Downloaded the latest version of the plugins from here ( http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the matroska one to the modules/media/src/main/native/gstreamer/plugins/ folder, as well as the modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ folder (I'm unsure of this - should I add it to both these folders?). - Added all the C files from the first folder mentioned above to the plugins.vcxproj file - Added the relevant files and directory to Makefile.gstplugins - Called the additional relevant plugin_init() function in gstplugins-lite.c However, after the above I still get the same result having touched none of the native code, that being that GSTMediaPlayer throws a MediaException with flag 257, which seems to mean it couldn't create the required media from the given location. So at this point I'm a bit stuck really - of course, the whole task may be much more complicated than I'm assuming it should be. I'm not even sure if the default gradle sdk task is actually reflecting the changes I've made - certainly gstreamer-lite.dll seems to be exactly the same size as before, though I'm unsure if the additional plugin is meant to be embedded in this file or not. I'm experienced with Java but much less so with C++, and completely new to gradle (as of yesterday.) Is there anything obvious I'm not doing correctly, and if so would someone be kind enough to give me a bit of a nudge in the right direction? Many thanks, Michael
Re: Adding GStreamer plugins
Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote: I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. However, I'm not sure if I'm going about including the matroska plugin in the right way - I've currently done the following: - Downloaded the latest version of the plugins from here ( http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the matroska one to the modules/media/src/main/native/gstreamer/plugins/ folder, as well as the modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ folder (I'm unsure of this - should I add it to both these folders?). - Added all the C files from the first folder mentioned above to the plugins.vcxproj file - Added the relevant files and directory to Makefile.gstplugins - Called the additional relevant plugin_init() function in gstplugins-lite.c However, after the above I still get the same result having touched none of the native code, that being that GSTMediaPlayer throws a MediaException with flag 257, which seems to mean it couldn't create the required media from the given location. So at this point I'm a bit stuck really - of course, the whole task may be much more complicated than I'm assuming it should be. I'm not even sure if the default gradle sdk task is actually reflecting the changes I've made - certainly gstreamer-lite.dll seems to be exactly the same size as before, though I'm unsure if the additional plugin is meant to be embedded in this file or not. I'm experienced with Java but much less so with C++, and completely new to gradle (as of yesterday.) Is there anything obvious I'm not doing correctly, and if so would someone be kind enough to give me a bit of a nudge in the right direction? Many thanks, Michael -- Thanks, Michael
Re: Error in tablevie ghost error
It would be useful to get a more complete description of the issue and the error you are receiving. Also, this is probably better filed in the Jira issue tracker at http://javafx-jira.kenai.com In any case, if I were to guess the problem you're mentioning, it might be: https://javafx-jira.kenai.com/browse/RT-35338 This has been fixed in JavaFX 8u20. -- Jonathan On 24/03/2014 2:22 a.m., siput wrote: Why when i clik in the area outside row contain a data and outside column area I get an error? red area of eror
Using JavaFX deploy and having signing issues...
Hi, I am using JavaFX deploy ant task and having issue trying to sign because of jre embeded for Apple Store bundling. It is the last issue I have to fix then I can finish my Apple Store submission. Apparently even the jdk for the bundle has to be signed. To do that I had to redo permissions of jars and dylib files so the signing process would not error. My jars for my own app jars are code signed already. I am using the Apple find and codesign together so the jdk jre jars and dylib files get signed by codesign. Still I get error when submitting final pkg (with its own signing requirements) about invalid signature saying app not signed. I also discovered the JavaFX deploy lowercases my bundle id so it did not match bundle id registered with iconnect. I fixed the pinfo file so it matched. I would really like to see how this is all done with the ensemble app from the JavaFX group. Regards, -Tony
JavaFX on iOS and Android: any real world app?
After showing some demos concerning JavaFX on iOS and Android we would like to see any real world JFX app for iOS or Android. Is there anybody in the mailing list who developed a real world app? What are your experiences? What about performance? Best regards, Tobi
Re: Adding GStreamer plugins
Hi all, I'm now a bit further along with this, though struggling to get the matroska plugin to compile (getting a bunch of unresolved external symbol errors for functions it uses in glib - not entirely sure why at the moment, as I said C is not my strong point.) I've also noticed the plugins currently bundled have quite a few changes to the gstreamer version, and I can't quite work out the logic behind why things have been changed the way they have - so even after the compilation issue is resolved I'm now less confident that it will just drop in and work! Again, if someone knowledgeable in this area that's lurking in the shadows could shed any light on any of this, it would be hugely appreciated. However, putting the current problems aside for a bit, the snags I hit up until this point could I think be relatively easily addressed in the documentation. With that in mind could I suggest a few additional points for the wiki? These may be obvious to the majority reading here, but as someone completely new to building JFX they had me stumped for a while! - It turns out that the Gstreamer stuff doesn't compile at all by default, which is why I wasn't seeing any changes on the native level. To ensure GStreamer is actually compiled, you need to copy the gradle.properties.template file to gradle.properties, and uncomment the #COMPILE_MEDIA = true line. (A similar scenario would appear to exist for any webkit alterations as per the line above.) - As well as the requirements listed, I needed the Windows SDK ( http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for GStreamer to compile successfully under Windows (7) - without it cygpath just threw a rather confusing error. - The DirectX SDK failed to install for me, Googling found the fix relatively easily ( http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023), but perhaps this could be included just for reference. - The developer workflow page ( https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers to -Djavafx.ext.dirs - I think this should be -Djava.ext.dirs instead? I'm happy to make the above changes myself but unsure of if / where you can sign up for an account, so I'm just throwing them here for now - if anyone could point me to the right place then that'd be great! If I do ever manage to get this working (ha-ha) I'd also like to throw up a wiki page just detailing how to grab a gstreamer plugin and make the necessary changes to it to compile it into openjfx as a stop gap to then perhaps working on one or both of the above JIRA issues and seeing where I get - does this sound reasonable? Many thanks, Michael On 23 March 2014 15:32, Michael Berry berry...@gmail.com wrote: Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote: I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. However, I'm not sure if I'm going about including the matroska plugin in the right way - I've currently done the following: - Downloaded the latest version of the plugins from here ( http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the matroska one to the modules/media/src/main/native/gstreamer/plugins/ folder, as well as the modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ folder (I'm unsure of this - should I add it to both these folders?). - Added all the C files from the first folder mentioned above to the plugins.vcxproj file - Added the relevant files and directory
