Part of that 11+ minutes of the macOS build on GitHub Actions (which
starts from a clean machine) is downloading and installing the JDK and
other tools (gradle, etc), and cloning the repo. Also, incremental
builds are much faster after the first one. So even if you do a full
build once, subsequ
On 2/26/21 6:56 AM, Rob Nikander wrote:
I wonder if I can get a dev setup with a quick edit-compile-run cycle, or if
the compile step takes a long time.
The builds for macOS are taking just over 11 minutes on GitHub.
To speed that up, I do my development in a project with only the JavaFX
Gra
On Fri, 26 Feb 2021 13:58:01 GMT, Johan Vos wrote:
> What is the expected behavior?
I think that's why I never raised the issue. I let the bug train me to avoid
it! For better or for worse, I think the only answer to your question is
whatever Android and iOS do. After playing around with the J
On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote:
> Issue: Initial layout delay was removed and layout() is called from
> layoutTimer instead of WebPage::prePaint().
>
> Fix: Re-introduce the initial layout delay.
This pull request has now been integrated.
Changeset: 8ad18c32
Author:Ar
On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote:
> Issue: Initial layout delay was removed and layout() is called from
> layoutTimer instead of WebPage::prePaint().
>
> Fix: Re-introduce the initial layout delay.
Tested on Linux and Windows, Looks good to me.
-
Marked as revi
> On Feb 25, 2021, at 3:26 PM, John Neffenger wrote:
>
> Those earlier font fixes taught me that if you can write and debug Java
> application code, you can write and debug code in JavaFX and the JDK, too. So
> you might consider trying to fix it yourself. When successful, it's like
> gain
On Sat, 20 Feb 2021 19:43:01 GMT, John Neffenger
wrote:
>>> The expected result isn't explicit in the bug report, so just to confirm,
>>> there should be no button action events received at all when you touch any
>>> of the buttons only for the purpose of scrolling the entire pane, right?
>>