Re: including fonts
I guess I was assuming the "ideal"/expected behavior applied? Sorry... On Sun, Jan 3, 2016 at 10:14 AM, Tom Eugelink <t...@tbee.org> wrote: > Hi David, > > Which would assume that if I specify no keywords, then it should take the > normal version. It does not. Whatever version is loaded last is used. > > Tom > > > > On 3-1-2016 17:09, cogmission (David Ray) wrote: > >> Hi Tom, >> >> I Believe in CSS, once you establish the family you can access the >> sub-types via type keywords? >> ...via >> >> -fx-font-weight: bold,bolder etc. >> -fx-font-style: plain, italic >> >> Cheers, >> David >> >> On Sun, Jan 3, 2016 at 8:52 AM, Tom Eugelink <t...@tbee.org > t...@tbee.org>> wrote: >> >> Addendum: >> >> If I list the font families using Font.getFamilies() I get "Roboto >> Medium" once, given that both TTF files are added using @font-face. But if >> I examine Font.getFontNames() I get separate entries for "Roboto Medium" >> and "Roboto Medium Italic". Closer examination of the font loading reveals >> that indeed each font has its own distinct name and some fonts shared the >> same family name. That makes sense. >> >> The thing is that in CSS -as far as I can see- fonts can only >> accessed through its family name, not its own name. >> >> Tom >> >> >> >> On 3-1-2016 11:21, Tom Eugelink wrote: >> >> I'm currently including Google's Roboto font in JFXtras and >> making it easily available to other users. I noticed that the font-family >> attribute in font-face is ignored, and you have to use the name as it is >> specified in the TTF file. I found >> https://bugs.openjdk.java.net/browse/JDK-8094516 which says "/Please >> note that all @font‑face descriptors are ignored except for the src >> descriptor./" That pretty much explains what is going on. >> >> Now, Roboto comes in different styles, condensed, bold, etc, but >> also italic. However, italic is a separate TTF file, so you have a >> Roboto-Medium.ttf and a Roboto-MediumItalic.ttf. The name of the font >> inside these two TTF files is the same, so when I use "font-family: 'Roboto >> Medium'" whatever ever font is defined last by font-face is used, and the >> other is not accessible. >> >> My question is: is the way Roboto does Italic, with the same font >> name in the TTF file, a bug of Roboto, or is this common? >> >> Tom >> >> >> >> >> >> -- >> /With kind regards,/ >> David Ray >> Java Solutions Architect >> *Cortical.io <http://cortical.io/>* >> Sponsor of: HTM.java <https://github.com/numenta/htm.java> >> d@cortical.io <mailto:d@cortical.io> >> http://cortical.io <http://cortical.io/> >> > > -- *With kind regards,* David Ray Java Solutions Architect *Cortical.io <http://cortical.io/>* Sponsor of: HTM.java <https://github.com/numenta/htm.java> d@cortical.io http://cortical.io
The Case for JavaFX Emulated LFs (across iOS, Android etc.)
The argument against emulated LFs hinges on one point: That they will always be one step behind. This (Greg Brown et al.) is a fallacy! The reason being is that companies like Apple and Google count on affinity, acculturation, and familiarization with a given method of presentation in order to increase patronage! It is *not* like these companies change their LFs with every new release. You are confusing language/application features with presentation formats - which *do not* change at the same rate. Apple has changed its iOS widget set twice in the last ~10 years! (while features do in fact change) ...and let's not talk about the speed of Android feature uptake; let alone actual GUI widget-set changes? Yes, Oracle can indeed keep up with LF changes - *easily*; and they do not have to worry about features so much because much of that is passed to implementation developers. Another point. HTML 5 usage idioms suck. (Sorry, I feel strongly about this). The whole idea of spreading LF configuration across 2 or 3 different formats is ill-conceived and painfully over-verbose! (Yes I'm talking about FXML, BXML; CSS etc...) The fact that it allows designers to function autonomously is also a fallacy. I have never seen this play out in actual practice - as time-to-market doesn't allow the creation of perfect code (in terms of separation of concerns) - because developers cost too much money; and while companies want expressively rich UIs - they are concordantly not willing to pay for it. (unfortunately - I have seen this over and over and over again). Back to the point... Spreading the UI definition across language formats means the developer has to learn more than one format to get the job done - thus invoking the eventuality; Jack of all trades; Master of none. This also makes maintainability dependent on local convention (which is absurd and not dependable across implementation entities). The only thing it (FXML, BXML) is good for is automatic GUI builder implementations; and it should be left at that. CSS is not intuitive (as is a GUI widget toolset API; in the language of implementation). Mastery depends on memorization (which is a losing proposition for uptake); instead of intuitive insight across consistent methods of accomplishing tasks. I think in our field, if something is said often enough - it starts to be accepted as truth. I for one would like to stand up against some of these misnomers. I apologize for my emphatic expression of these points - I have been holding this in for a long time :-P -- *With kind regards,* David Ray Java Solutions Architect *Cortical.io http://cortical.io/* Sponsor of: HTM.java https://github.com/numenta/htm.java d@cortical.io http://cortical.io
Like if you agree!
Hi, I just wanted to share some opinions close to my heart... https://www.linkedin.com/pulse/exposing-myth-case-javafx-emulated-lfs-david-ray?published=t Cheers, David -- *With kind regards,* David Ray Java Solutions Architect *Cortical.io http://cortical.io/* Sponsor of: HTM.java https://github.com/numenta/htm.java d@cortical.io http://cortical.io
Re: Show case: JFX on iOS and Android
Awesome work Tobias! :) On Nov 18, 2013, at 4:02 PM, Tobias Bley t...@ultramixer.com wrote: For all who do not follow me on twitter: a few screenshots concerning JFX on iOS and Android: http://blog.software4java.com/?p=148#comment-4629 Best regards, Tobi -- Tobias Bley Chief Executive Officer Tel +49 351 - 264 49 86 Fax +49 180-3555688-50 UltraMixer Digital Audio Solutions Am Waldschlößchen 2 D-01099 Dresden Germany b...@ultramixer.com http://www.ultramixer.com
Re: JavaFX on iOS and Android - are we there yet?
+1 re: Native LF. IMO also there is nothing sacred about the exactness of Apple's ui. They 'll be changing it up a lot a also. Being someone who prefers custom looks to bland native looks anyway, I never did get the sacredness of repeating mirror-lookalike grey :). Just my opinion, I'm sure there are those who disagree. David Sent from my iPhone On Oct 22, 2013, at 7:17 AM, Tobias Bley t...@ultramixer.com wrote: 1) Look and Feel: IMO it’s enough to build „native looking“ css based skins! That could be very quickly without complex technologies like CALayer etc. 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… Tobi Am 21.10.2013 um 21:48 schrieb Richard Bair richard.b...@oracle.com: 1. Can you provide me with a detailed summary of where the iOS/Android ports are currently? This includes the platform specific stuff to make either RoboVM or an Oracle JVM work? I would say, it is in a good prototype stage. It hasn't had heavy testing, so the biggest risk is the unknown. Luckily, on iOS at least there are only a very few devices so it should be relatively easy for an app developer to feel confident it works for their app. But for the OpenJFX project, to test and certify a whole variety of APIs, will be quite a challenge. We have a huge pile of tests, we just need: 1) To have a way to run our unit tests on the actual devices 2) Have a way to run graphical tests on devices (basically a port of Jemmy??) I haven't scoped either of these efforts, but both are ripe areas for collaboration with anybody in the community. If it were heavily tested, I'd say most of the remaining work is actually in the graphics / performance side. Path rendering performance is fairly bad (though I've seen similar complaints for Cocoa path rendering performance, so it may be we're not that bad relatively speaking, but it is still horrendous IMO and needs to be looked at). The code is all there for the integration layer -- anybody with familiarity with Objective-C and Cocoa, I'd say, go read the glass code! This is a huge opportunity for community initial community involvement because: 1) There is a ton of existing documentation and code in the Apple universe describing all the sorts of things we need to do in Glass 2) Glass is pretty decoupled from the rest of the platform, so you can easily understand what is going on there without having to understand everything else Contributing on the Graphics side is more work and requires more specialized skills. The fortunate thing here is that the graphics code is shared with embedded (and desktop Mac and Linux) so there is a lot of overlap. So those would be the main things from my perspective: performance testing, functional / unit testing, native platform integration, and graphics. Another thing we've designed for from the beginning, but never validated, is the ability to use a native control as the skin. The iOS prototype hot swaps a native text field in when a TextInputControl gets focus, but this is kinda funky (and there are lots of bugs here). The right thing to do here would be to have a set of native skins for controls, and the ability to create multiple core layers. So if you have a scene graph where on the bottom you draw stuff, then have a native control, then draw more stuff over the native control, then what you would want is, on the Prism side, use 3 hardware layers (one for below the native, one for the native, and one for above the native). I don't know: 1) How well this would work in practice with input events (but one could imagine putting a native 'glass pane' on the top to intercept all events and vector them through FX, forwarding to native controls as necessary as part of the normal FX event dispatch) 2) How many layers you could have before things would explode. Alternatively, using image skinning to get the look right, and only do the funky native control swap in for text input, like we're doing today. 2. Are the iOS and Android ports at roughly the same level of completeness/viability? I think so, David / Tomas, can you guys add some insight as to where we're at from your perspective? 3. Exactly what is left in making these ports viable? Here the word viable is defined in my 6 Degrees of Separation post here http://justmy2bits.com/2013/09/30/javafx-on-ios-and-android-six-degrees-of-separation 1. Their look and feel is indistinguishable from native apps As described above, there is work to be done here either by beefing up the emulation, or adding the ability to intersperse native controls. The latter approach I expect to be significant work, although technically feasible. Also, I expect people
Re: JavaFX on iOS and Android - are we there yet?
I think you may be facing an absolute requirement which is placing demands on you to replicate the exact look and feel of one or both mobile environments? I'm not sure?? Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I do not see the problem with the above? Yes, the controls in question would maybe act differently than their native counterparts and Yes there may not be the exact complement of controls each native platform has, but my reaction to that is… so what? The fact is, these controls are born of a different gui toolkit. This only is a problem if one has it stuck in their head that JavaFX has to behave em exactly /em like the native platform - I don't see why this is necessary, especially when the variations are minor behavioral aspects anyway? The CSS skinning in my opinion is to most closely approximate the native look and feel IMO. I just don't see why it is necessary to reproduce the iOS toolkit or the Android toolkit in JavaFX? This to me is a way to ensure rigidity and lack of movement. As long as what *does* exist is rock-solid, dependable and very close looking - then I say good enough. Otherwise, why not just use Objective-C or Android?? It is way better to have vertical movement and obvious progress, IMO. I did find the link to your 6 - degrees… publication - and I vow to read it in case my opinion comes down on the misguided side of things, but I just don't see the need for such a tight constraint??? Regards, David On Oct 22, 2013, at 3:26 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. Then there's the issue that every time the OS changes and the behaviour or appearance of those native controls changes, the author of those JavaFX controls has to react accordingly. The issue of keyboard type and layouts is mentioned in my 6 Degrees of Separation post and is critical. There's just no way we are going to get away with any kind of text control that does not support all the native features of entering text on mobiles and tablets. Whether we place a borderless native text box inside a JavaFX shape or just integrate the native control itself, this is one of the most important features for a JavaFX app and one where it would fail spectacularly if this native support was not in place. I know some excellent work has been done on OS skins like AquaFX but appearance is only half the challenge. As I said, it's the behaviour that will kill us. To attempt to emulate all native control behaviour in lightweight controls is not only nearly impossible but in my view it's a massive waste of effort if it is somehow possible to integrate the actual native control itself. I am hopeful that the layering paradigm will gives us this. Another issue though is that native controls are unlikely to be as skinnable as JavaFX controls and are probably more limited in the scope of the customisation of their appearance. Integrating native controls may then impose limitations on the richness of the interface as it mandate an LCD approach so that the native controls don't look out of place. To me, the ideal solution would be to just extract/integrate the non-visual aspects of native controls (such as the auto-complete, keyboard customisations, other behaviour etc.) and then render them with the JavaFX API/scenegraph. On 23 October 2013 05:22, Stefan Fuchs snfu...@gmx.de wrote: Hi Richard, I currently try to release updates of the jfx78 back port in 1-3 days after https://bitbucket.org/**openjfxmirrors/openjfx-8-**master-rthttps://bitbucket.org/openjfxmirrors/openjfx-8-master-rt(from whereever this comes from) has been updated (usually every Friday). This obviously depends on the number of changes required and my available time. Stefan 2) After starting RoboVM JavaFX needs round about 10 seconds to start the simple list example on iPhone4. So it’s too long. I tried to use the preloaded class via property „-Djavafx.preloader“ but it doesn’t work, my preloaded class is not instantiated… What is the state of the jfx78 back port, and how often is
Re: JavaFX on iOS and Android - are we there yet?
Ok, I have read your 6 Degrees… publication, and I have to say I agree wholeheartedly with points 2 - 6. I just don't see why 90% of the common set of gui widgets, rock solid dependability and performance isn't good enough? Maybe others disagree I don't know… but if it comes down to being an engineering nightmare or so complex that the dependability or upgradeability is not there, then I just don't see it as important enough to warrant the abandonment of the effort? Regards, David On Oct 22, 2013, at 3:51 PM, David Ray cognitionmiss...@gmail.com wrote: I think you may be facing an absolute requirement which is placing demands on you to replicate the exact look and feel of one or both mobile environments? I'm not sure?? Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. I do not see the problem with the above? Yes, the controls in question would maybe act differently than their native counterparts and Yes there may not be the exact complement of controls each native platform has, but my reaction to that is… so what? The fact is, these controls are born of a different gui toolkit. This only is a problem if one has it stuck in their head that JavaFX has to behave em exactly /em like the native platform - I don't see why this is necessary, especially when the variations are minor behavioral aspects anyway? The CSS skinning in my opinion is to most closely approximate the native look and feel IMO. I just don't see why it is necessary to reproduce the iOS toolkit or the Android toolkit in JavaFX? This to me is a way to ensure rigidity and lack of movement. As long as what *does* exist is rock-solid, dependable and very close looking - then I say good enough. Otherwise, why not just use Objective-C or Android?? It is way better to have vertical movement and obvious progress, IMO. I did find the link to your 6 - degrees… publication - and I vow to read it in case my opinion comes down on the misguided side of things, but I just don't see the need for such a tight constraint??? Regards, David On Oct 22, 2013, at 3:26 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Even the most fab skins or CSS is not going to get us away from the need to integrate JavaFX controls with true native controls. As has been pointed out, there are some native controls on both iOS and Android for which there is no JavaFX equivalent and this will always be the case. Even if someone were to develop near identical lightweight controls in JavaFX, they would need to behave slightly differently on iOS than they do on Android and vice versa. Then there's the issue that every time the OS changes and the behaviour or appearance of those native controls changes, the author of those JavaFX controls has to react accordingly. The issue of keyboard type and layouts is mentioned in my 6 Degrees of Separation post and is critical. There's just no way we are going to get away with any kind of text control that does not support all the native features of entering text on mobiles and tablets. Whether we place a borderless native text box inside a JavaFX shape or just integrate the native control itself, this is one of the most important features for a JavaFX app and one where it would fail spectacularly if this native support was not in place. I know some excellent work has been done on OS skins like AquaFX but appearance is only half the challenge. As I said, it's the behaviour that will kill us. To attempt to emulate all native control behaviour in lightweight controls is not only nearly impossible but in my view it's a massive waste of effort if it is somehow possible to integrate the actual native control itself. I am hopeful that the layering paradigm will gives us this. Another issue though is that native controls are unlikely to be as skinnable as JavaFX controls and are probably more limited in the scope of the customisation of their appearance. Integrating native controls may then impose limitations on the richness of the interface as it mandate an LCD approach so that the native controls don't look out of place. To me, the ideal solution would be to just extract/integrate the non-visual aspects of native controls (such as the auto-complete, keyboard customisations, other behaviour etc.) and then render them with the JavaFX API/scenegraph. On 23 October 2013 05:22, Stefan Fuchs snfu...@gmx.de wrote: Hi Richard, I currently try to release updates of the jfx78 back port in 1-3 days after
Re: Why is almost everything in the API final
Final methods more so take the control out of the hands of the many developers, and places it in the hands of the API designers. If there is an issue, and demands are high - would we rather A. Report the issue and wait for the original API designer's development process to acknowledge, repair, and release a fix? -or- B. Report the issue to begin the above process, and improvise a workable workaround that let's a developer continue on with their work? I too observed the advantages of being able to do this in SWING countless times… Just a thought… David On Sep 3, 2013, at 9:38 AM, Mario Torre neug...@redhat.com wrote: On Tue, 2013-09-03 at 08:34 +0200, Fabrizio Giudici wrote: On Tue, 03 Sep 2013 07:16:06 +0200, Tom Eugelink t...@tbee.org wrote: AFAIK there was never a framework that used final a lot, so time will tell if the choice was right. Swing and the JDK made it this far. But The NetBeans Platform API does use final a lot for the same rationale we're discussing now. I'm suspecting the choice may have been made motivated more from the perspective of the developers of the framework (a few people) and not as much from the users (many people). That's true, but you're misusing the perspective. Many users would only see some minor impact of extending a class, while the few developers would see the accumulation of a huge number of problems because those minor things are multiplied by the large number of users. It's precisely by putting oneself in the perspective of the developers that 'final' makes sense. I've designed quite a few APIs and have extended Swing in a number of very creative ways over the years. While the extensibility comes handy after the 10+ years old API doesn't do anymore the things you would like, you quickly realise it's really part of the problems in the first place, so I agree completely with Fabrizio here. Cheers, Mario
Re: Why is almost everything in the API final
By we I meant the place where I work… (not JWrapper Inc.)! :) David On Sep 3, 2013, at 1:28 PM, David Ray cognitionmiss...@gmail.com wrote: I would strongly recommend leaving the shared JRE install world behind. As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? David On Sep 3, 2013, at 1:23 PM, Richard Bair richard.b...@oracle.com wrote: Wouldn't it be better to allow developers to override methods at their own risk. There's no such thing. When some big customer overrides methods, we have no choice but to support their app for the foreseeable future. Which is why deprecated stuff never could be removed from the JDK as well. And a host of bugs won't be fixed. When the CEO of a customer with a major hardware contract comes knocking -- well, at that time you really wish you had designed the API differently. Yet, those that are willing to take the risks, can do something to keep their business alive. I would strongly recommend leaving the shared JRE install world behind. Richard
Re: Why is almost everything in the API final
When you have a new version of your app to distribute, you would repackage it using the same tool you did before - maybe specifying a new JVM target (if you would like to update the JVM that gets bundled with the app). Then upload your app to the Apple App Store and voila' :) (Ok so there's the extra step of the endless slew of provisioning licensing and packaging hurdles introduced by Apple -- then voila' !!!) :-D David On Sep 3, 2013, at 1:48 PM, Mario Torre neugens.limasoftw...@gmail.com wrote: But this puts the task to update the jre in the hands of the developer, no? This would be very insecure in my opinion then. Cheers, Mario Il giorno 03/set/2013 20:36, Richard Bair richard.b...@oracle.com ha scritto: I would strongly recommend leaving the shared JRE install world behind. As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems? If my business were betting on it, I'd not use a shared install for a couple reasons: - I want to control the *exact* version of the JRE such that my app testing was done against a specific version of the JRE - I have the freedom to modify the JRE as needed for my app - I can deploy as a normal desktop app using normal mechanisms - Related, I don't have to field support requests around what version of Java is installed or not, or Java install problems I can still have auto-update with an app cobundle, so I don't miss out there either. None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system. Richard
Re: Mixing 2D and 3D
And Voila! Webstart fails again! Cannot launch the application… jnlp spec=1.0 xmlns:jfx=http://javafx.com; codebase=http://www.interactivemesh.org/models/webstartjfx/; href=fxTuxCube-0.6_FX3D.jnlp information titleFXTuxCube 0.6/title vendorInteractiveMesh e.K./vendor descriptionFXTuxCube 0.6/description /information security all-permissions/ /security resources j2se version=1.8+/ jar href=fxTuxCube-0.6-ssign.jar size=23 download=eager/ jar href=jimObjModelImporterJFX-0.4-ssign.jar size=3 download=eager/ property name=jnlp.packEnabled value=true/ property name=prism.dirtyopts value=false/ property name=javafx.animation.fullspeed value=true/ /resources application-desc main-class=org.interactivemesh.jfx.sample3d.tuxcube.FXTuxCube/ update check=background/ /jnlp Re: FXTuxCube is a simple JavaFX 3D example with 2D elements drawn on top of a 3D SubScene: http://www.interactivemesh.org/models/jfx3dtuxcube.html Just letting you know (as if you didn't already). I'm running a iMac 3.4 ghz Intel core i7, with Java SE build 1.7.0_21-b12 David On Jul 23, 2013, at 6:45 AM, August Lammersdorf, InteractiveMesh s...@interactivemesh.com wrote: Vidio games usually draw the player's 2D UI elements in a second step on top of the perspective 3D scene in the parallel/orthographic projection mode (overlay or head-up display - HUD). This approach is already widest supported by JavaFX even with perspective 3D transforms. Using a StackPane or a self-written layered pane the user interface can be rendered onto the 3D SubScene and can be designed, updated and animated with: - layout panes : javafx.scene.layout.* - UI controls : subclasses of javafx.scene.control.* - two-dimensional shapes : javafx.scene.effect.shape* - graphical effects : javafx.scene.effect.* - images : javafx.scene.image.* - shapes and background filler : javafx.scene.paint.* - transformations : javafx.scene.transform - animations : javafx.animation Is there any other 3D API or game engine based on C++ or Java which can beat this scenario? FXTuxCube is a simple JavaFX 3D example with 2D elements drawn on top of a 3D SubScene: http://www.interactivemesh.org/models/jfx3dtuxcube.html Worth reading: User interface design in games http://www.thewanderlust.net/blog/2010/03/29/user-interface-design-in-video-games/ August Am Sonntag, den 21.07.2013, 16:07 +0200 schrieb Herve Girod herve.gi...@gmail.com: What is the use case for rendering 2D pixel-coordinates-based shapes (or even controls) within a 3D scene consisting of meshes constructed on 3D coordinates of arbitrary unit? In my field of work (avionics displays),we might have a lot of use cases for that. However, you also have that in video games, where they like to render 2D interactive panels in a 3D perspective in the game world. Hervé
Re: JavaFX 8 Progress
I don't want to open up the webstart can of worms here, but we have multiple issues surrounding recognition and validity of signed jars when using certain VMARGS in combination with OSGi style deployment. We finally settled on JWrapper due to WebStarts apparent brittleness - but as you say, this is neither here nor there as far as JavaFX is concerned… Anyway, thanks for getting back to us on the deployment tools organization… David On Jul 18, 2013, at 9:22 AM, Joe McGlynn joe.mcgl...@oracle.com wrote: No, the deployment team works on these, not the FX team. It's the same bits for FX and Swing/AWT when running browser-deployed apps (which includes applets and web start). Deployment, FX and Swing are all part of the Java client org. There are a number of bug fixed being worked in this area, as well as new requirements around how to deploy a secure applet or web start app. The deploy code base is currently identical between 7u and JDK 8. If you are working with deploy technologies you should know this area is rapidly changing and I'd strongly advise staying on the latest release (currently 7u40 EA) and following the updates to the docs, especially around best practices for deployment. In short, these are: Buy a code signing certificate from a recognized CA and sign your app Use the new permissions and codebase JAR manifest attributes I'd recommend avoiding the use of mixed code if at all possible as that results in additional warning prompts to the end user and additional runtime risks. I'd also recommend testing your app with the security slider at the Very High level with every update of the JRE. Typically new restrictions are introduced first at Very High, and then propagated down into High and ultimately Medium over time. If there are problems using deployment with FX, of course report the issue and the team will investigate. I'm aware of one problem that causes some FX web start apps not to work with the latest release. It's being investigated right now. On Jul 18, 2013, at 6:40 AM, Daniel Zwolenski zon...@gmail.com wrote: Sure, but no one other than the JFX team are (or will be) working on these right? They are effectively desktop technologies and no other team has any interest in them I'm guessing? I'd assume if they're not on the JFX roadmap, they're not on the Java roadmap? On Thu, Jul 18, 2013 at 9:48 PM, Artem Ananiev artem.anan...@oracle.comwrote: On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/** projects/jdk8/milestoneshttp://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/**projects/jdk8/milestones#Zero_** Bug_Bouncehttp://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
Re: JavaFX 8 Progress
JWrapper (no plug - I don't work for them or own stock) solves all of this - you have to bundle the jvm but it's small and the installation is hitch-less… Oracle should buy them out - seriously! David On Jul 18, 2013, at 4:09 PM, ozem...@ozemail.com.au wrote: +1 The various applet and Web Start deployment options are severly damaging the entire Java brand. and should be discontinued ASAP. Even before the recent security issues raised their ugly heads there have been several issues with either launching Java applications from within a web page or running them as applets and the user experience has been dismal to say the least. The main reason why Java applets had such a short-lived period of popularity was because Flash came along. Flash applets started significantly faster, didn't pop-up any security warnings and almost always just worked. The exact opposite was true of applets and, sadly, this has only gone further downhill lately. For many years the browser vendors have gone out of their way to make running Java in the browser a very painful experience for the end user. Now we have the situation where most people assume every Java applet is a security threat and avoid them like the plague. Anyway, I do not believe Java, JavaFX or any plugin-based technology has any place in a web browser. This includes Flash and Silverlight. We have HTML5 for that kind of app. Surely it won't be long until all browser vendors make it *impossible* for Java to run inside the browser or simply not support *any* plugins. What's the point of investing any further effort into the Java Plugin? Yes, I know there are legacy apps and applets out there that need to run but Oracle should be focused on getting JavaFX into the modern platforms and their associated app stores. Why not issue an End Of LIfe bulletin that signals the end of the Java Plugin so anyone out there still relying on Java applets can have time to find an alternative. Let's face it, almost *all* the security vulnerabilities exposed in recent months only affect Java in the browser. All the effort Oracle expends on patching these vulnerabilities and tightening up the security model should be spent on advancing JavaFX on mobiles and tablets. -jct - Original Message - From: Daniel Zwolenski zon...@gmail.com To: David Ray cognitionmiss...@gmail.com Cc: mike.ehrenb...@barchart.com Ehrenberg mike.ehrenb...@barchart.com, openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net, JeremyJongsma jer...@barchart.com Sent: Fri, 19 Jul 2013 06:47:46 +1000 Subject: Re: JavaFX 8 Progress Among general complaints and my own disasters with it, I had this guy write to me: http://web-conferencing-central.com The failure of webstart is making him lose customers (they literally are emailing him and telling him it's too hard to install). This is one of the very few commercial, public apps that use desktop-java and webstart (I'd be keen to know about any others - I know of none that use jfx?). From what I understand of the work being carried out, I highly doubt any of the fixes or improvements being worked on are going to help people like this. I love the idea of web deployment but it's failed and getting worse with the complexities now added in your attempts to keep it secure. In my opinion, web deploy should be deprecated or at least placed in minimal 'bandaid' only fixes and all effort should be put into making native bundles actually useful and into adding app store support. On 19/07/2013, at 2:10 AM, David Ray cognitionmiss...@gmail.com wrote: I don't want to open up the webstart can of worms here, but we have multiple issues surrounding recognition and validity of signed jars when using certain VMARGS in combination with OSGi style deployment. We finally settled on JWrapper due to WebStarts apparent brittleness - but as you say, this is neither here nor there as far as JavaFX is concerned… Anyway, thanks for getting back to us on the deployment tools organization… David On Jul 18, 2013, at 9:22 AM, Joe McGlynn joe.mcgl...@oracle.com wrote: No, the deployment team works on these, not the FX team. It's the same bits for FX and Swing/AWT when running browser-deployed apps (which includes applets and web start). Deployment, FX and Swing are all part of the Java client org. There are a number of bug fixed being worked in this area, as well as new requirements around how to deploy a secure applet or web start app. The deploy code base is currently identical between 7u and JDK 8. If you are working with deploy technologies you should know this area is rapidly changing and I'd strongly advise staying on the latest release (currently 7u40 EA) and following the updates to the docs, especially around best practices for deployment. In short, these are: Buy
Re: Mixing 2D and 3D
I'm not a 3D expert but my gut tells me that the two pipelines should remain distinct as you say. I can't imagine the evolution of such different functions converging in such a way where the semantic treatment of the two will coincide in a clean, simple and unconfusing manner. That only seems like it would lead to compromise and the inability to develop both concepts to their full maturity - and what about what you mentioned regarding possible OpenGL exposure from the 3D API ? Would this be possible while still merging 2D and 3D semantics? David On Jul 18, 2013, at 3:58 PM, Richard Bair richard.b...@oracle.com wrote: While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer 2) Draw the magenta circle. Same as with green -- draw into an image with nice AA and rotate and blend 3) Draw the rectangle. Because the depth buffer is turned on, for each pixel of the green magenta circles, we *don't* render any black. Because the AA edge has been touched with some transparency, it was written to the depth buffer, and we will not draw any black there. Hence the dirty fringe! No blending! 4) Draw the blue circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black
Re: Java Deployment (was Re: JavaFX 8 Progress)
So you're saying, once I create my new JavaFX app with all the new beautiful and wondrous JavaFX goodies - I can do what? Sit at home and look at it? :) David On Jul 18, 2013, at 5:02 PM, Daniel Zwolenski zon...@gmail.com wrote: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: Java Deployment (was Re: JavaFX 8 Progress)
A list of JWrapper's features: Oracle, are you ready to buy these guys yet? If you don't, we will… :) Easily deploy Java as native apps (for free) But lets break that down... Easily... To us, this means being able to build for everything, on anything - true cross platform builds. Multiple developers can share one build file, yet everyone can build for every OS. Users can get hold of your app and updates no matter what web server or scripting language you use. You issue a new automatically updated release by overwriting some files on your web server, and if we do our best to ensure your app has a predictable, stable environment. If use a system JRE we even copy it so you aren't exposed when Oracle decides to update it and break API. …deploy Java... To us, this means creating signed, iconified, automatically updating OS-native apps that can pick up a system JRE, download or bundle a heavily compressed one. Since we're replacing applets it also means making your app available on your website by just sharing the files and adding one line of HTML to embed a JavaScript download button. It also means stuff like automatically detecting HTTP proxies from wherever makes the OS has that info (system settings, browser settings) so that you don't have to guess at them yourself or hope that the system JRE is set up to use the right one (if there even is one). …as native apps To us this means it looks and feels like a native app. On Windows this means a signed executable which can elevate as you need. On OSX this means a signed .app file inside a DMG. On Linux this means a native exe inside a double-click extractable tar.
Re: JavaFX 8 Progress
Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
Re: Making Color Final (and Paint too, for all intents and purposes)
+1
David
Sent from my iPhone
On Jul 12, 2013, at 3:15 PM, Richard Bair richard.b...@oracle.com wrote:
I have two different changes I might want to make, both of which are
definitely incompatible for subclasses, but are otherwise source compatible.
public abstract class Paint {
Paint() { } // --- Add this package constructor. Anybody who subclassed
Paint will die
}
public final class Color extends Paint { … } // Added final
Nobody can do anything useful today by subclassing Paint. Each Paint subclass
has hardcoded support in the graphics pipeline. If you were to subclass Paint
with WackyPaint and use it in the scene graph, it would do absolutely nothing
(except maybe explode in the graphics pipeline someplace). Likewise, if you
extend Color with WackyColor, it will only be used as a Color object.
Color however does have non-final methods (blast!) which somebody could
override. Now, they could do nefarious things with it (as far as the graphics
pipeline is concerned), but other than logging when somebody called a method,
there is nothing else they could do by overriding (since Color is immutable),
except for the deriveColor method which could be reimplemented in a
reasonable manner, although the platform will never call your method so it
doesn't do you much good.
Both of these *should* have been final / effectively final when defined in
the first place, and we've made subclassing these classes sufficiently
worthless by other methods (other final methods plus the way the pipeline
works) that nobody should really be broken but such a change. Besides which,
we added a new abstract method in the last release which essentially breaks
any subclasses in a binary manner (they would have to update their code), and
I'm about to do it again while fixing
https://javafx-jira.kenai.com/browse/RT-31565.
Anybody with major heartburn let me know now, 'cause its going down!
Richard
