Yes, definitely.
On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote:
This is starting to sound like it may also partially address the issue in the
desktop space of supplying a native surface (the heavyweight) to draw in that
is part of the scene graph. It may not be the
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
+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
Another approach which would be a *lot* easier to implement would be to add a
Layer public API that would allow the app developer to specify what layers
there are, and where they are (this has a lot of other benefits related to
performance on embedded and mobile devices). Then, don't solve the
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.
Generally this should be very easy for somebody to do. There is a ui kit
already out there that designers use for mocking up UI designs for
I would avoid image based CSS files… we should create pure CSS based skins
using pure css styles and SVG paths…
That would definitely be (a lot) more work, but if you're going to be scaling
up the controls you will appreciate them being normal background fills paths.
Richard
javafx, like for instance: a toggle button (a control that looks like a
flip switch)
These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons).
We've done this for example for DukePad.
, comboboxes where you change the value through a wheel, etc..
Yes, need this kind of
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
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
Well I guess I am in the once bitten, a thousand times shy category after
my experiences with Swing over the years.
As I have mentioned in my blog posts, I believe the native look-and-feels
for Swing were a monumental mistake. The first version of the Swing
Windows look-and-feel for example left
Yeah, the Swing file dialog is quite embarrassing...
I accept that you can ship commercial software using the Swing Windows look
and feel but only to certain types of customers and certain market niches.
I do not believe you could compete with native applications in a more
generic market sector
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
Rather than arguing this point, the correct answer is to provide both
and let the application developer choose.
Do you guys know how old this argument is? Hint: It predates Java.
Steve
On 2013-10-22 6:17 PM, Pedro Duque Vieira wrote:
Even the most fab skins or CSS is not going to get us
Yes, having viable implementations of both options would be ideal.
How long till Oracle and/or the community gets to that point? ;-)
On 23 October 2013 10:06, Stephen F Northover
steve.x.northo...@oracle.comwrote:
Rather than arguing this point, the correct answer is to provide both and
let
On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com
wrote:
These have are just styled CheckBoxes (or Toggle buttons, or Radio Buttons).
We've done this for example for DukePad.
Yes that's right but I think that as it is used so much on Android, ios and
windows 8 it
This is something worth thinking about. I noticed the fonts weren't the
right size, implying that the port on iOS isn't picking up the best font
size, and all the UI controls are sized based on the font, so in theory
this might be sufficient. But it is true a spin-off with bigger insets
Hi Richard,
Undoubtedly you are aware of the buzz and confusion regarding possible
porting of JavaFX to iOS and Android and in an effort to calm the masses
and give us all a little hope, would you be kind enough to provide
definitive answers to the following questions?
1. Can you provide me with
Hi Felix,
I think you can just forget any official statement from Oracle on this.
It's not their way of working. And there appears to be some legal issues
that made Oracle cancel the javafx sessions on ios and android at javaone.
The javafx team is indeed working on this however no official
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.
Personally I feel we *have* to go with the layering approach as I don't
believe look-and-feel emulation will ever give a true native experience (as
outlined in my 6 Degrees post).
Has *any* work been done on this layering?
No there hasn't been.
Are there other products on iOS for
20 matches
Mail list logo
