Yes, definitely.
> On Oct 23, 2013, at 11:52 AM, Scott Palmer 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 ideal solution
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 ideal solution, but
could be useful for specific use cases, like a video preview overlay. Would
To do this we need to either solve the auto-layer problem in the NG nodes /
Glass / Quantum, or we need to ask the app developer to use SubScene and put
all the native stuff in a single SubScene, and all lightweight content above
and below it. For the short term, we could use the SubScene approa
>
> 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
>
On Oct 22, 2013, at 9:38 AM, Pedro Duque Vieira
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 should have a control r
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
wrote:
> Rather than arguing this point, the correct answer is to provide both and
> let the application developer c
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 away
>
> 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
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 t
+1 for native keyboard support. Unless you want to emulate the dictation
feature in iOS and all that kind of stuff, you pretty much have to use the
native keyboard.
But I think native widgets in general could be postponed, so long as JNI
could be used to implement settings and the sort of thing t
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 l
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
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 c
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 someon
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-rt (from
whereever this comes from) has been updated (usually every Friday). This
obviously depends on the number of changes required and my available t
>
> 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 should have a control representation. For instance the same
can be said of checkbox,
> 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 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
+1 on this. I don't see why having an exact copy of the look and feel of
the OS has to be mandatory. You can see a lot of apps on ios that use
controls that don't mimic the look and feel of the OS and yet look and feel
great, in fact I would say the best looking apps are the ones that don't
mimic t
> 1. Can you provide me with a detailed summary of where the iOS/Android
> ports are currently?
I got this from Tomas today (with some minor modifications):
*
-Text rendering
Hopefully the last thing remaining to have Android fully opensourced is native
text rendering sup
I would avoid image based CSS files… we should create pure CSS based skins
using pure css styles and SVG paths…
Am 22.10.2013 um 16:33 schrieb Richard Bair :
>> 1) Look and Feel:
>>
>> IMO it’s enough to build „native looking“ css based skins! That could be
>> very quickly without complex tec
> 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
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 h
+1 re: Native L&F. 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 s
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 p
> 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
Thanks so much for all this valuable info Richard!
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?
Are there other prod
> 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.
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 state
30 matches
Mail list logo
