[API Review] RT-15314
We have a request <https://javafx-jira.kenai.com/browse/RT-15314> to allow non-sandboxed applications to disable the "ESC to exit full screen" overly (and the associated ESC action to exit Full Screen). This is needed for "kiosk" style applications where Full Screen should only be under programmatic control. I have several options to present, but all of them have an underlying change, which is the addition of a system property to disable the overlay behavior: -Djavafx.fullScreenWarning=false API Option One: Add to Platform, providing for a system toggle that is static. public static void setFullScreenWarning(boolean warn) public static boolean getFullScreenWarning() Note: I considered other options, like Application, but felt they were poor fits. I am willing to listen to reason though. API Option Two: Add to Stage. This would be a per instance change, and not a global toggle: public void setFullScreenWarning(boolean warn) public boolean getFullScreenWarning() API Option Three: don't change the API at this point, rely only on the system properly to disable the overlay. Note: option three seems to be a reasonable solution for many of the users of this functionality, because in a "kiosk" style application you can control the launching anyway. -- David Hill Java Embedded Development "In the business world, the rearview mirror is always clearer than the windshield." -- Warren Buffett (1930 - )
Update on the FullScreen ESC API proposal.
Richard has proposed an API for the FullScreen/ESC/Overlay issue in
https://javafx-jira.kenai.com/browse/RT-15314
The proposal is pasted below, please consider watching/updating in the jira
with comments.
Dave
/**
* Specifies what KeyCombination will allow the user to exit full screen mode.
* A value of KeyCombination.NO_MATCH will not match any KeyEvent and will
make it so
* the user is not able to escape from Full Screen mode. A value of null means
that
* the default platform specific key combination should be used.
*/
public final void setFullScreenExitKeyCombination(KeyCombination
keyCombination);
public final KeyCombination getFullScreenExitKeyCombination();
public final ObjectProperty fullScreenExitKeyProperty();
/**
* Specifies the text to show when a user enters full screen mode, usually used
* to indicate the way a user should go about exiting out of full screen mode.
A
* value of null will result in the default per-locale message being
displayed. If set
* to the empty string, then no message will be displayed.
*/
public final void setFullScreenExitHint(String value);
public final String getFullScreenExitHint();
public final BooleanProperty fullScreenExitHintProperty();
We would also add (as the JavaDocs above indicate) a NO_MATCH public
static final KeyCombination to KeyCombination, which would be a
KeyCombination who's "match" always returns false, thereby never
matching anything. This API allows you to solve the following use cases
in, what I think, is a pretty minimally invasive manner:
* I want to customize what key is used to exit *
stage.setFullScreenExitKeyCombination(new KeyCharacterCombination("w",
KeyCombination.CONTROL_DOWN));
Note that this should also play into the default exit hint text, such that it should now say
"CTRL+W" instead of "ESC"
* I want to customize the displayed hint *
stage.setFullScreenExitHint("Don't even think about leaving this game!");
* I want to show my own exit hint *
stage.setFullScreenExitHint("");
// then in your own code construct your own message
* I want to hide the exit hint but still allow the user to exit *
stage.setFullScreenExitHint("");
* I want to disallow the user from exiting full screen *
stage.setFullScreenExitKeyCombination(KeyCombination.NO_MATCH);
* I want to restore the default exit hint *
stage.setFullScreenExitHint("Some hint");
stage.setFullScreenExitHint(null); // restore to default
Changing either property would result in a SecurityException when necessary by
an installed SecurityManager.
Note that we could also have a command line property:
-Djavafx.fullScreenExitEnabled=false which would ignore these settings
and turn off exiting in all cases. I'm not sure that it is important to
have a system property for this with proper API also being available, so
I would opt to just go with the API for now and add the system property
later if we want? Alternatively we could go with
-Djavafx.stage.fullScreenDefault=disabled or some other way to specify
that the default behavior is disabled, but if a specific stage has
provided a different default key combination / hint then we'll use that
instead. Or we could add API to Application later which would be
applicable to all Stages. But for now I would start with just the API on
Stage and see how far that takes us.
David Hill
Java Embedded Development
One of the keys to happiness is a bad memory.
-- Rita Mae Brown
Re: CFV: New OpenJFX Committer: Petr Pchelko
vote: yes On 7/9/13 Jul 9, 6:22 AM, Artem Ananiev wrote: I hereby nominate Petr Pchelko to OpenJFX Committer. Petr is a member of AWT group and an active contributor to JDK8 and OpenJFX projects. His primary areas of responsibility are AWT, Glass, and Mac OS X. Here is a list of his recent commits to OpenJFX: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=pchelko Votes are due by Jul 23, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Artem [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt. -- Mark Twain
Re: CFV: New OpenJFX Committer: Danno Ferrin
On 7/9/13 Jul 9, 6:03 PM, Richard Bair wrote: I hereby nominate Danno Ferrin to OpenJFX Committer. vote: yes Danno has been actively submitting patches and following up to make sure they get integrated for the past 8 months or so (the first patch I found was on this issue: https://javafx-jira.kenai.com/browse/RT-26719). He has maintained a BitBucket mirror since last JavaOne to make it easier for people to contribute to the project, and has submitted fixes for build issues, fxpackager, and project code (CSS, etc). Here are some of the issues he has submitted patches for (there were more but we haven't given attribution appropriately in all cases). http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=danno Votes are due by Jul 23, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Richard [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development "For every ailment under the sun There is a remedy, or there is none; If there be one, try to find it; If there be none, never mind it." -- Mother Goose
Re: CFV: New OpenJFX Committer: Debra Masada
On 7/9/13 Jul 9, 6:07 PM, Richard Bair wrote: I hereby nominate Debbie Masada to OpenJFX Committer. vote: yes Debbie is a member of the samples team and works on Ensemble and other sample applications, adding functionality etc. as necessary. Some of her recent changes can be seen here. http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=masada Votes are due by Jul 23, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Richard [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development "For every ailment under the sun There is a remedy, or there is none; If there be one, try to find it; If there be none, never mind it." -- Mother Goose
Re: CFV: New OpenJFX Committer: Alexander Kouznetsov
On 7/9/13 Jul 9, 6:09 PM, Richard Bair wrote: I hereby nominate Alexander Kouznetsov to OpenJFX Committer. vote: yes Alex is a member of the samples team, but also contributes to the core platform itself and to J1 demos. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=kouznetsov Votes are due by Jul 23, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Richard [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development "A specification that will not fit on one page of 8.5x11 inch paper cannot be understood." -- Mark Ardis
Re: CFV: New OpenJFX Committer: Oleg Mazurov
On 7/9/13 Jul 9, 6:17 PM, Richard Bair wrote: I hereby nominate Oleg Mazurov to OpenJFX Committer. vote: yest Oleg has been a key behind-the-scenes contributor to JavaFX performance. Some of his contributions can be counted in code http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=mazurov But much more in terms of performance profiling and analysis. As we move more performance code to the open source, his contributions will be more evident to the community. Votes are due by Jul 23, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Richard [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development "A specification that will not fit on one page of 8.5x11 inch paper cannot be understood." -- Mark Ardis
Re: JDK 8 for ARM Early Access Releases (with JavaFX)
On 7/10/13 Jul 10, 10:22 AM, Gerrit Grunwald wrote: I just saw some problems with complex -fx-shape based paths. Hi Gerrit, If you have a test case you can share, I would appreciate a Jira filed :-) Simple test cases make me a happy person. Please add in the description that it is a PI issue so if gets routed to us embedded guys. We have been working through the known issues for the ARM hard float on the PI, and have been getting better over time. And of course our efforts to improve performance on the PI have lead to overall JFX improvements. So feedback, both good and bad is appreciated. -- David Hill Java Embedded Development "Be obscure clearly." -- E. B. White
Re: JDK 8 for ARM Early Access Releases (with JavaFX)
On 7/10/13 Jul 10, 2:28 PM, Tom Schindl wrote: Hi David & Daniel, Is there a version which works on a beagleboard (or beagleboard like hardware) as well? IIRC hard float does not work there. We don't have plans to make soft float builds of JDK 8 available on java.net. However we do plan to provide instructions on how to build OpenJFX for ARM for the BeagleBoard, PI and other platforms. We need to document the OS and SDK setup needed for the beagle which is significantly more complicated than it is for the PI, and you will need to wait just a bit longer before a work in progress change to support fonts properly in OpenJFX is in place. We hope to finish documenting how to perform an OpenJFX PI build really soon now, as it is really, really close. We will announce when it is ready. -- David Hill Java Embedded Development "Nobody will ever win the Battle of the Sexes. There's just too much fraternizing with the enemy.' -- Henry Kissinger (1923 - )
Building your own OpenJFX for Linux ARM/Raspberry PI
You should now be able to build OpenJFX for Linux Arm (hard float abi) for the Raspberry PI. To do this you will need the current Linux ARM JDK from java.net, and a Linux desktop machine. The basic setup for building with Linux is here https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX and PI build (Cross building for ARM hard float) are described here: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-CrossbuildingforARMhardfloat Details on running on the PI are here: https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi Daniel has validated a working result :-) We look forward to working with the community to improve and simplify the process. Next steps (coming soon we hope): * Fully open native font support (currently you need a "closed" shared library) * Build instructions for Linux ARM soft float ABI (like the the Beagle XM) * a more streamlined porting interface to enable adding other platforms -- David Hill Java Embedded Development "Paradise is exactly like where you are right now... only much, much better." -- Laurie Anderson, Language Is A Virus
Re: Building your own OpenJFX for Linux ARM/Raspberry PI
On 7/10/13 Jul 10, 5:02 PM, Richard Bair wrote: Hi David, maybe you should cross post this over on the raspberry PI forums? Daniel posted this there: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=81&t=49497 Dave On Jul 10, 2013, at 1:46 PM, David Hill wrote: You should now be able to build OpenJFX for Linux Arm (hard float abi) for the Raspberry PI. To do this you will need the current Linux ARM JDK from java.net, and a Linux desktop machine. The basic setup for building with Linux is here https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX and PI build (Cross building for ARM hard float) are described here: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-CrossbuildingforARMhardfloat Details on running on the PI are here: https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi Daniel has validated a working result :-) We look forward to working with the community to improve and simplify the process. Next steps (coming soon we hope): * Fully open native font support (currently you need a "closed" shared library) * Build instructions for Linux ARM soft float ABI (like the the Beagle XM) * a more streamlined porting interface to enable adding other platforms -- David Hill Java Embedded Development "Paradise is exactly like where you are right now... only much, much better." -- Laurie Anderson, Language Is A Virus -- David Hill Java Embedded Development "Unix is user-friendly. It's just very selective about who its friends are."
Re: A different way to handle pulse timing
On 7/26/13 Jul 26, 1:22 AM, Richard Bair wrote: As for multiple scenes, I'm actually curious how this happens today. If I have 2 scenes, and we have just a single render thread servicing both, then when I go to present, it blocks? Or is there a non-blocking present method that we use instead? Because if we block, then having 2 scenes would cut you down to 30fps maximum, wouldn't it? If we are non-blocking today (is that possible?) then the only way this proposed solution would work is if there was a different render thread per stage (which actually is something I think we ought to be doing anyway?). Currently we block/lock rendering using AbstractPainter.renderLock so you can take a 'uses' to see where it is used. In general though, we use PaintCollector to stage render jobs in a pulse - one per dirty Scene. This operation is on the user event thread, and is blocked by any pending render tasks (in effect it waits for a current pulse to complete). The PaintCollector uses window state", similar to a shadow scene graph, so that the render operation is using state that is consistent (this is done using SceneState) Each render task (scene) is executed separately on the render thread, and takes the renderLock while it is doing its thing. This means that there is an unlocked state between queued rendered scene tasks. Rendering tends to be done via either PresentingPainter (accelerated) or UploadingPainter (sw). The above is the simplified view - and shows that user event thread can be happily running along doing stuff while the render thread is doing its thing - at least until it is blocked by needed to push another render pulse. But... it is a touch more complicated than that, as we found that there are a number of user event thread operations that really can't be happening when we have a render operation going. These are mostly related to "window operations", like resizing or closing a window. Changing a windows state while rendering to it causes "unpredictable" results on many platforms. Because of this, there are a number of operations where we take the renderLock before calling from Quantum into glass. A sampling of these cases are WindowStage setScene, setVisible, close. The idea is that Glass should be treated as single threaded. Note that embedded arm behaves a touch different - because we have a single GL graphics context and no "real" windows - we always paint every stage/scene from back to front. In effect, we are the compositor of the screen as we are the "window manage". This is pretty obvious in the PaintCollector class. Given that we have a single graphics context - there is no way we would want one render thread per scene there. Another note - the addition of SceneState solved a problem, one that was easily seen with HelloWindowAbuse, which created/resized/closed windows at a frantic pace. There was some discussion at the time that we might have been able to save less state in SceneState because we already have that data in other places, like the SceneGraph. SceneState was a compromise solution that provided the quickest fix for the least amount of code reconstruction, which of course means that there is likely room for improvement. So, that is my view of the elephant <https://en.wikipedia.org/wiki/Blind_men_and_an_elephant>, and I am sure that others will have a different take :-) -- David Hill Java Embedded Development Education: that which reveals to the wise, and conceals from the stupid, the vast limits of their knowledge. -- Mark Twain
Re: A different way to handle pulse timing
On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote: as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. I think the difference is that I was going to use the vsync as the limiter. That is, the first time through we do a pulse, then we schedule another pulse, then we run that other pulse (almost immediately), then we hit the sync point with the render thread and have to wait for it because it is blocked on vsync. Meanwhile the user events are being queued up. When we get back from this, the next pulse is placed on the end of the queue, we process all input events, then the next pulse. You are assuming several things here - most of which would not be present on something like the PI. * access to vsync * a fast enough rendering that you can usually fit into a vsync period. I would be seriously concerned over user event starvation. It would not take much of a busy set of animations to mean we spin painting a SG that has not completely caught up with the bindings/and or ignoring the incoming input events. -- David Hill Java Embedded Development A committee is a cul-de-sac down which ideas are lured and then quietly strangled. -- Sir Barnett Cocks (1907 - 1989)
Re: A different way to handle pulse timing
On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote: The idea of user event starvation has been mentioned before and has me a little confused… Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? There is a "simple" user input queue - the problem is that we dispatch those arriving events on the user event *thread*, and that thread is used for a lot of thing other than user input. It is not so much the cost of handling the input, but rather the cost of handling the actions after input. As an example, on a mouse click, a control may change - which might cause a re-layout, which should cause repainting to happen. Currently, JFX uses a separate "rendering thread" for painting. This is goodness, especially when you have a GPU. On the user event thread we need to queue up and then stage the repaint request. Things are more complicated because many (but not all) painting/window management tasks need to be single threaded. In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). Those of us who have been through several iterations of this are suggesting caution on a rework though :-) BTW - it is very easy to write a "bad" app which will demonstrate the problem. As a thought example - if on a button click, you calculate PI to the nth digit before updating your text field - and you do it in the event callback - you are stalling the user event thread. Add in enough computes and you get an very unresponsive app. Instead of computes, you can just call sleep to see the problem too :-) Dave In terms of rendering fast enough that you can fit things into a vsync period.. that shouldn't be necessary. If you miss one sync period then you should be finished by the next.. having a strict requirement to fit within a single vsync period is impractical. Without access to true sync, a timer would serve the same purpose. Having both a timer and sync is where things get silly. Cheers, Scott On 2013-08-05, at 9:47 AM, David Hill wrote: On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote: as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. I think the difference is that I was going to use the vsync as the limiter. That is, the first time through we do a pulse, then we schedule another pulse, then we run that other pulse (almost immediately), then we hit the sync point with the render thread and have to wait for it because it is blocked on vsync. Meanwhile the user events are being queued up. When we get back from this, the next pulse is placed on the end of the queue, we process all input events, then the next pulse. You are assuming several things here - most of which would not be present on something like the PI. * access to vsync * a fast enough rendering that you can usually fit into a vsync period. I would be seriously concerned over user event starvation. It would not take much of a busy set of animations to mean we spin painting a SG that has not completely caught up with the bindings/and or ignoring the incoming input events. -- David Hill Java Embedded Development A committee is a cul-de-sac down which ideas are lured and then quietly strangled. -- Sir Barnett Cocks (1907 - 1989) -- David Hill Java Embedded Development The radical of one century is the conservative of the next. The radical invents the views. When he has worn them out the conservative adopts them. -- Mark Twain
Re: A different way to handle pulse timing
On 8/5/13 Aug 5, 1:09 PM, Richard Bair wrote: In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). Right, but I don't see how that could still happen in this proposal? The problem before was the pulse events were handled outside of the event queue (as I recall) so that they got higher priority. We got rid of the higher priority and starvation ceased. This proposal would not reintroduce priorities, so I don't see how you could end up with input event starvation again? rendering is "staged" on the event queue (layout, adding the render job to the render thread). It has been this way for quite a while now. As far as I remember,( other than paths with "live resize"), we have never had a mechanism that provided for event priority (at least not on the Linux side where I tend to live). BTW - it is very easy to write a "bad" app which will demonstrate the problem. As a thought example - if on a button click, you calculate PI to the nth digit before updating your text field - and you do it in the event callback - you are stalling the user event thread. Add in enough computes and you get an very unresponsive app. Instead of computes, you can just call sleep to see the problem too :-) But this is the case today as well. Indeed - and something we document as a "do not do that because it hurts" item. I used this to illustrate the problem. Just like the app writer, we need to make sure we use the user event queue in ways that allows us to handle events in a timely fashion. In some cases - that means we do a lot of work to put computes on a different thread (ie rendering). Richard -- David Hill Java Embedded Development Ich weiß nicht. -- an unknown German philosopher
Re: A different way to handle pulse timing
On 8/5/13 Aug 5, 1:40 PM, Scott Palmer wrote: On 2013-08-05, at 12:49 PM, David Hill wrote: On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote: The idea of user event starvation has been mentioned before and has me a little confused… Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? There is a "simple" user input queue - the problem is that we dispatch those arriving events on the user event *thread*, and that thread is used for a lot of thing other than user input. It is not so much the cost of handling the input, but rather the cost of handling the actions after input. Right, I guess I don't have a complete picture of the threading model. I think that there is a relatively small number of people that do - and I count myself as someone that has a good, but partial, understanding of it. I assume that user events like mouse clicks and key presses are coming in from some OS thread and queued on the "user event thread". Meanwhile things like runLater() are also queued on the user event thread. If other user events from the OS happened they would naturally be interleaved with runLater type operations - everything eventually gets processed no matter how busy the system is, no matter what you do on the user event thread so long as eventually the operation completes. The cost of handling the input, would either complete and then the next event is processed or they might trigger additional work via runLater. The runLater stuff would be queued behind any other OS events that have already been queued by the OS input thread, they wouldn't "jump the queue". I suspect I am oversimplifying. If there is somewhere to go to get a idea of the actual threading model please point me in the right direction. As part of our "porting guide" which will just be part of the openjfx wiki - this is something that I want to write up, at least in overview. Not there yet though. I suspect that some of the details will be changing over the next while anyway. The repo refactoring now allows us to clean up some of the rather convoluted means of communicating from the API through quantum to Prism and Glass. Dave -- David Hill Java Embedded Development "The conventional view serves to protect us from the painful job of thinking." -- John Kenneth Galbraith (1908 - 2006)
CFV: New OpenJFX Committer:Daniel Blaukopf
I hereby nominate Daniel Blaukopf to OpenJFX Committer. Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the "embedded device" space. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, David [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
CFV: New OpenJFX Committer: Seeon Birger
I hereby nominate Seeon Birger to OpenJFX Committer. Seeon is a member of the Embedded Device team, which means he works across various aspects of the platform, but in particular, Lens and Virtual Keyboard. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=seeon.birger Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Dave [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
Re: A different way to handle pulse timing
On 8/6/13 Aug 6, 10:07 AM, Scott Palmer wrote: On 2013-08-06, at 9:10 AM, Artem Ananiev wrote: On 8/5/2013 10:26 PM, Richard Bair wrote: In this proposal, we also would be putting the next pulse on the end of the queue, so it is impossible to starve input events. Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have "paint starvation" instead of "input events starvation". If the OS message queue is fundamentally broken (i.e. it does not behave like a queue), can all this be done on a proper queue that you have control over? I.e. in the OS-specific message loop, just move the messages to a more reasonably behaved queue. Posting a request to process a pulse would simply queue the operation on the well behaved queue and not use the OS PostMessage or SendMessage mechanism at all. I admit to not knowing enough about Windows message processing to know if that even makes sense. (Windows seriously doesn't have a mechanism to put something on the tail end of the message queue? Wow, don't they understand how a "queue" is supposed to work?) This is what Glass/Lens does - the user event thread is all in Java. But then - we also don't have to deal with any pesky native window managers :-) Lens input events are taken from as close as we have to a native event loop (on an input thread) and posted to the java based user event thread, just like any other Application.InvokeLater (first in, first out queue). This also saves Lens a bit of JNI handling as most user (non input events) never leave java this way. Dave Scott -- David Hill Java Embedded Development "Sometimes the questions are complicated and the answers are simple." -- Dr. Seuss (1904 - 1991)
Re: CFV: New OpenJFX Committer: Chien Yang
On 8/15/13 Aug 15, 11:50 AM, Artem Ananiev wrote: Vote: YES I hereby nominate Chien Yang to OpenJFX Committer. Chien is a member of JavaFX graphics group at Oracle. Here is the list of his fixes and reviews: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=chien Votes are due by Aug 29, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Artem [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development "Perl - The only language that looks the same before and after RSA encryption." -- Keith Bostic
Re: CFV: New OpenJFX Committer: Mick Fleming
On 8/15/13 Aug 15, 2:11 PM, Artem Ananiev wrote: vote: yes. I hereby nominate Mick Fleming (OpenJDK user name: mickf) to OpenJFX Commmitter. Mick is a member of JavaFX Controls team at Oracle. He fixed many bugs and implemented tons of features in virtually every JavaFX Control, from buttons to tables. Here is a short list of his commits: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=mickf As I wrote in another email, full list of changesets can be found from command line: hg log -u mickf It shows far more than 32 entries, which would be enough for nomination to Reviewer, if we had this role OpenJFX. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Artem [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus -- David Hill Java Embedded Development "Play: Work that you enjoy doing for nothing." -- Evan Esar (1899 - 1995), Esar's Comic Dictionary
Result: New OpenJFX Committer: Seeon Birger
Voting for Seeon Birger to OpenJFX Committer [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008677.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
Result: New OpenJFX Committer: Daniel Blaukopf
Voting for Daniel Blaukopf to OpenJFX Committer [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008677.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
Porting BOF at JavaOne
I would like to highlight an upcoming JavaOne BOF that might be of interest to this mailing list. Session ID: BOF4424 Session Title: Porting OpenJFX to New Devices Venue / Room: Hilton - Plaza B Date and Time: 9/23/13, 18:30 - 19:15 I will be acting as moderator, and there will be a number of luminaries from the JFX team present. I am planning on bringing some slides that generally talk about low level porting (primarily to Linux like platforms). Like any good BOF, I hope people will bring questions about their favorite platform. Hope to see you there, Dave -- David Hill Java Embedded Development Mistakes are a part of being human. Appreciate your mistakes for what they are: precious life lessons that can only be learned the hard way. Unless it's a fatal mistake, which, at least, others can learn from. -- Al Franken
RE: CFV: New OpenJFX Committer: Joseph Andresen
Vote: yes -Original Message- From: Artem Ananiev [artem.anan...@oracle.com] Received: Wednesday, 25 Sep 2013, 8:37am To: OpenJFX [openjfx-dev@openjdk.java.net] Subject: CFV: New OpenJFX Committer: Joseph Andresen I hereby nominate Joe Andresen to OpenJFX Committer. Joe is a member of JavaFX Graphics team at Oracle. His first changeset in Prism is dated by 2009, and total number of commits is close to one hundred. Full list of Joe's changesets in the open workspace is available from command line: hg log -u "Joseph Andresen" Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
RE: CFV: New OpenJFX Committer: Lisa Selle
Vote: yes -Original Message- From: Artem Ananiev [artem.anan...@oracle.com] Received: Wednesday, 25 Sep 2013, 8:36am To: OpenJFX [openjfx-dev@openjdk.java.net] CC: Lisa Selle [lisa.se...@oracle.com] Subject: Re: CFV: New OpenJFX Committer: Lisa Selle Re-sending with the right subject (was: OpenJDK, now: OpenJFX). Sorry for the typo. Thanks, Artem On 9/25/2013 7:30 PM, Artem Ananiev wrote: > > I hereby nominate Lisa Selle to OpenJFX Committer. > > Lisa is a member of JavaFX Embedded team. Her changes are all over the > JavaFX code, from cursors and input events to makefiles and virtual > keyboard. The list of Lisa's commits in the workspace: > >hg log -u "Lisa Selle" >hg log -u "Lisa.Selle" > > Incomplete list is also available by the following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle > > Votes are due to Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project > Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem
CFV: New OpenJFX Committer: Assaf Yavani
I hereby nominate Assaf Yavnai to OpenJFX Committer. Assaf is a member of JavaFX Embedded team at Oracle. Most of Assaf's changes are in Glass/Lens support code: hg log -u "Assaf Yavani" An incomplete list of Assaf's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=assaf Votes are due by Nov 13, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
CFV: New OpenJFX Committer: Assaf Yavani
I hereby nominate Rafi Tayar to OpenJFX Committer. Rafi is a member of JavaFX Embedded team at Oracle. Rafi's changes are in Glass/Lens support code: hg log -M -u "Rafi Tayar" An incomplete list of Rafi's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=tayar Votes are due by Nov 19, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
Fwd: CFV: New OpenJFX Committer: Rafi Tayar
[ resending it with a corrected subject line. The dangers of reusing a form] I hereby nominate Rafi Tayar to OpenJFX Committer. Rafi is a member of JavaFX Embedded team at Oracle. Rafi's changes are in Glass/Lens support code: hg log -M -u "Rafi Tayar" An incomplete list of Rafi's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=tayar Votes are due by Nov 19, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
review - import change in FXMLLoader
webrev: http://cr.openjdk.java.net/~ddhill/RT-33392/ jira: https://javafx-jira.kenai.com/browse/RT-33392 While examining the output from jdeps, I noticed an oddity regarding a missing dependency javafx.fxml.ParseTraceElement which was in error anyway, as the ParseTraceElement should be from: com.sun.javafx.fxml.ParseTraceElement and the wildcard import should/does get the right one (after all we compile...) The above webrev corrects this oddity, while correcting FXMLLoader so that it conforms to our coding standards by not using package wildcard imports. -- David Hill Java Embedded Development "Computers make very fast, very accurate mistakes."
Result: New OpenJFX Committer: Assaf Yavani
Voting for Assaf Yavani to OpenJFX Committer [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008677.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
Result: New OpenJFX Committer: Rafi Tayar
Voting for Rafi Tayar to OpenJFX Committer [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008677.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
Changing the default gradle build results.
Come join the discussion - we don't have much time to do this :-) https://javafx-jira.kenai.com/browse/RT-34633 The Jira starts with this: The OpenJFX default target for gradle (currently 'sdk') should also build the public apps Currently we have: sdk: builds only the SDK runtime binary - not apps apps: builds open and closed apps, and copies selected items to the artifacts tree all: used for all release engineering builds, includes sdk, apps There seems to be a desire to have some additional targets/behaviors Steve would like the default build (gradle with no arguments) to include the building of the SDK and the public samples. Dave and Kevin would like to make sure that anything added does not limit the ability to build only sdk runtime, and limits the extra time building other "stuff". Kevin report the closed side of the apps build takes an additional 3 minutes. There seems a number of ways to solve this issue - adding additional targets, while retaining the overall end result. The challenge seems to be defining what those intermediate targets should be, and what should be the definition of 'sdk' and what is the default gradle target. -- David Hill Java Embedded Development "Do not throw the arrow which will return against you." -- Kurdish Proverb
please review RT-31668
https://javafx-jira.kenai.com/browse/RT-31668 Kevin, Alexander, please review: http://cr.openjdk.java.net/~ddhill/RT-31668/ <http://cr.openjdk.java.net/%7Eddhill/RT-31668/> -- David Hill Java Embedded Development Education: that which reveals to the wise, and conceals from the stupid, the vast limits of their knowledge. -- Mark Twain
webrev for moving a few toys to public toys
These are some of the closed toys I use constantly, so am migrating them to public toys: http://cr.openjdk.java.net/~ddhill/RT-34081 jira: RT-34081 <https://javafx-jira.kenai.com/browse/RT-34081> Included: HelloSanity, HelloWindowManager, HelloWindowAbuse Also included is a fix to the nb source path, and a few javadoc fixes. -- David Hill Java Embedded Development "Any fool can make a rule, and any fool will mind it." -- Henry David Thoreau (1817 - 1862)
Fwd: CFV: New OpenJFX Committer: Vadim Pakhnushev
I hereby nominate Vadim Pakhnushev to OpenJFX Committer. Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are in Glass Windows/D3d: hg log -M -u "vadim" An incomplete list of Vadim's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim Votes are due by Dec 25, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
Additions to apps/toys
As part of RT-34081, I just moved about 50 Hello 'toys' to open source. You can find then under rt/apps/toys/Hello These are toys in the sense that they are not official samples. These are usually vehicles to experiment with various features, or are used as part of quick feature tests. In particular - try HelloSanity. Have fun with them :-) -- David Hill Java Embedded Development "For every complex problem there is a simple solution, and it's wrong." -- H. L. Mencken
Result: New OpenJFX Committer: Vadim Pakhnushev
Voting for Vadim Pakhnushev to OpenJFX Committer [1] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008677.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
Re: JavaFX on headless Jenkins
On 1/4/14, Jan 4, 3:57 PM, Tom Eugelink wrote: I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a "no suitable pipeline found". Any suggestions how to fix that? This has long been a challenge with FX. I even modified Glass/Lens to get a headless with a VNC option working on Linux & Mac (Windows probably needed a little porting). This has never been a priority though, only a casual hobby. Daniel is working on a refresh of Glass/Lens that may make it even easier to do headless (as a side effect). If there is any interest, I can provide more information on the current Glass/Lens headless. Dave :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest > enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread "Thread-4" java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) -- David Hill Java Embedded Development "On a clear disk, you can seek forever."
Re: JavaFX on headless Jenkins
On 1/6/14, Jan 6, 3:13 PM, Tom Eugelink wrote: Yes please, I've got Jenkins setup so it starts a vncserver and it runs on linux, so I'm interesting in the option you mention (as long as it doesn't require too many hoops I need to jump through). This will take me a day of so. It would appear that I have not touched this since the gradle switchout :-( Dave Tom On 2014-1-6 17:36, David Hill wrote: On 1/4/14, Jan 4, 3:57 PM, Tom Eugelink wrote: I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a "no suitable pipeline found". Any suggestions how to fix that? This has long been a challenge with FX. I even modified Glass/Lens to get a headless with a VNC option working on Linux & Mac (Windows probably needed a little porting). This has never been a priority though, only a casual hobby. Daniel is working on a refresh of Glass/Lens that may make it even easier to do headless (as a side effect). If there is any interest, I can provide more information on the current Glass/Lens headless. Dave :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest > enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread "Thread-4" java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) -- David Hill Java Embedded Development "Basic research is what I am doing when I don't know what I am doing." -- Wernher von Braun (1912 - 1977)
Failure to find any font (probably on Embedded)
I am chasing a edge case that probably only happens in certain Embedded
configurations. If we don't find *any* fonts, then we quietly fail and blame it
on CSS :-)
I say blame it on CSS because the resulting hard failure is:
Exception in thread "JavaFX Application Thread" java.lang.NoClassDefFoundError:
Could not initialize class javafx.scene.CssStyleHelper
This is because CSS needs a font for various calculations.
With Embedded, if libfontconfig is not present (or improperly configured) you
will not find any fonts.
I would like thoughts on my putting a more informative error message out, and
making zero fonts an earlier hard failure.
What I would really like to do is to be able to put a URL to a Fonts wiki page
(like: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but not sure
how well that would stand up to the test of time.
The code point in FontConfigManager is:
if (anyFont == null) {
if (debugFonts) {
System.err.println("Fontconfig returned no fonts at all.");
}
fontConfigFailed = true;
return;
--
David Hill
Java Embedded Development
"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams
Heads up... changing the rt/build/*sdk/ directory
As part of this Jira <https://javafx-jira.kenai.com/browse/RT-35809>, we are
trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able to provide a
common path to "host build" jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with, explained
here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A developer may
// have multiple SDK's on their system at any one time, depending on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
--
David Hill
Java Embedded Development
"On a clear disk, you can seek forever."
Re: Heads up... changing the rt/build/*sdk/ directory
On 2/15/14, Feb 15, 7:55 PM, Stefan Fuchs wrote:
Hi,
hm, is there now a way to crossbuild the apps like Ensemble8?
Seems to me that the apps are now always build against the default sdk.
I ask this, because for the dalvik port, we currently use a stripped down
version of the sdk, which only contains the classes, we got working.
Stefan,
When performing 'gradle apps', we pass several properties into the the ant
based apps/build.xml.
(Actually gradle sucks in the apps/build.xml tree and runs internally, but that
is an implementation detail).
def appsJar = project.task("appsJar${t.capital}") {
doLast() {
ant.properties['targetBld'] = "$t.name"
if (!rootProject.ext[t.upper].compileSwing) {
ant.properties['JFX_CORE_ONLY'] = 'true'
}
ant.properties['jfxbuild.jfxrt.jar'] = jfxrtJar
ant.properties['platforms.JDK_1.8.home'] =
"${rootProject.ext.JDK_HOME}"
ant.project.executeTarget("sampleAppsJar")
}
}
in this case jfxrtJar now evaluates on a 'host' build to:
build/sdk/rt/lib/ext/jfxrt.jar
and on a cross build to:
build/${t.name}-sdk/rt/lib/ext/jfxrt.jar
Note in the above the conditional setting of JFX_CORE_ONLY. This is because we are
currently not building Swing & SWT classes in the ARM cross builds, and we use
the JFX_CORE_ONLY property to avoid trying to build some of the examples.
Our nightly build does quite a bit (but not all) of the apps tree for both
'host' and cross.
I am looking forward to hooking up most of the rest. I think there are a couple
that we will not ever build nightly (I think Kevin said Scenebuilder was one).
Dave
- Stefan
David Hill wrote:
As part of this Jira <https://javafx-jira.kenai.com/browse/RT-35809>, we are
trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able to provide a
common path to "host build" jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with, explained
here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A developer may
// have multiple SDK's on their system at any one time, depending on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
--
David Hill
Java Embedded Development
"The most likely way for the world to be destroyed, most experts agree, is by
accident. That's where we come in; we're computer professionals. We cause accidents."
-- Nathaniel Borenstein (1957 - )
Review for RT-35535 - better provide for embedded font fallback
Hi all, I have a review request for Jira: https://javafx-jira.kenai.com/browse/RT-35535 Webrev: http://cr.openjdk.java.net/~ddhill/RT-35535/ This change is to support certain embedded cases where Linux does not have FontConfig installed (usually to save overhead). For this case we support specifying a font directory and a means of listing the fonts there (logicalfonts.properties) (Thanks Phil!). Our JDK usually has the Lucida fonts installed at ./jre/lib/fonts. The set of changes: a) provides an option to ignore fontconfig -Dprism.useFontConfig=false for testing purposes b) corrects where we look for lib/fonts relative to jfxrt.jar (we are in lib/ext now) c) when lib/fonts is found and logicalfonts.properties is not, guess at one. d) when zero fonts are found, mention it so we have a clue why CSS failed. Other existing properties of interest: -Dprism.fontsdir=/opt/fonts -Dprism.debugfonts=true And my documenting fonts (at least on Linux) page on the Wiki: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup -- David Hill Java Embedded Development "Basic research is what I am doing when I don't know what I am doing." -- Wernher von Braun (1912 - 1977)
Embedded ARM interest "poll"
I know that there is a fair amount of interest in IOS and Android. What I don't know is what other "Embedded" ARM platforms people are interested in running OpenJFX on. "Embedded" in this case can be translated as "other than iOS or Android". As many of you know, we have documented "known to work" for the Raspberry PI <https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi>. Recently we have had success with the Freescale i.MX6. The i.MX6 is a startling fast platform compared to the PI, particularly the quad core I am using. A lot of the operations seem to be 3-5x faster than the PI. For the power, the prices are pretty reasonable to me. See http://www.wandboard.org/ and http://boundarydevices.com/ for just two of the vendors I know about that have development boards. I have started documenting the setup on the OpenJFX Wiki <https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+Freescale+i.MX6>, though this effort is complicated by the community Yocto build which does not have a working "framebuffer" image. I am using a "workaround" for this build problem. For those not in the know, Freescale provides different versions of libEGL for different rendering targets (x11, framebuffer, ...) I certainly would enjoy it if others in the OpenJFX community wanted to help out with i.MX6! The TI "Beagle xM" probably works, but I have not found a Linux hard float distro with sufficiently integrated graphics drivers to try it on. I have a pending request to support the A20-OLinuXino, and actually have one so I might be able to start work soon. If "Embedded" ARM is interesting to you, could you reply OFF LIST - just to me with the platforms you are interested in or are currently using ? -- David Hill Java Embedded Development "Discontent is the first necessity of progress." -- Thomas A. Edison
Re: review request for RT-35353
On 2/26/14, Feb 26, 3:02 PM, Lisa Selle wrote:
Hi Daniel and David,
Please review the following fix for
https://javafx-jira.kenai.com/browse/RT-35353 - Add a dispman back end to
Monocle glass:
http://cr.openjdk.java.net/~kselle/webrev-20140226-1458-RT-35246/webrev/
Thanks,
Lisa
51 bcmLibraryHandle = ls.dlopen("libbcm_host.so",
LinuxSystem.RTLD_LAZY);
check for null ?
other than that, did not see anything. +1
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
Review for font fallback change RT-35978
jira: https://javafx-jira.kenai.com/browse/RT-35978 webrev: http://cr.openjdk.java.net/~ddhill/RT-35978 The change is for Embedded Arm font fallback, simplifying the determination of where the jre/lib/fonts will be found. I switched to using the java.home property as it provides the desired information with greater simplicity and accuracy than the previous mechanism. I also would appreciate an associated Wiki rework for this topic: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup -- David Hill Java Embedded Development "If you want to catch something, running after it isn't always the best way." -- Lois McMaster Bujold, "Borders of Infinity", 1989
Moved samples 3DViewer and Modena from experiments to samples
A heads up. I just moved samples 3DViewer and Modena from experiments to samples. If you are going to work on these samples, you may want to sync up soon to avoid later fun. Dave -- David Hill Java Embedded Development "We trained hard, but it seemed that every time we were beginning to form up into teams, we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization." -- Unknown (misattributed to Petronius Arbiter, 210AD).
Re: [8u20] review request: https://javafx-jira.kenai.com/browse/RT-36163
On 3/11/14, Mar 11, 6:21 PM, Kevin Rushforth wrote: David, Please review the (simple) build fix for: JIRA: https://javafx-jira.kenai.com/browse/RT-36163 Webrev: http://cr.openjdk.java.net/~kcr/RT-36163/ -- Kevin +1 -- David Hill Java Embedded Development Education: that which reveals to the wise, and conceals from the stupid, the vast limits of their knowledge. -- Mark Twain
review: enable debugging info in linux shared libs
Hi Kevin, There is a simple diff in the bug. https://bugs.openjdk.java.net/browse/JDK-8150673 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review for enabling systemTest with Jake
Kevin, (finally) https://bugs.openjdk.java.net/browse/JDK-8147399 http://cr.openjdk.java.net/~ddhill/8147399/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review for paper test
Phil, could you review: JobSettingsTest.testPaper fails with small paper sizes Simple fix, make the margins that don't fit 10% of the page dimension https://bugs.openjdk.java.net/browse/JDK-8149756 http://cr.openjdk.java.net/~ddhill/8149756/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
jake: enabling systemTests
Kevin, if you could review: Enable systemTests in jake https://bugs.openjdk.java.net/browse/JDK-8147399 http://cr.openjdk.java.net/~ddhill/8147399.2/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Documenting our Junit tests
I just added a new page on the OpenJFX wiki. It covers JUnit tests within the OpenJFX build, but in particular covers them in a JDK 9 modular world (Jigsaw). I know that modules does not apply to many people - yet. I wrote this up after I was asked by an engineer about how to rework some existing tests, and quickly realize how much detail I had locked up in my brain. So to set that knowledge free, I put it in a wiki :-) Please let me know if you have any comments, questions, corrections. https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: Move & Copy DnD operation on OS-X and Linux
On 3/29/16, 7:04 AM, Tom Schindl wrote:
Hi,
Tom,
This is something we might be able to change in 9.
Would you file a bug for this ?
thanks,
Dave
While developing our editor control we tried to implement DnD of
Text-Selection to:
* to rearrange text inside the control
* to copy text selections to another position inside the text
On Win32 everything works as expected, if you start dragging the initial
operation is MOVE and you can change that to a COPY by pressing CTRL
while dragging.
On Linux the initial gesture is COPY which is not how DnD works in
things like nautilus, ... . I can get that to change to a move operation
by holding the SHIFT key.
On OS-X the initial gesture is a COPY and which is not how DnD works
finder or eg Finder, and I haven't found a way to change the operation
to a MOVE.
I would expect the following on ALL operation systems:
- a drag WITHOUT any modifier key is a MOVE operation
- on Windows& Linux I make it to a copy operation by pressing CTRL
while dragging
- on OS-X I make it a copy operation by pressing ALT while dragging
In general I think the problem is even bigger because the default
operation depends on the target eg on windows when you drag a file
between 2 folders on the same filesystem you get a default MOVE but if
you drag to another one the default is a COPY and SHIFT makes it a MOVE.
JavaFX does all that right but what it gets wrong is the default
operation. Any thoughts on this? Did we miss something obvious?
The simple application below is how to reproduce.
package application;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.input.ClipboardContent;
import javafx.scene.input.DataFormat;
import javafx.scene.input.DragEvent;
import javafx.scene.input.Dragboard;
import javafx.scene.input.MouseEvent;
import javafx.scene.input.TransferMode;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;
public class Main extends Application {
private BorderPane root;
@Override
public void start(Stage primaryStage) {
try {
root = new BorderPane();
Scene scene = new Scene(root,400,400);
scene.getStylesheets().add(getClass().getResource("application.css").toExternalForm());
primaryStage.setScene(scene);
primaryStage.show();
root.setOnDragDetected(this::onDragDetected);
root.setOnDragOver(this::onDragOver);
root.setOnDragDropped(this::onDragDropped);
root.setOnDragDone(this::onDragDone);
} catch(Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
launch(args);
}
private final DataFormat f = new DataFormat() {
};
private void onDragDetected(MouseEvent event) {
System.err.println(this + " onDragDetected");
Dragboard db = root.startDragAndDrop(TransferMode.ANY);
ClipboardContent c = new ClipboardContent();
c.putString("Hello world");
db.setContent(c);
event.consume();
}
private void onDragOver(DragEvent event) {
event.getTransferMode();
event.acceptTransferModes(TransferMode.ANY);
System.err.println(event.getTransferMode());
// System.err.println("onDragOver " +
event.getAcceptedTransferMode());
event.consume();
}
private void onDragDropped(DragEvent event) {
System.err.println(this + " onDragDropped " +
event.getAcceptedTransferMode());
event.setDropCompleted(true);
event.consume();
}
private void onDragDone(DragEvent event) {
System.err.println(this + " onDragDone " +
event.getAcceptedTransferMode());
System.err.println("payload: " +
event.getDragboard().getString());
event.consume();
}
}
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
review: remove a cygwin dependancy
Kevin, I have been running with this for a couple of weeks now. remove a cygwin dependancy https://bugs.openjdk.java.net/browse/JDK-8151747 http://cr.openjdk.java.net/~ddhill/8151747/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: Conditionally save policy file in Sandbox tests
Kevin, Conditionally save policy file in Sandbox tests https://bugs.openjdk.java.net/browse/JDK-8153086 http://cr.openjdk.java.net/~ddhill/8153086/ a small change, but very helpful when debugging the Sandbox test apps -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: review: remove a cygwin dependancy
On 3/30/16, 2:02 PM, Ali Ebrahimi wrote:
Hi,
line
ByteArrayOutputStream out = new ByteArrayOutputStream();
can be removed!
Good catch!
thanks
On Wed, Mar 30, 2016 at 10:04 PM, David Hill mailto:david.h...@oracle.com>> wrote:
Kevin,
I have been running with this for a couple of weeks now.
remove a cygwin dependancy
https://bugs.openjdk.java.net/browse/JDK-8151747
http://cr.openjdk.java.net/~ddhill/8151747/
<http://cr.openjdk.java.net/%7Eddhill/8151747/>
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
--
Best Regards,
Ali Ebrahimi
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
review: javafx.swing system test RT30650Test fails in jigsaw mode
Kevin, you were right about: https://bugs.openjdk.java.net/browse/JDK-8152898 just need an add exports: diff -r 1a6124ade5b4 tests/system/src/test/addExports --- a/tests/system/src/test/addExports Wed Mar 30 13:58:30 2016 -0400 +++ b/tests/system/src/test/addExports Wed Mar 30 14:03:58 2016 -0400 @@ -18,5 +18,6 @@ javafx.graphics/com.sun.javafx.iio.png=ALL-UNNAMED,\ javafx.graphics/com.sun.javafx.image.impl=ALL-UNNAMED,\ javafx.graphics/com.sun.javafx.image=ALL-UNNAMED,\ + javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED,\ \ java.base/sun.util.logging=ALL-UNNAMED" -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: Add a command line toggle for worker.debug
Kevin, https://bugs.openjdk.java.net/browse/JDK-8153110 Add a command line toggle for worker.debug There is a diff inline in the bug that works for toggling worker.debug from the gradle command line -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: review: remove a cygwin dependancy
On 3/30/16, 1:34 PM, David Hill wrote: Kevin, I have been running with this for a couple of weeks now. remove a cygwin dependancy https://bugs.openjdk.java.net/browse/JDK-8151747 http://cr.openjdk.java.net/~ddhill/8151747/ I updated the webrev in place, removing the unneeded ByteArrayOutputStream and fixing the whitespace. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: CFV: New OpenJFX Committer: Murali Billa
On 3/31/16, 5:04 PM, Kevin Rushforth wrote: VOTE: yes I hereby nominate Murali Billa [1] to OpenJFX Committer. Murali is a member of JavaFX team at Oracle working on WebKit, who has contributed 10 changesets [5] to OpenJFX, at least 8 of which are significant. Votes are due by April 14, 2016. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#mbilla [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of changesets: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a251a1d65932 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ecea43f5734c http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/42b461505f27 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/82ecaebd44cf http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8643ca988cef http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/765fd07f22fc http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ae75f92d5e53 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/25db4b2e47a1 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/51c2129d282c http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/cb8a24f5db2a -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: convert addExports to new syntax
Kevin, yet another review for you to look at :-) https://bugs.openjdk.java.net/browse/JDK-8153231 http://cr.openjdk.java.net/~ddhill/8153231/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: move DragDrop test app to openjfx
move DragDrop test app to openjfx https://bugs.openjdk.java.net/browse/JDK-8153536 http://cr.openjdk.java.net/~ddhill/8153536/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review request: 8153657 fix DragDrop builds with ARM
Kevin, could you review the diff in: https://bugs.openjdk.java.net/browse/JDK-8153657 thanks! -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: Clear potential exception when reporting exceptions from JNI Glass GTK
Kevin, could you review: Clear potential exception when reporting exceptions from JNI Glass GTK A one line diff in: https://bugs.openjdk.java.net/browse/JDK-8154206 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: quiet Prism warnings
Kevin, Chien, would you review this quick fix to quiet some warnings ? Tested on OEL, Ubuntu, Mac Windows. https://bugs.openjdk.java.net/browse/JDK-8154256 http://cr.openjdk.java.net/~ddhill/8154256/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
early draft for 8087516: [JavaFX] Conditional support for GTK 3 on Linux
Kevin, Phil, anyone else interested. Here is an early draft of [JavaFX] Conditional support for GTK 3 on Linux <https://bugs.openjdk.java.net/browse/JDK-8087516> http://cr.openjdk.java.net/~ddhill/8087516.1/ There are some rough edges left, particularly with the GTK 3 side of shaped windows. Given my time frame, I am interested in feedback on what is there because the core of it is complete. I have done limited testing on this, some with GTK3 and have not found any problems so far. I have more unit testing planned for next week. The default GTK version will be GTK2. To use GTK3, use the following: -Djdk.gtk.version=3 To enable some really verbose output: -Djdk.gtk.verbose=true This verbosity will be reduced before I commit this - and only a message about the version actually used will be output. Known issues: Marked with a DAVE for easy cleanup later. * shaped windows with GTK3 - need to verify the new region methods * debug code that will be used to check that all of the code paths are tested. * move the disableGrab back into the main code logic. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: early draft for 8087516: [JavaFX] Conditional support for GTK 3 on Linux
On 4/23/16, 4:22 PM, Tom Schindl wrote: Hi, For FXCanvas it should be doable because you can check if SWT is running with GTK3 using 8< org.eclipse.swt.internal.gtk.OS.GTK3 : boolean 8< This is what e(fx)clipse uses today to cancel loading of FXCanvas because it would core-dump your application [1]. IIRC this flag is there since the last SWT release! There is an interesting idea. I had not thought about using java reflection. The newness of the variable is a down side though. Will have to try some stuff once I get the initial - non-detecting work cleaned up enough to get in place. In particular - a last look at using dlopen, and maybe the proc stuff. The detection code could go in as a bug fix after the initial submital of the functionality. Tom, Sounds like you might be able to help us test after we integrate :-) Dave Tom [1]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.osgi/src/org/eclipse/fx/osgi/fxloader/FXClassLoader.java On 23.04.16 20:30, Philip Race wrote: That may be [need to be] ironed out later. We are not certain there is a 100% reliable mechanism for this. Some experiments on the AWT equivalent using dlopen(..) with RTLD_NOLOAD is apparently failing to detect that gtk3 was loaded in the case it was loaded by SWT. An alternative but not very pretty approach using /proc has been proposed. ' Any boiler plate code that works across all versions of Linux/Unix and where you do not control the manner in which gtk3 was loaded is proving elusive. And nothing will help in the case that FX is loaded first and gtk/swt is loaded later. -phil. On 4/23/16, 10:32 AM, Tom Schindl wrote: David / Kevin, Do you see chances to detect for the SWT case if we are running with SWT on Gtk3 or Gtk2 and not having to use -Djdk.gtk.version=3 The problem with requiring one to switch by setting the System-Property is that eg if someone want to use FX in the Eclipse IDE he does not control the Java-Launch Process. Tom On 23.04.16 00:50, David Hill wrote: Kevin, Phil, anyone else interested. Here is an early draft of [JavaFX] Conditional support for GTK 3 on Linux<https://bugs.openjdk.java.net/browse/JDK-8087516> http://cr.openjdk.java.net/~ddhill/8087516.1/ There are some rough edges left, particularly with the GTK 3 side of shaped windows. Given my time frame, I am interested in feedback on what is there because the core of it is complete. I have done limited testing on this, some with GTK3 and have not found any problems so far. I have more unit testing planned for next week. The default GTK version will be GTK2. To use GTK3, use the following: -Djdk.gtk.version=3 To enable some really verbose output: -Djdk.gtk.verbose=true This verbosity will be reduced before I commit this - and only a message about the version actually used will be output. Known issues: Marked with a DAVE for easy cleanup later. * shaped windows with GTK3 - need to verify the new region methods * debug code that will be used to check that all of the code paths are tested. * move the disableGrab back into the main code logic. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review:
Morris, would you please review: JDK-8155114: Set both X and Y position for some window managers <https://bugs.openjdk.java.net/browse/JDK-8155114> webrev: http://cr.openjdk.java.net/~ddhill/8155114/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review for Linux: unit test failures in ImageTest on some systems
Kevin, Linux: unit test failures in ImageTest on some systems https://bugs.openjdk.java.net/browse/JDK-8089960 http://cr.openjdk.java.net/~ddhill/ 8089960 <https://bugs.openjdk.java.net/browse/JDK-8089960> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: [9] Review request: 8154186: JVM crash while using JavaFW WebView and colgroup/cols html feature
On 4/27/16, 9:56 AM, Guru Hb wrote:
Hi Dave & Kevin,
Could you please review updated Unit test case
http://cr.openjdk.java.net/~ghb/8152420/webrev.01/
Solution updated in JBS.
Hi Guru,
JDK-8154186 is closed, so I suspect you will need to open a new bug. Kevin
will say for sure but I think the new world is one commit/one bug id.
Looking at the changes - the only minor issues I have are:
The new directory build/resources for the jar file. While not a big deal,
build/testing (perhaps build/testing/resources ?) feels like a better home as
the jar is for testing purposes. build/testing was added with Jigsaw, so you
may not have noticed it in your build, but we are headed that way :-)
The assumption of a working directory in the test:
load("jar:" + new File("build/resources/webArchiveJar.jar")
This is /probably/ ok from a sustainability point of view. But there are other places
where we pass in a property to find stuff in the build tree like: def cssDir =
file("$buildDir/classes/main/javafx")
jvmArgs "-Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit",
"-DCSS_META_DATA_TEST_DIR=$cssDir"
+1 after consideration of these minor points, and I am OK if they are not acted
on.
Dave
Thanks,
Guru
On 20/4/16 7:25 PM, Guru Hb wrote:
Hi Alexander Z , Kevin & Arunprasad,
Please review the fix :
https://bugs.openjdk.java.net/browse/JDK-8154186
http://cr.openjdk.java.net/~ghb/8154186/webrev.00/
Root Cause and solution updated in JBS.
Thanks,
Guru
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
Re: CFV: New OpenJFX Committer: Guru Hb
On 4/28/16, 11:16 AM, Kevin Rushforth wrote: I hereby nominate Guru Hb [1] to OpenJFX Committer. vote: yes Guru is a member of JavaFX team at Oracle working on WebKit, who has contributed 10 changesets [5] to OpenJFX, at least 8 of which are significant. Votes are due by May 12, 2016. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#ghb [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of changesets: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/1ec63f261e9f http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/fb4c37073893 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ccf14ef836f http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/45efd3d83bf1 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/08a57f273c76 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/bd97f8ca31fc http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/0576d7a6f137 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/d4f8c9496683 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/620f5c6b4383 http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/aa51df7e1d41 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review for minor changes to build.gradle
Kevin, a couple of proposed changes to build.gradle. Diffs are inline in the bugs. Provide for extra jvm arguments for gradle test task https://bugs.openjdk.java.net/browse/JDK-8155831 Allow disabling :web:test https://bugs.openjdk.java.net/browse/JDK-8155832 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: [JavaFX] Conditional support for GTK 3 on Linux
Kevin, Phil, https://bugs.openjdk.java.net/browse/JDK-8087516 [JavaFX] Conditional support for GTK 3 on Linux Here is the latest version of the changes. This addresses the issues raised by Kevin, as well as some other minor cleanups. This passes a FULL_TEST and Robot manual tests with GTK 2 & 3 for me. http://cr.openjdk.java.net/~ddhill/8087516.2/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review:
Kevin, please review this fix to update our handling of -Xpatch with tests and provide a @xpatch.args for general developement. https://bugs.openjdk.java.net/browse/JDK-8155862 http://cr.openjdk.java.net/~ddhill/8155862 <http://cr.openjdk.java.net/%7Eddhill/8155862> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review v3: [JavaFX] Conditional support for GTK 3 on Linux
version 3: http://cr.openjdk.java.net/~ddhill/8087516.3/ This reworks the loading of the gtk symbols, providing for trying .so.0 first, and falling forward or back between 2 & 3. The meat of the change in the rework in wrapper_main.c I also removed the block of code mentioned by Serge in GlassApplication.cpp -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
JFX - Running with Jigsaw in development
We have a new trick in the FX repo to help with running FX apps backed by a Jigsaw enabled build. If you build FX with JIGSAW_HOME set to a JDK 9 build later than build 110, then the Jigsaw modules will be generated. These modules can be used with -Xpatch to override the modules in JDK9. Unfortunately each module must be listed separately, and we need a -Djava.library.path to find the built native libraries - a very verbose command line... But... recently added to the build, a new file is now created: build/xpatch.args that has all of this for you. export JIGSAW_HOME="path_to_top_of_JDK9" export JFX_BUILD="path_to_top_of_your_repo" alias javafx='$JIGSAW_HOME/bin/java @$JFX_BUILD/build/xpatch.args' This alias uses the @argfile mechanism to include all that Xpatch/java.library.path verbosity to create a single command to run FX backed by your recently built binaries. Get your Jigsaw enabled JDK9 preview here: https://jdk9.java.net/download/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review v4: [JavaFX] Conditional support for GTK 3 on Linux
Minor cleanups version 4: http://cr.openjdk.java.net/~ddhill/8087516.4/ changes from 3: http://cr.openjdk.java.net/~ddhill/8087516.4d/ -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Support for GTK 2 & 3 now in JFX
I added a new feature Friday and would like some help testing it. This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to use either GTK v2 or 3 with JavaFX. The default has not changed - we will use gtk 2 by preference. The help I need is for anyone doing testing on Linux with the current tree - like todays sanity testing. Adding -Djdk.gtk.verbose=true should output the version detected and used. I would appreciate a paste of that along with the OS version. -Djdk.gtk.version=3 toggles the preferred version to GTK 3. Testing using that toggled would also be appreciated, along with a note to me with the OS version. thanks! -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: Support for GTK 2 & 3 now in JFX
On 5/9/16, 9:39 AM, Erik De Rijcke wrote:
Hi,
Are there any known limitations on the gtk3 backends (html5, wayland, ...) that
could be used?
In short - no, but do tell if you find some :-)
The problem before was that you can't mix GTK2 & 3 in the same application, so SWT
for example that is using GTK3 would crash and burn. With the addition of dynamic loading
of GTK we can at least avoid that issue - at least as long as you tell the app which
version to use. I have a task to investigate detecting if a version is already in use
<https://bugs.openjdk.java.net/browse/JDK-8156491>, but that has some portability
issues and might not make the final product. I am not aware of any reason why there would
be an issue - unless there is something with the GTK event loop.
Let me know if you give it a try.
Dave
regards,
Erik
On Mon, May 9, 2016 at 3:18 PM, David Hill mailto:david.h...@oracle.com>> wrote:
I added a new feature Friday and would like some help testing it.
This new feature (8087516: Conditional support for GTK 3 on Linux) allows
us to use either GTK v2 or 3 with JavaFX.
The default has not changed - we will use gtk 2 by preference.
The help I need is for anyone doing testing on Linux with the current tree
- like todays sanity testing. Adding
-Djdk.gtk.verbose=true
should output the version detected and used. I would appreciate a paste of
that along with the OS version.
-Djdk.gtk.version=3
toggles the preferred version to GTK 3. Testing using that toggled would
also be appreciated, along with a note to me with the OS version.
thanks!
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
review: remove use of GetPropertyAction
Kevin, https://bugs.openjdk.java.net/browse/JDK-8157280 webrev: http://cr.openjdk.java.net/~ddhill/8157280 <http://cr.openjdk.java.net/%7Eddhill/8157280> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: Correct unused import in FXDnD
Kevin, https://bugs.openjdk.java.net/browse/JDK-8157390 webrev: http://cr.openjdk.java.net/~ddhill/8157390 <http://cr.openjdk.java.net/%7Eddhill/8157390> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: missing export to fxml in base module
Kevin, a patch inline: https://bugs.openjdk.java.net/browse/JDK-8157473 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: remove old annotations from web
Kevin, another inline diff: https://bugs.openjdk.java.net/browse/JDK-8157477 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: Openjfx on Wanboard
On 6/7/16, 6:08 AM, Guillaume sétan wrote: Hi, I want to use Java with JavaFX on my wandboard but I see that the arm's version was unsupported on the website Oracle. So I found a other solution OpenJFX. But I try 2 things : - To download the package with apt-get install, but he can't found libopenjfx-jni. -To compile OpenJFX but I get this exception "Unknown and unsupportef build architecture: arm " ( I have a Linux armv7l). Do you have solutions for one of these problems ? I doubt you would find javafx with apt-get. That would likely be an openjdk build without javafx integrated. For a quick start, you might try one of the community builds (https://wiki.openjdk.java.net/display/OpenJFX/Community+Builds), making sure that you have JDK version 8 (not 7) installed. There are some platform notes here too https://wiki.openjdk.java.net/display/OpenJFX/Platforms Oracle is no longer supporting FX on arm platforms, rather relying on a combination of community support with some of my time when I can squeeze it in. In particular, Oracle is working hard on JDK9 which requires FX to be integrated as part of the JDK. This is a big shift, because with JDK8 we could build/provide FX as an "overlay" onto an existing JDK. Sometime in the next couple of months I do plan on trying an integrated ARM JDK/JFX build to prove it can be done, and will be updating the OpenJFX wiki as I do. I have tried an integrated build on Linux x64, and it does seem to "just work" :-) Also - never tried the Wandboard. I know it is a varient of the i.MX so likely will just work. Some of the ARM boards are not so easy though. Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: Building OpenJFX for the first time
On 6/17/16, 4:17 PM, John C. Turnbull wrote: Thanks Kevin - that looks very helpful. -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Saturday, 18 June 2016 05:53 To: openjfx-dev@openjdk.java.net Subject: Re: Building OpenJFX for the first time https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX Dave Hill updated it recently, so it is reasonably current. And he is always interested in suggestions/clarifications and kudos :-) Seriously - I have several environments (virtual boxes) that I try the procedure in, but that does not mean that I can come close to coverage of the environments out there. So feedback is always welcome. Dave -- Kevin John C. Turnbull wrote: I would like to set up a development environment for the OpenJFX project but have never attempted this before. I am very familiar with all 3 major Java IDEs with my preference (in order of most favourite to least favourite) is Eclipse, IntelliJ, NetBeans (so whichever one is "best" doesn't really matter). I am familiar with Gradle but by no means an expert. My machine is a Windows 10 x64 PC. I am only interested in building for JDK 9 and JavaFX 9 (as these will be released before any project I am working on will go live). I am happy to build just for Windows at this point so I can get a feel for the project and see if there are opportunities where I can fix a bug or two or make contributions in other ways. So, what is the best way to build this project using the environment and tools I have described? Which IDE would make the process the simplest or easiest? Is there an up-to-date web page that describes the process in sufficient detail that will enable me to accomplish this? Thanks very much, John -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: [9] Review Request: 8149975: [packager] Programmatically Determine JDK or JRE Modules
On 7/5/16, 8:40 PM, Chris Bensen wrote: Hi David, Please review this change for the Java Packager to programmatically get a list of the modules that are to be redistributable. This was waiting on https://bugs.openjdk.java.net/browse/JDK-8155955 and https://bugs.openjdk.java.net/browse/JDK-8160005 which have now fixed, but is still waiting on https://bugs.openjdk.java.net/browse/JDK-8158410 but I thought I’d get the review complete in the meantime. Let me know if the build.gradle changes are to your liking. JIRA: https://bugs.openjdk.java.net/browse/JDK-8149975 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8149975/webrev.01/ <http://cr.openjdk.java.net/%7Ecbensen/JDK-8149975/webrev.01/> Thanks, Chris Couple of minor nits added to the jbs. Kevin did not say what the changes that are needed in 8158410 <https://bugs.openjdk.java.net/browse/JDK-8158410>, I wonder if they are in place already. Dave -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Review: Clean up module relative paths in build.gradle
Chien, could you review: https://bugs.openjdk.java.net/browse/JDK-8161227 webrev: http://cr.openjdk.java.net/~ddhill/8161227 <http://cr.openjdk.java.net/%7Eddhill/8161227> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
CFV: New OpenJFX Committer: Ankit Srivastava
I hereby nominate Ankit Srivastava to OpenJFX Committer. Ankit Srivastava is part of the JavaFX team focusing on Web. A list of Ankit's commits and reviews is available by the following links http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=a.ankit.srivast...@oracle.com http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=asrivastava Votes are due by August 3th, 2016. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave
review: Fix more hardcoded paths in gradle build
Kevin, if you could review: https://bugs.openjdk.java.net/browse/JDK-8162114 webrev: http://cr.openjdk.java.net/~ddhill/8162114 <http://cr.openjdk.java.net/%7Eddhill/8162114> -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: Rename directories under modules to exactly match the module names
This is a biggie and is presented a bit not traditionally. In short, we need to rename modules/*/ to match the new JDK9 module names - javafx.* (with a few exceptions). For your review - a webrev of the actual changes needed in files to support this change. And... the script that will be used to 'hg mv' the hierarchies. This operation generates a HUGE diff that is not very informative for reviewers. This rename operation has been tested by myself, Kevin, Vadim, Chien and our Hudson server in test builds. jbs: https://bugs.openjdk.java.net/browse/JDK-8161705 webrev: http://cr.openjdk.java.net/~ddhill/8161705 rename script: http://cr.openjdk.java.net/~ddhill/8161705/module_rename -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Migrating FX patches to/from module paths
Hi all, with the rather large change set that just landed in openjfx, there will be some developers with a need to convert existing patches for use with the new module source paths, or need to back port a patch to the old module source paths. We have provided a set of scripts that can be used to help with this conversion. Old style to new style (ex: module/graphics ---> module/javafx.graphics) bash tools/scripts/fix_patch_8_9 < old_patch > new_patch New style to old style, likely for back porting (ex: module/javafx.graphics ---> module/graphics) bash tools/scripts/fix_patch_9_8 < old_patch > new_patch Note: * these scripts only modify the "diff paths" and should not modify the actual contents of the file changes. * testing has validated the rather complex regex in the scripts, but ... triple check that the resulting patch is correct! Likely the new_patch will fail to apply cleanly if there is an error, but check the resulting diffs to make sure. * your mileage may vary. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: Add xpatch argfile creation script
JBS: https://bugs.openjdk.java.net/browse/JDK-8162872 This adds a simple script that will create a "xpatch" file for a modular build output. This xpatch file will resemble the current build/xpatch.args file created by the build. This script is needed if you want to copy/download or whatever the build output to another location. The arguments in the file really have to be full paths to enable Java to find them. Script is attached to the JBS. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
review: (JDK-8163010) support macosx with fix_patch scripts
Kevin, I really dislike platform specific code :-) yet another review (JDK-8163010) support macosx with fix_patch scripts <https://bugs.openjdk.java.net/browse/JDK-8163010> attached new versions of the files as it is a pretty big makeover. Diff is in the jbs. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Result: New OpenJFX Committer:Ankit Srivastava
Voting for Ankit Srivastava (asrivastava) to OpenJFX Committer [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-May/013881.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
Re: Compiling OpenJFX on OpenBSD
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) at org.gradle.launcher.Main.doAction(Main.java:33) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at org.gradle.groovy.scripts.AbstractUriScriptSource.classNameFromPath(AbstractUriScriptSource.java:54) at org.gradle.groovy.scripts.AbstractUriScriptSource.getClassName(AbstractUriScriptSource.java:40) at org.gradle.groovy.scripts.DelegatingScriptSource.getClassName(DelegatingScriptSource.java:32) at org.gradle.groovy.scripts.internal.BuildScopeInMemoryCachingScriptClassCompiler.compile(BuildScopeInMemoryCachingScriptClassCompiler.java:45) at org.gradle.groovy.scripts.DefaultScriptCompilerFactory$ScriptCompilerImpl.compile(DefaultScriptCompilerFactory.java:50) at org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:152) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyScript(DefaultObjectConfigurationAction.java:102) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$000(DefaultObjectConfigurationAction.java:36) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$1.run(DefaultObjectConfigurationAction.java:62) at org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136) at org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46) at org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.java:34) at build_17kvkvc4f9j45htivwn1v303b$_run_closure5.doCall(/tmp/rt-b41445afa464/build.gradle:614) at build_17kvkvc4f9j45htivwn1v303b.run(/tmp/rt-b41445afa464/build.gradle:612) at org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:91) ... 47 more BUILD FAILED Total time: 19.946 secs -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: Compiling OpenJFX on OpenBSD
On 8/4/16, 10:48 AM, Turvamies IT Security Services wrote:
Guys,
I think you're spot on with the COMPILE_TARGETS notion.
If you are game, you could try extending this:
ext.IS_LINUX = OS_NAME.contains("linux")
to be
ext.IS_LINUX = OS_NAME.contains("linux") || OS_NAME.contains(what ever is set
for bsd)
and see what happens.
I did tried compiling gradle 2.11 anyways, but that failed since
https://downloads.gradle.org/distributions-snapshots/gradle-2.11-20160112230025+-bin.zip
does not exist anymore.
Any ideas how to proceed from here? Apparently I'll have to come up
with a custom OpenBSD COMPILE_TARGET, right?
Yours,
Jyri
--
Turvamies IT Security Services
On Thu, 04 Aug 2016 07:33:39 -0700
Kevin Rushforth wrote:
Ah, you might be right, in which case gradle 2.11 won't solve his
problem.
-- Kevin
Vadim Pakhnushev wrote:
I'd say the culprit is here:
08:38:45.852 [INFO] [org.gradle.api.Project] Applying
COMPILE_FLAGS_FILE 'buildSrc/.gradle'
I think that COMPILE_TARGETS is "" since it's not a "mac", not a
"win" nor a "linux".
Vadim
--
David Hill
Java Embedded Development
"A man's feet should be planted in his country, but his eyes should survey the
world."
-- George Santayana (1863 - 1952)
review: Build should fail fast with unsupported OS/ARCH
thanks to Jyri's email, I have a simple fix to fail quickly and with a understandable error message. jbs: https://bugs.openjdk.java.net/browse/JDK-8163196 simple diff inside jbs -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
Re: Compiling OpenJFX on OpenBSD
On 8/4/16, 1:51 PM, Turvamies IT Security Services wrote: Actually, the problem appears to be with ld rather than g++. This thread gave me a hint: https://forums.freebsd.org/threads/5799/ "ldl is libdl. It is a linuxism. FreeBSD does not have a libdl. The same functionality that is in linux's libdl is provided in FreeBSD's libc. So you should be able to simply remove -ldl from CFLAGS and try compile." I know I should edit build.gradle further so that ldl is not included in CFLAGS when compiling on OpenBSD, but I have not worked with gradle build files and would very much appreciate it if you guys could help me out in crafting the proper target definitions for OpenBSD. The definitions are in buildSrc/linux.gradle The challenge would be fixing this in a way that would not break the linux builds. In theory, it would be possible to clone linux.gradle to bsd.gradle, fix the compile line issues in that configuration and then build with gradle -PCOMPILE_TARGETS=bsd With the change you have done, we would treat the platform as similar to linux, but with a configuration of bsd. Dave - Jyri -- Turvamies IT Security Services -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952)
