How did you go with using Maven for your iOS stuff Tobi? Did it work out for
you?
Has anyone else had a chance to get into it? I was hoping for more feedback on
what works and what doesn't. Also hoping to see some open source demo iOS apps
popup to start highlighting what works and what doesn't
Yes Felix, it *has* to be this year…. We do not port our swing based commercial
apps if JavaFX does not run on tablets as well.
Am 30.07.2013 um 21:06 schrieb Felix Bembrick :
> Hi Tobi,
>
> I know how you feel. As much as I am impressed with JavaFX, clearly its
> long-term survival does d
Hi,
Like advertised I've now the first thing to show off. Part of our
nightly e(fx)clipse build we generate a *self-contained* FXML-Compiler
jar which anyone interested can download from [1].
We currently provide an ant-integration (I'm not 100% happy on how I
make sure the appropriate classpath
Depending of security requirements on the deployed code (like in an
application not loading untrusted code), an hammer method can be useful:
relaxing access rights on @FXML-annotated fields and methods to allow
public access.
It would need a preprocessing of application bytecode to change thes
Hi,
If you want to take a look at the sources, they are available at
http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.fxml.compiler.
Code is written in xtend - don't judge the code yet, I simply want
something going.
The process of the conversio
Where is the code base for this converter? Done properly it can also be
written to spit out the generated stubs, as well as output in any language
the user may prefer. A top grade implementation could integrate with
FXMLLoader for a seamless experience ala .bss files.
On Tuesday, July 30, 2013,
Have you decided, how you will make the bridge near the current
FXMLLoader class. Particularly, will it be understandable by Proguard
for better inlining and further reduce bytecode?
Example: if a specific FXML is only loaded in one method of an
application, all the FXMLLoader code can theoret
It will spit out a .java-Class which you run through javac and get
bytecode - for robovm this is going to be completely transparent because
it gets a java-class file.
Tom
On 31.07.13 09:57, Niklas Therning wrote:
> Will this converter be able to precompile embedded JavaScript? That
> would be ver
jfx-dev@openjdk.java.net Mailing
> Subject: Re: JavaFX and iOS - it will remain a dream
>
> I don't think it is a good idea to use fxml on embedded and mobile, we are
> working on a fxml => java converter so you can add it to your build process.
>
> Tom
>
> Von me
Will this converter be able to precompile embedded JavaScript? That would
be very cool. If I remember correctly Rhino can compile JS to bytecode AOT.
RoboVM would then be able to compile that bytecode to machine code.
On Wed, Jul 31, 2013 at 8:28 AM, Tom Schindl wrote:
> I don't think it is a go
3 16:29
To: Niklas Therning
Cc: openjfx-dev@openjdk.java.net Mailing
Subject: Re: JavaFX and iOS - it will remain a dream
I don't think it is a good idea to use fxml on embedded and mobile, we are working
on a fxml => java converter so you can add it to your build process.
Tom
Von meinem i
Mailing
Subject: Re: JavaFX and iOS - it will remain a dream
I don't think it is a good idea to use fxml on embedded and mobile, we are
working on a fxml => java converter so you can add it to your build process.
Tom
Von meinem iPhone gesendet
Am 31.07.2013 um 08:11 schrieb Niklas
I don't think it is a good idea to use fxml on embedded and mobile, we are
working on a fxml => java converter so you can add it to your build process.
Tom
Von meinem iPhone gesendet
Am 31.07.2013 um 08:11 schrieb Niklas Therning :
after many days trying to really build iOS apps with Java
> > > after many days trying to really build iOS apps with JavaFX and RoboVM
> or
> > > Avian I’m very frustrated because of the following things:
> > >
> > > Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know
> the
> > > reason - maybe it’s the rendering model of JavaFX - maybe i
I agree, our customers want and need tablet/mobile solutions to complement
our desktop offering. The current "give it a shot, good luck, let us know
how it goes" approach is not the way to advance JavaFX in the mobile space.
Rick
On Tue, Jul 30, 2013 at 3:06 PM, Felix Bembrick wrote:
> Hi Tobi,
Hi Tobi,
I know how you feel. As much as I am impressed with JavaFX, clearly its
long-term survival does depend on it being viable on mobiles and tablets.
All I can say is don't give up yet. I am certainly not giving up. I
really hope we see something at JavaOne this year that will please us a
16 matches
Mail list logo
