Re: Building on windows
If commenting out those two lines made a difference, then there is
likely something wrong with your environment. WINDOWS_VS_VER should only
be "100" with Visual Studio 2010. If you have VS 2017 installed in the
right place (or are pointing to it), then WINDOWS_VS_VER should be 150.
You might want to make sure that it isn't something else (e.g., a stale
build or a running gradle daemon). Running "gradle --stop" and then "rm
-rf build" often helps resolve these sort of strange problems.
-- Kevin
On 8/5/2019 5:46 PM, Thiago Milczarek Sayao wrote:
win.gradle line 155:
//if (WINDOWS_VS_VER != "100") {
winSdkBinDir += "/$CPU_BITS"
//}
I have Windows 10, so commenting the if resolved the problem. Wonder why it's
there...
De: Nir Lisker
Enviado: segunda-feira, 5 de agosto de 2019 07:44
Para: Thiago Milczarek Sayao
Cc: openjfx-dev@openjdk.java.net
Assunto: Re: Building on windows
The double slash in "Bin//rc.exe" is weird, there should be a folder there.
If it helps, build.gradle has this comment on line 40:
The genVSproperties.bat doesn't find the directory where RC.exe lives. So it is
hard coded. Might be a problem.
I never hit this problem.
- Nir
On Mon, Aug 5, 2019 at 4:26 AM Thiago Milczarek Sayao
mailto:thiago.sa...@clamed.com.br>> wrote:
Managed to get past the error by updating the source tree.
Now I'm getting this:
FAIL: cannot find RC: C:/Program Files (x86)/Windows Kits/10/Bin//rc.exe
Seems to be failing to get CPU architecture.
Mine is x64 (AMD Ryzen).
Chocolatey gives me the same error.
Cheers.
De: openjfx-dev
mailto:openjfx-dev-boun...@openjdk.java.net>> em nome
de Thiago Milczarek Sayao mailto:thiago.sa...@clamed.com.br>>
Enviado: sábado, 3 de agosto de 2019 19:41
Para: openjfx-dev@openjdk.java.net
mailto:openjfx-dev@openjdk.java.net>>
Assunto: Building on windows
Hi,
I have followed the instructions on:
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Windows
When running ./gradlew.bat on cygwin I get:
FAIL: WINSDK_DIR not defined
My version is 14.16.27012.
Thanks.
OpenJFX 13 is in Rampdown Phase Two (RDP2)
To: OpenJFX Developers As a reminder, OpenJFX 13 is now in Rampdown Phase Two RDP2. [1] During RDP2, all bug fixes (except for docs and test fixes), and all enhancements will need explicit approval to go in to openjfx/13-dev. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. We will use the same rules for RDP2 that the JDK uses [2], with three modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 13 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx13-fix-request", "openjfx13-fix-yes", "openjfx13-fix-no" and "openjfx13-fix-nmi", "openjfx13-enhancement-request", "openjfx13-enhancement-yes", "openjfx13-enhancement-no" and "openjfx13-enhancement-nmi" as corresponding labels. 3. Some important P3 bugs might be considered during RDP2, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P3 bugs should be moved to openjfx14 at this point. I expect few, if any, P3 bugs to be approved. Note that if a fix is approved to push to 13-dev (with the appropriate approval label added by a lead), then you should *not* also push it to jfx-dev -- we will auto-sync from 13-dev --> jfx-dev for the duration of the openjfx13 release. Now that we are in RDP2, the goal is to stabilize what is there, with priority on fixing bugs that are new in openjfx13. We need to be extremely careful about including anything that introduces risk. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-March/023180.html [2] http://openjdk.java.net/jeps/3
Concatenating transforms to scale positions but not objects
Hello! I realize the subject is somewhat convoluted. I'm putting together something that bears a passing resemblance to a DAW such as Ardour: https://rekkerd.org/img/201303/ardour3.png Mine doesn't look like that, but the principle is basically the same: I have regions (the blocks containing waveform images above) placed on a timeline. The timeline is scalable on both axes independently; scaling the timeline vertically gives you more space to work with when adjusting automation curves (visible in the "Fader" lane above), and scaling/translating the timeline horizontally allows you to move forwards and backwards in time, and to focus more clearly on a particular region of time. For the sake of simplicity, let's act as if I have just a single timeline instead of the multiple stacked timelines shown in that image. My application expresses the positions of regions on the timeline in terms of "ticks" (small units of time). For the (obviously JavaFX-based) GUI, I'd like to be able to specify a single transform on the timeline view such that I can specify the coordinates of region nodes in terms of ticks and the transform will determine their onscreen pixel positions appropriately. This isn't too hard to do; I can specify an x-axis scale such that 1 pixel = 128 ticks, and I can then specify an x-axis translation in terms of ticks that will be scaled appropriately for the screen. The problem then, however, is that the the nodes within region nodes are also scaled up hugely; if I try to put labels in the regions, the labels will appear 128 times larger than they normally would. :) I want to specify the *positions* of regions in one coordinate system, but work in ordinary "scene pixels" inside those regions. I can't quite work out how to express the transforms I need to JavaFX. I feel like what I need to do is, for each region node, add *another* node inside the node that fills the region entirely, and specify an inverse of the transform applied to the parent region node... If that makes any sense. Is there a sensible way to do what I'm trying to do? [I've developed a 3D renderer, so I'm familiar with how transforms are concatenated using matrices. I don't have an intuitive understanding of how transforms are applied inside JavaFX, and there doesn't appear to be much documentation on this.] -- Mark Raynsford | http://www.io7m.com
RFR: JDK-8228766: Platform.startup() deadlock on mac
Hi, Please review PR #543 [1] which fixes issue #542 [2] or JDK-8228766 [3]. Thanks, - Johan [1] https://github.com/javafxports/openjdk-jfx/pull/543 [2] https://github.com/javafxports/openjdk-jfx/issues/542 [3] https://bugs.openjdk.java.net/browse/JDK-8228766
