error while building JFX 8udev for iOS (2)
@Oracle, can you help me?
> Anfang der weitergeleiteten Nachricht:
>
> Von: Tobias Bley
> Betreff: error while building JFX 8udev for iOS
> Datum: 15. Juli 2014 13:52:11 MESZ
> An: "openjfx-dev@openjdk.java.net Mailing"
>
> Hi folks,
>
> when I try to build JFX for iOS using „gradle sdk…“ i’m getting the following
> errors - is it a known issue?
>
> Best regards,
> Tobi
>
>
>
> :graphics:ccIosPrismES2Arm
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:67:34:
> warning: implicit declaration of function 'createContext' is invalid in C99
> [-Wimplicit-function-declaration]
> context = (jlong) (intptr_t) createContext((void *) (intptr_t)
> nativeShareCtxHandle,
> ^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:76:14:
> warning: implicit declaration of function 'makeCurrentContext' is invalid in
> C99 [-Wimplicit-function-declaration]
> result = makeCurrentContext((void *) (intptr_t) context);
> ^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:78:9:
> warning: implicit declaration of function 'printAndReleaseResources' is
> invalid in C99 [-Wimplicit-function-declaration]
> printAndReleaseResources(0, context,
> ^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:137:13:
> warning: implicit declaration of function
> 'getProcAddress' is invalid in C99 [-Wimplicit-function-declaration]
> getProcAddress("glActiveTexture");
> ^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:239:5:
> warning: implicit declaration of function 'setSwapInterval' is invalid in
> C99 [-Wimplicit-function-declaration]
> setSwapInterval((void *) jlong_to_ptr(ctxInfo->context), 0);
> ^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:59:22:
> warning:unused variable 'pfInfo' [-Wunused-variable]
> PixelFormatInfo* pfInfo = (PixelFormatInfo* )jlong_to_ptr(nativePFInfo);
> ^
> 6 warnings generated.
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLDrawable.c:108:5:
> warning: implicit declaration of function 'flushBuffer' is invalid in C99
> [-Wimplicit-function-declaration]
> flushBuffer((void *) (intptr_t) ctxInfo->context);
> ^
> 1 warning generated.
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:13:
> warning: format specifies type 'unsigned int' but the argument has type
> 'void *' [-Wformat]
> shareContext, view, pixelFormat, viewNotReady);
> ^~~~
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:27:
> warning: format specifies type 'unsigned int' but the argument has type
> 'void *' [-Wformat]
> shareContext, view, pixelFormat, viewNotReady);
> ^~~~
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:70:
> warning: flag ' ' results in undefined behavior with 'n' conversion
> specifier [-Wformat]
> fprintf(stderr, "IOSWindowSystemInterface : share %x view %x pf %
> notready %\n",
> ~^~
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:33:
> warning: format specifies type 'int *' but the argument has type 'void *'
> [-Wformat]
> shareContext, view, pixelFormat, viewNotReady);
> ^~~
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:81:
> warning:invalid conversion specifier '
> ' [-Wformat-invalid-specifier]
> fprintf(stderr, "IOSWindowSystemInterface : share %x view %x pf %
> notready %\n",
>
> ~^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:60:12:
> warning: incompatible integer to pointer conversion returning 'jlong' (aka
> 'long long') from a function with result type 'void *' [-Wint-conversion]
> return ptr_to_jlong(ctx);
>^
> /Applications/Developer/Java/open-jfx-graphics-8u-dev2
hg: openjfx/8u-dev/rt: RT-38076
Changeset: 86ffa7810b12 Author:Martin Sladecek Date: 2014-07-29 15:13 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/86ffa7810b12 RT-38076 Map- and SetExpression invalidation listeners cause eventual NPEs when removing themselves ! modules/base/src/main/java/com/sun/javafx/binding/MapExpressionHelper.java ! modules/base/src/main/java/com/sun/javafx/binding/SetExpressionHelper.java ! modules/base/src/test/java/javafx/collections/MockMapObserver.java ! modules/base/src/test/java/javafx/collections/MockSetObserver.java ! modules/base/src/test/java/javafx/collections/ObservableMapTest.java ! modules/base/src/test/java/javafx/collections/ObservableSetTest.java
Re: Skin layoutChildren: when to get bounds of child nodes?
Richard,
Is there a sequence diagram (or similar) where the layout process is described
in detail?
It’s hard to in text get a clear and precise view on how the layout process in
the Node hierarchy is happening.
The sequence diagram would be good to have as a constraint for building layout
panes. Otherwise its easy to time things incorrectly with strange layout
artefacts as a result.
It’s especially important for devs to know which methods are called for the
pre-layout (size measuring) phase and them for the actual layout phase.
Cheers,
Mikael
On 28 Jul 2014, at 07:38, Martin Sladecek wrote:
> The super.layoutChildren should size every child of the control (which is
> VBox), but not child's children. The control must finish the layout before
> children can do theirs. If you need to do layout on some child before that,
> you can call .layout() on it. It will do it's layout using it's current size.
> You should have all the bounds correct after that call.
>
> But that would not work in your case anyway. You have both childs in a HBox,
> which takes care of resizing the children. This means you need to layout the
> HBox to get children size and in order to do that, you need HBox to be at
> it's final size, which will happen during the VBox layout. So your steps
> would be:
> 1) super.layoutChildren() - VBox is resized to Controls content size
> 2) now the VBox is resized, you can call vbox.layout()
> 3) now HBox is resized, so call hbox.layout()
> 4) children are resized. They have correct layout bounds now. But in order to
> get correct boundsInParent (but maybe you really need layout bounds?), you
> need to call .layout() on children too.
>
> Even if you do all these steps, calling setPrefWidth() on child2 marks the
> whole tree dirty again. Because HBox needs to resize child2 using it's new
> PrefWidth. This also means, HBox prefwidth will be different, so it's parent
> (VBox) must do the same. Ditto with the control. Also, the HBox (VBox,
> control) may not have enough size to resize child2 to it's pref width, so
> child1 might be shrinked as a result, which breaks your invariant. You are
> basically changing the input for HBox's layout (child2.pref size) based on
> it's output (child1 size), which makes this a loop.
>
> So in order to really make this work, you need to manage the child nodes
> directly and compute your layout by yourself. This can be done either by
> using your own subclass of Pane and overriding it's layoutChildren. Or if you
> want to do everything in Skin's layoutChildren, you can make the children
> unmanaged, but then it doesn't really matter where they are in the
> scenegraph, HBox won't be managing them.
>
> Hope this helps!
>
> -Martin
>
>
> On 25.7.2014 18:56, Richard Bair wrote:
>> Hmmm. The first question I have is whether boundsInParent is really what you
>> want to use, vs. layout bounds. But assuming it is what you want, why are
>> the bounds zero? This is during the layout pass, which is the right place to
>> be doing what you’re doing. The super layoutChildren call will size
>> everything based on the contentX, contentY, contentWidth, contentHeight
>> (http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/4b8d06211312/modules/controls/src/main/java/javafx/scene/control/SkinBase.java).
>> Is it possible that the parent itself is size 0? boundsInParent should
>> always be invalidated automatically whenever the width/height/transforms/etc
>> changes. If not that is definitely a bug (that you can write a simple test
>> case for to prove).
>>
>> But my first guess is maybe the parent is size 0 as well, due to something
>> else (maybe the pref size of the control is 0 to start with or something…)
>>
>> Richard
>>
>> On Jul 24, 2014, at 3:34 AM, Werner Lehmann
>> wrote:
>>
>>> Hi,
>>>
>>> inside a control skin I have the following code pattern:
>>>
>>> protected void layoutChildren(...)
>>> {
>>>super.layoutChildren(...);
>>>
>>>Node child1 = ...
>>>Bounds bip = child1.getBoundsInParent();
>>>
>>>if (!animating) {
>>> Node child2 = ...
>>> child2.setTranslateX(bip.getMinX();
>>> child2.setPrefWidth(bip.getWidth());
>>>}
>>> }
>>>
>>> The skin scene graph looks roughly like this:
>>>
>>> VBox
>>> HBox { ..., child1, ...}
>>> child2
>>> ...
>>>
>>> Everything is layouted just fine but I want to adjust child2.translateX and
>>> prefWidth based child1 bounds. This does not work initially because
>>> boundsInParent returns zero components leading to incorrect initial display
>>> of the control.
>>>
>>> Seems as if boundsInParent is not yet updated. I guess I could use a
>>> binding for that but it would conflict with an animation I also have on
>>> translateX and prefWidth.
>>>
>>> Maybe there is a better time to make those adjustments on child2?
>>>
>>> Rgds
>>> Werner
>
Re: Skin layoutChildren: when to get bounds of child nodes?
I created some simple diagrams for this blog post:
https://blogs.oracle.com/jfxprg/entry/the_peculiarities_of_javafx_layout
-Martin
On 07/29/2014 03:15 PM, Mikael Grev wrote:
Richard,
Is there a sequence diagram (or similar) where the layout process is described
in detail?
It’s hard to in text get a clear and precise view on how the layout process in
the Node hierarchy is happening.
The sequence diagram would be good to have as a constraint for building layout
panes. Otherwise its easy to time things incorrectly with strange layout
artefacts as a result.
It’s especially important for devs to know which methods are called for the
pre-layout (size measuring) phase and them for the actual layout phase.
Cheers,
Mikael
On 28 Jul 2014, at 07:38, Martin Sladecek wrote:
The super.layoutChildren should size every child of the control (which is
VBox), but not child's children. The control must finish the layout before
children can do theirs. If you need to do layout on some child before that, you
can call .layout() on it. It will do it's layout using it's current size. You
should have all the bounds correct after that call.
But that would not work in your case anyway. You have both childs in a HBox,
which takes care of resizing the children. This means you need to layout the
HBox to get children size and in order to do that, you need HBox to be at it's
final size, which will happen during the VBox layout. So your steps would be:
1) super.layoutChildren() - VBox is resized to Controls content size
2) now the VBox is resized, you can call vbox.layout()
3) now HBox is resized, so call hbox.layout()
4) children are resized. They have correct layout bounds now. But in order to
get correct boundsInParent (but maybe you really need layout bounds?), you need
to call .layout() on children too.
Even if you do all these steps, calling setPrefWidth() on child2 marks the
whole tree dirty again. Because HBox needs to resize child2 using it's new
PrefWidth. This also means, HBox prefwidth will be different, so it's parent
(VBox) must do the same. Ditto with the control. Also, the HBox (VBox, control)
may not have enough size to resize child2 to it's pref width, so child1 might
be shrinked as a result, which breaks your invariant. You are basically
changing the input for HBox's layout (child2.pref size) based on it's output
(child1 size), which makes this a loop.
So in order to really make this work, you need to manage the child nodes
directly and compute your layout by yourself. This can be done either by using
your own subclass of Pane and overriding it's layoutChildren. Or if you want to
do everything in Skin's layoutChildren, you can make the children unmanaged,
but then it doesn't really matter where they are in the scenegraph, HBox won't
be managing them.
Hope this helps!
-Martin
On 25.7.2014 18:56, Richard Bair wrote:
Hmmm. The first question I have is whether boundsInParent is really what you
want to use, vs. layout bounds. But assuming it is what you want, why are the
bounds zero? This is during the layout pass, which is the right place to be
doing what you’re doing. The super layoutChildren call will size everything
based on the contentX, contentY, contentWidth, contentHeight
(http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/4b8d06211312/modules/controls/src/main/java/javafx/scene/control/SkinBase.java).
Is it possible that the parent itself is size 0? boundsInParent should always
be invalidated automatically whenever the width/height/transforms/etc changes.
If not that is definitely a bug (that you can write a simple test case for to
prove).
But my first guess is maybe the parent is size 0 as well, due to something else
(maybe the pref size of the control is 0 to start with or something…)
Richard
On Jul 24, 2014, at 3:34 AM, Werner Lehmann
wrote:
Hi,
inside a control skin I have the following code pattern:
protected void layoutChildren(...)
{
super.layoutChildren(...);
Node child1 = ...
Bounds bip = child1.getBoundsInParent();
if (!animating) {
Node child2 = ...
child2.setTranslateX(bip.getMinX();
child2.setPrefWidth(bip.getWidth());
}
}
The skin scene graph looks roughly like this:
VBox
HBox { ..., child1, ...}
child2
...
Everything is layouted just fine but I want to adjust child2.translateX and
prefWidth based child1 bounds. This does not work initially because
boundsInParent returns zero components leading to incorrect initial display of
the control.
Seems as if boundsInParent is not yet updated. I guess I could use a binding
for that but it would conflict with an animation I also have on translateX and
prefWidth.
Maybe there is a better time to make those adjustments on child2?
Rgds
Werner
Re: JavaFX embedded (jre 8u6): touch problem (malformed multi touch event)
On Mon, Jul 28, 2014 at 12:38 AM, Daniel Blaukopf wrote: > We are in the process of moving this application into the openjfx repository. > > On Jul 27, 2014, at 1:03 PM, Seeon Birger wrote: > >> You can use this one which is more suitable for testing multi-touch: >> rt-closed/toys/HelloWorld/src/helloworld/HelloMultitouch.java >> >> Also note that if using Monocle you'll have to apply the patch referenced in >> this JIRA: >> RT-37950 - Wrong touch coordinates for a window not at the origin (0,0) >> >> Thanks Seeon for pointing out this one. This may be a potential reason why the "pop up" window (extra layout) is not detecting touch. FYI: this is not on (0,0) co-ordinates. Also, Daniel (in a separate context) pointed out that I have not included freetype & pango in my openjfx cross-build which may be a reason for application failure. So I'm looking into that one. >> >> >> >> Daniel, >> >> Do you have any other suggestions for apps that we know handle multitouch >> correctly that Prasant could use to determine if his multitouch problem is >> in the platform or in his app? >> >> Thanks, >> >> Lisa >> On 7/25/2014 11:42 AM, Lisa Selle wrote: >>> rt//apps/toys/Hello/ has HelloGestures which uses multitouch gestures. >>> I'm not aware of any others, but maybe someone else on the list has >>> some input there? I will inquire internally also. >>> >>> Thanks, >>> >>> Lisa Thanks Lisa, for pointing that out. The "HelloGestures" application worked like a charm!! This is exactly what I needed for testing my multi-touch. So I guess monocle multi-touch works for me! I will now check my cross build. >>> On 7/25/2014 11:20 AM, Prasant J wrote: Hi Lisa, Can you please point out to me a javafx application that can help me test my multi touch? I want to rule out my application out of my multi touch test, so a standard multi touch test will be of help to me. Regards, Prasant Thanks Daniel, for pointing out that I forgot to "reply-all".. Regards, Prasant
Re: JavaFX embedded (jre 8u6): touch problem (malformed multi touch event)
I'm glad to hear you are making progress. I am in the process of open source HelloMultiTouch as described below which can serve as an additional test once you get past other potential issues. Thanks, Lisa On 7/29/2014 9:19 AM, Prasant J wrote: On Mon, Jul 28, 2014 at 12:38 AM, Daniel Blaukopf wrote: We are in the process of moving this application into the openjfx repository. On Jul 27, 2014, at 1:03 PM, Seeon Birger wrote: You can use this one which is more suitable for testing multi-touch: rt-closed/toys/HelloWorld/src/helloworld/HelloMultitouch.java Also note that if using Monocle you'll have to apply the patch referenced in this JIRA: RT-37950 - Wrong touch coordinates for a window not at the origin (0,0) Thanks Seeon for pointing out this one. This may be a potential reason why the "pop up" window (extra layout) is not detecting touch. FYI: this is not on (0,0) co-ordinates. Also, Daniel (in a separate context) pointed out that I have not included freetype & pango in my openjfx cross-build which may be a reason for application failure. So I'm looking into that one. Daniel, Do you have any other suggestions for apps that we know handle multitouch correctly that Prasant could use to determine if his multitouch problem is in the platform or in his app? Thanks, Lisa On 7/25/2014 11:42 AM, Lisa Selle wrote: rt//apps/toys/Hello/ has HelloGestures which uses multitouch gestures. I'm not aware of any others, but maybe someone else on the list has some input there? I will inquire internally also. Thanks, Lisa Thanks Lisa, for pointing that out. The "HelloGestures" application worked like a charm!! This is exactly what I needed for testing my multi-touch. So I guess monocle multi-touch works for me! I will now check my cross build. On 7/25/2014 11:20 AM, Prasant J wrote: Hi Lisa, Can you please point out to me a javafx application that can help me test my multi touch? I want to rule out my application out of my multi touch test, so a standard multi touch test will be of help to me. Regards, Prasant Thanks Daniel, for pointing out that I forgot to "reply-all".. Regards, Prasant
[8u40] Review request : RT-37686 : [Monocle] Robot screen/pixel capture is broken
Daniel, Please review the fix for : https://javafx-jira.kenai.com/browse/RT-37686 Details are in the Jira. Thanks, Rafi
Re: error while building JFX 8udev for iOS (2)
Hi Tobias,
We are not building iOS regularly and it is quite possible that the
build is broken. Please enter a JIRA and we will look into fixing the
build.
Steve
On 2014-07-29, 8:51 AM, Tobias Bley wrote:
@Oracle, can you help me?
Anfang der weitergeleiteten Nachricht:
Von: Tobias Bley
Betreff: error while building JFX 8udev for iOS
Datum: 15. Juli 2014 13:52:11 MESZ
An: "openjfx-dev@openjdk.java.net Mailing"
Hi folks,
when I try to build JFX for iOS using „gradle sdk…“ i’m getting the following
errors - is it a known issue?
Best regards,
Tobi
:graphics:ccIosPrismES2Arm
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:67:34:
warning: implicit declaration of function 'createContext' is invalid in C99
[-Wimplicit-function-declaration]
context = (jlong) (intptr_t) createContext((void *) (intptr_t)
nativeShareCtxHandle,
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:76:14:
warning: implicit declaration of function 'makeCurrentContext' is invalid in
C99 [-Wimplicit-function-declaration]
result = makeCurrentContext((void *) (intptr_t) context);
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:78:9:
warning: implicit declaration of function 'printAndReleaseResources' is
invalid in C99 [-Wimplicit-function-declaration]
printAndReleaseResources(0, context,
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:137:13:
warning: implicit declaration of function
'getProcAddress' is invalid in C99 [-Wimplicit-function-declaration]
getProcAddress("glActiveTexture");
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:239:5:
warning: implicit declaration of function 'setSwapInterval' is invalid in C99
[-Wimplicit-function-declaration]
setSwapInterval((void *) jlong_to_ptr(ctxInfo->context), 0);
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:59:22:
warning:unused variable 'pfInfo' [-Wunused-variable]
PixelFormatInfo* pfInfo = (PixelFormatInfo* )jlong_to_ptr(nativePFInfo);
^
6 warnings generated.
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLDrawable.c:108:5:
warning: implicit declaration of function 'flushBuffer' is invalid in C99
[-Wimplicit-function-declaration]
flushBuffer((void *) (intptr_t) ctxInfo->context);
^
1 warning generated.
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:13:
warning: format specifies type 'unsigned int' but the argument has type 'void
*' [-Wformat]
shareContext, view, pixelFormat, viewNotReady);
^~~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:27:
warning: format specifies type 'unsigned int' but the argument has type 'void
*' [-Wformat]
shareContext, view, pixelFormat, viewNotReady);
^~~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:70:
warning: flag ' ' results in undefined behavior with 'n' conversion specifier
[-Wformat]
fprintf(stderr, "IOSWindowSystemInterface : share %x view %x pf % notready
%\n",
~^~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:33:
warning: format specifies type 'int *' but the argument has type 'void *'
[-Wformat]
shareContext, view, pixelFormat, viewNotReady);
^~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:81:
warning:invalid conversion specifier '
' [-Wformat-invalid-specifier]
fprintf(stderr, "IOSWindowSystemInterface : share %x view %x pf % notready
%\n",
~^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:60:12:
warning: incompatible integer to pointer conversion returning 'jlong' (aka
'long long') from a function with result type 'void *' [-Wint-conversion]
return ptr_to_jlong(ctx);
^
Re: error while building JFX 8udev for iOS (2)
Belay that. This works for me in 8u-dev:
gradle -PCOMPILE_TARGETS=ios -PUSE_LIPO=true -PIOS_VERSION=7.1
As far as I know, RoboVM does not support lambdas so the result will not
run.
Steve
On 2014-07-29, 8:51 AM, Tobias Bley wrote:
@Oracle, can you help me?
Anfang der weitergeleiteten Nachricht:
Von: Tobias Bley
Betreff: error while building JFX 8udev for iOS
Datum: 15. Juli 2014 13:52:11 MESZ
An: "openjfx-dev@openjdk.java.net Mailing"
Hi folks,
when I try to build JFX for iOS using „gradle sdk…“ i’m getting the following
errors - is it a known issue?
Best regards,
Tobi
:graphics:ccIosPrismES2Arm
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:67:34:
warning: implicit declaration of function 'createContext' is invalid in C99
[-Wimplicit-function-declaration]
context = (jlong) (intptr_t) createContext((void *) (intptr_t)
nativeShareCtxHandle,
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:76:14:
warning: implicit declaration of function 'makeCurrentContext' is invalid in
C99 [-Wimplicit-function-declaration]
result = makeCurrentContext((void *) (intptr_t) context);
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:78:9:
warning: implicit declaration of function 'printAndReleaseResources' is
invalid in C99 [-Wimplicit-function-declaration]
printAndReleaseResources(0, context,
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:137:13:
warning: implicit declaration of function
'getProcAddress' is invalid in C99 [-Wimplicit-function-declaration]
getProcAddress("glActiveTexture");
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:239:5:
warning: implicit declaration of function 'setSwapInterval' is invalid in C99
[-Wimplicit-function-declaration]
setSwapInterval((void *) jlong_to_ptr(ctxInfo->context), 0);
^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:59:22:
warning:unused variable 'pfInfo' [-Wunused-variable]
PixelFormatInfo* pfInfo = (PixelFormatInfo* )jlong_to_ptr(nativePFInfo);
^
6 warnings generated.
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLDrawable.c:108:5:
warning: implicit declaration of function 'flushBuffer' is invalid in C99
[-Wimplicit-function-declaration]
flushBuffer((void *) (intptr_t) ctxInfo->context);
^
1 warning generated.
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:13:
warning: format specifies type 'unsigned int' but the argument has type 'void
*' [-Wformat]
shareContext, view, pixelFormat, viewNotReady);
^~~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:27:
warning: format specifies type 'unsigned int' but the argument has type 'void
*' [-Wformat]
shareContext, view, pixelFormat, viewNotReady);
^~~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:70:
warning: flag ' ' results in undefined behavior with 'n' conversion specifier
[-Wformat]
fprintf(stderr, "IOSWindowSystemInterface : share %x view %x pf % notready
%\n",
~^~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:33:
warning: format specifies type 'int *' but the argument has type 'void *'
[-Wformat]
shareContext, view, pixelFormat, viewNotReady);
^~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:81:
warning:invalid conversion specifier '
' [-Wformat-invalid-specifier]
fprintf(stderr, "IOSWindowSystemInterface : share %x view %x pf % notready
%\n",
~^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:60:12:
warning: incompatible integer to pointer conversion returning 'jlong' (aka
'long long') from a function with result type 'void *' [-Wint-conversion]
return ptr_to_jlo
hg: openjfx/8u-dev/rt: RT-37968: [Spinner] Review LocalDate and LocalTime spinner value factories
Changeset: c519c8a7ccae Author:jgiles Date: 2014-07-30 16:00 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c519c8a7ccae RT-37968: [Spinner] Review LocalDate and LocalTime spinner value factories ! modules/controls/src/main/java/javafx/scene/control/Spinner.java ! modules/controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: dd2faaee52c9 Author:jgiles Date: 2014-07-30 16:20 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dd2faaee52c9 Backed out changeset: c519c8a7ccae (it appears in importing my patch the line endings changed - will repush patch with correct line endings). ! modules/controls/src/main/java/javafx/scene/control/Spinner.java ! modules/controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java Changeset: 8296c327320b Author:jgiles Date: 2014-07-30 16:21 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8296c327320b RT-37968: [Spinner] Review LocalDate and LocalTime spinner value factories ! modules/controls/src/main/java/javafx/scene/control/Spinner.java ! modules/controls/src/main/java/javafx/scene/control/SpinnerValueFactory.java
