That seems like a very workable model to me.
-- Kevin
On 9/21/2018 12:56 PM, Johan Vos wrote:
Adding to #2: what we try to do with gluon is increasing adoption, allow
free development and usage, while still getting revenues to fund the
development.
All builds created for the latest version of JavaFX are free to use (GPL +
CPE) for private and commercial usage.
With the Gluon JavaFX Enterprise support (see
https://gluonhq.com/javafx-11-release-and-support-plans/), we provide LTS
to companies that don't want to jump to the latest versions with every
release but still require updates.
If you go from JavaFX 11 to 12, 13, 14,... you'll always get a free,
high-quality, supported build. If for some reasons you need to stick with
JavaFX 11 but still want critical updates, you can buy Gluon JavaFX
Enterprise support and you will get builds including critical patches.
This is similar to the Java SE support: if you follow the release cadence
and use the latest and greatest version, you're totally fine. If you don't
want to do that, that's fine. If you want to stay on an old version but
still get regular high-quality updates, you can get commercial support.
- Johan
On Fri, Sep 21, 2018 at 9:43 PM Scott Palmer <swpal...@gmail.com> wrote:
I would focus on bug-free functionality and *performance* over new
features. Layout and CSS issues still seem to have a significant drag on
JavaFX rendering.
Much of the new features I want are somewhat motivated by performance
anyway. E.g. getting native window handles… to handle performance issues
with 3D and video overlays.
I think #2, while cheap, will severely harm JavaFX adoption just from the
added nuisance alone. Is there a precedent where this has worked out?
Regards,
Scott
On Sep 21, 2018, at 12:04 PM, jav...@use.startmail.com wrote:
Two items for us
1) focus on bug-free functionality over new features.
2) require a U.S. $50.00 a year fee per corporate entity for commercial
application usage. This is very reasonable and would finally secure
JavaFX's future as a development platform.
I feel without 2) above we will find ourselves wandering around
cyberspace hoping for a benefactor or the charity of volunteers and their
spare time.
hth.
On Friday, September 21, 2018 at 5:52 AM, John-Val Rose <
johnvalr...@gmail.com> wrote:
That video is typical marketing “smoke and mirrors”.
With no access to the code of either app, it is simply unfair and
disingenuous to claim a performance advantage.
I am certain I could post an almost identical comparison video where
the results would be the complete opposite.
Yeah, good programmers can write slow code (especially if you have a
motive)...
On 21 Sep 2018, at 19:29, Johan Vos <johan....@gluonhq.com> wrote:
We can't defeat QT in performance, but we can defeat it at
applicability
and just don't get too far behind QT in performance. (bad example
https://www.youtube.com/watch?v=Kh6K-yEp_JY)
That video demonstrates the creator has absolutely no development
skills in
Java, or he intentionally misleads the viewer. I leave it to the
reader to
judge what would be worst.
I am not going to make performance statements without numbers, but my
first
observations using JavaFX 11 with the Bellsoft Liberica VM are very
encouraging (see
https://gluonhq.com/javafx-11-early-access-on-embedded/)
- Johan
