date:20140325


>> I mainly wanted to do this as a personal exercise, though I'd imagine this
>> is a useful piece of functionality for many others also - so should I
>> submit a patch of the changes, or is this unlikely to be accepted? (Again,
>> sorry for the perhaps obvious question, I'm rather new to this.) I've had a
>> look at the code review process and it seems to suggest adding a patch to
>> the relevant JIRA issue for those who don't have commit access (in this
>> case 18009), but I don't seem to have permission to do that either?
> 
> It sounds like there are perhaps two different ways to move forward here, the 
> first is to take a submission in the form of WIKI writeup that we can post so 
> that anybody else who wants to try extending the media files can follow the 
> path you took. The other is to take a patch for the given JIRA issue. Sadly, 
> the JIRA server doesn’t allow just anybody to supply patches, so you will 
> have to email to Steve or Kevin and they can attach it to the issue for you.

Be careful how these are implemented. We cannot just enable formats in 
GStreamer, there are licensing and legal issues involved. I think the Matroska 
licenses are fairly benign, but it still requires some amount of process.

What I would recommend is adding a switch to optionally enable additional 
formats, so those building GStreamer or OpenJFX themselves can turn whatever 
they want on or off, and they are on their own for dealing with legal issues.

That being said, we actually tested with MKV during development and it was 
pretty solid :)

-DrD-

Re: Adding GStreamer plugins

2014-03-25 Thread Michael Berry

Hi Richard,

Sure, I've emailed the patch to Scott and will work on a writeup for others
that want to do something similar! (Minor point, is the wiki source in
standard MediaWiki style or something else?)

Kirill - I think I'll take your suggestion next and start looking at
upgrading the existing native components to the latest version of GStreamer
before I look at adding any more plugins, that would seem to make sense.
Have you any pointers in how best to approach this?

Many thanks,

Michael


On 25 March 2014 23:46, Richard Bair  wrote:

> > Turns out it was a stupid mistake on my part causing the last few linking
> > errors, I hadn't added one of the C files I needed to the makefile (well
> I
> > had, but I'd then reverted it again without realising!) Thanks to all for
> > the prods and advice.
> >
> > Once I'd done that, the build went through without a hitch - and then it
> > was just a case of making the relevant additions to the native code to
> > register the MKV type and create a pipeline from it using the plugin.
> This
> > wasn't hard to work out at all; I've since tried several test files in
> MKV
> > format (with AAC audio) all of which play in MediaPlayer without a hitch!
>
> Awesome!
>
> > I mainly wanted to do this as a personal exercise, though I'd imagine
> this
> > is a useful piece of functionality for many others also - so should I
> > submit a patch of the changes, or is this unlikely to be accepted?
> (Again,
> > sorry for the perhaps obvious question, I'm rather new to this.) I've
> had a
> > look at the code review process and it seems to suggest adding a patch to
> > the relevant JIRA issue for those who don't have commit access (in this
> > case 18009), but I don't seem to have permission to do that either?
>
> It sounds like there are perhaps two different ways to move forward here,
> the first is to take a submission in the form of WIKI writeup that we can
> post so that anybody else who wants to try extending the media files can
> follow the path you took. The other is to take a patch for the given JIRA
> issue. Sadly, the JIRA server doesn't allow just anybody to supply patches,
> so you will have to email to Steve or Kevin and they can attach it to the
> issue for you.
>
> Thanks!
> Richard
>
>

Re: Adding GStreamer plugins

2014-03-25 Thread Richard Bair

> Turns out it was a stupid mistake on my part causing the last few linking
> errors, I hadn't added one of the C files I needed to the makefile (well I
> had, but I'd then reverted it again without realising!) Thanks to all for
> the prods and advice.
> 
> Once I'd done that, the build went through without a hitch - and then it
> was just a case of making the relevant additions to the native code to
> register the MKV type and create a pipeline from it using the plugin. This
> wasn't hard to work out at all; I've since tried several test files in MKV
> format (with AAC audio) all of which play in MediaPlayer without a hitch!

Awesome!

> I mainly wanted to do this as a personal exercise, though I'd imagine this
> is a useful piece of functionality for many others also - so should I
> submit a patch of the changes, or is this unlikely to be accepted? (Again,
> sorry for the perhaps obvious question, I'm rather new to this.) I've had a
> look at the code review process and it seems to suggest adding a patch to
> the relevant JIRA issue for those who don't have commit access (in this
> case 18009), but I don't seem to have permission to do that either?

It sounds like there are perhaps two different ways to move forward here, the 
first is to take a submission in the form of WIKI writeup that we can post so 
that anybody else who wants to try extending the media files can follow the 
path you took. The other is to take a patch for the given JIRA issue. Sadly, 
the JIRA server doesn’t allow just anybody to supply patches, so you will have 
to email to Steve or Kevin and they can attach it to the issue for you.

Thanks!
Richard

Re: Adding GStreamer plugins

2014-03-25 Thread Jonathan Giles

Typically in this case you would email the patch to the assigned 
developer, but it appears RT-18009 is unassigned at present. I think 
that is the first hurdle that needs to be resolved, but if you email me 
your patch I will attach it to the jira issue so that it is at least 
available for others.


Thanks!

-- Jonathan

On 26/03/2014 12:39 p.m., Michael Berry wrote:

Hi all,

Turns out it was a stupid mistake on my part causing the last few linking
errors, I hadn't added one of the C files I needed to the makefile (well I
had, but I'd then reverted it again without realising!) Thanks to all for
the prods and advice.

Once I'd done that, the build went through without a hitch - and then it
was just a case of making the relevant additions to the native code to
register the MKV type and create a pipeline from it using the plugin. This
wasn't hard to work out at all; I've since tried several test files in MKV
format (with AAC audio) all of which play in MediaPlayer without a hitch!

I mainly wanted to do this as a personal exercise, though I'd imagine this
is a useful piece of functionality for many others also - so should I
submit a patch of the changes, or is this unlikely to be accepted? (Again,
sorry for the perhaps obvious question, I'm rather new to this.) I've had a
look at the code review process and it seems to suggest adding a patch to
the relevant JIRA issue for those who don't have commit access (in this
case 18009), but I don't seem to have permission to do that either?

Thanks,

Michael


On 25 March 2014 17:01, Stephen F Northover wrote:


On 2014-03-25 7:00 AM, Kirill Kirichenko wrote:


Hi Michael.
See my comments inline.

On 24.03.2014 04:31, Michael Berry wrote:


I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved external symbol
errors for functions it uses in glib - not entirely sure why at the
moment,
as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer version, and
I
can't quite work out the logic behind why things have been changed the
way
they have - so even after the compilation issue is resolved I'm now less
confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could shed any
light on any of this, it would be hugely appreciated.


We did some changes in existing GStreamer code because it had errors and
because we needed to expand some functionality. The changes are not very
extensive.

  However, putting the current problems aside for a bit, the snags I hit up

until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few additional points
for the wiki? These may be obvious to the majority reading here, but as
someone completely new to building JFX they had me stumped for a while!


I can give you some directions. There is no wiki. I'd appreciate if you
created one.

- It turns out that the Gstreamer stuff doesn't compile at all by

default,
which is why I wasn't seeing any changes on the native level. To ensure
GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and uncomment the
"#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist
for
any webkit alterations as per the line above.)


You don't need to comment/uncomment anything. Just add
-PCOMPILE_MEDIA=true to the gradle command line. You can however change the
properties file too.

- As well as the requirements listed, I needed the Windows SDK (

http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed
for
GStreamer to compile successfully under Windows (7) - without it cygpath
just threw a rather confusing error.


You need windows 7.1a SDK and speaking precisely you need only samples
from it because samples have BaseClasses at 
Samples/multimedia/directshow/baseclasses.
BaseClasses are used for Oracle direchshowwrapper plugin.

- The developer workflow page (

https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow)
refers
to  "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs"
instead?


What are you gonna use it for ?


I updated the page and got rid of the BINARY_STUB reference that is no
longer needed.



  I'm happy to make the above changes myself but unsure of if / where you

can
sign up for an account, so I'm just throwing them here for now - if
anyone
could point me to the right place then that'd be great!


Steve. Can you give an advice ?


If you are looking to contribute (when you get to a good place), the
process is well known and is followed by the everyone.

 https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews



  If I do ever manage to get this working (ha-ha) I'd also like to throw

up a
wiki page just detailing how to grab a gstreamer plugin and make the
necessary changes to it to compile it into openjfx

Re: Adding GStreamer plugins

2014-03-25 Thread Michael Berry

Hi all,

Turns out it was a stupid mistake on my part causing the last few linking
errors, I hadn't added one of the C files I needed to the makefile (well I
had, but I'd then reverted it again without realising!) Thanks to all for
the prods and advice.

Once I'd done that, the build went through without a hitch - and then it
was just a case of making the relevant additions to the native code to
register the MKV type and create a pipeline from it using the plugin. This
wasn't hard to work out at all; I've since tried several test files in MKV
format (with AAC audio) all of which play in MediaPlayer without a hitch!

I mainly wanted to do this as a personal exercise, though I'd imagine this
is a useful piece of functionality for many others also - so should I
submit a patch of the changes, or is this unlikely to be accepted? (Again,
sorry for the perhaps obvious question, I'm rather new to this.) I've had a
look at the code review process and it seems to suggest adding a patch to
the relevant JIRA issue for those who don't have commit access (in this
case 18009), but I don't seem to have permission to do that either?

Thanks,

Michael


On 25 March 2014 17:01, Stephen F Northover wrote:

>
> On 2014-03-25 7:00 AM, Kirill Kirichenko wrote:
>
>> Hi Michael.
>> See my comments inline.
>>
>> On 24.03.2014 04:31, Michael Berry wrote:
>>
>>> I'm now a bit further along with this, though struggling to get the
>>> matroska plugin to compile (getting a bunch of unresolved external symbol
>>> errors for functions it uses in glib - not entirely sure why at the
>>> moment,
>>> as I said C is not my strong point.) I've also noticed the plugins
>>> currently bundled have quite a few changes to the gstreamer version, and
>>> I
>>> can't quite work out the logic behind why things have been changed the
>>> way
>>> they have - so even after the compilation issue is resolved I'm now less
>>> confident that it will just drop in and work! Again, if someone
>>> knowledgeable in this area that's lurking in the shadows could shed any
>>> light on any of this, it would be hugely appreciated.
>>>
>> We did some changes in existing GStreamer code because it had errors and
>> because we needed to expand some functionality. The changes are not very
>> extensive.
>>
>>  However, putting the current problems aside for a bit, the snags I hit up
>>> until this point could I think be relatively easily addressed in the
>>> documentation. With that in mind could I suggest a few additional points
>>> for the wiki? These may be obvious to the majority reading here, but as
>>> someone completely new to building JFX they had me stumped for a while!
>>>
>> I can give you some directions. There is no wiki. I'd appreciate if you
>> created one.
>>
>>- It turns out that the Gstreamer stuff doesn't compile at all by
>>> default,
>>> which is why I wasn't seeing any changes on the native level. To ensure
>>> GStreamer is actually compiled, you need to copy the
>>> gradle.properties.template file to gradle.properties, and uncomment the
>>> "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist
>>> for
>>> any webkit alterations as per the line above.)
>>>
>> You don't need to comment/uncomment anything. Just add
>> -PCOMPILE_MEDIA=true to the gradle command line. You can however change the
>> properties file too.
>>
>>- As well as the requirements listed, I needed the Windows SDK (
>>> http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed
>>> for
>>> GStreamer to compile successfully under Windows (7) - without it cygpath
>>> just threw a rather confusing error.
>>>
>> You need windows 7.1a SDK and speaking precisely you need only samples
>> from it because samples have BaseClasses at 
>> Samples/multimedia/directshow/baseclasses.
>> BaseClasses are used for Oracle direchshowwrapper plugin.
>>
>>- The developer workflow page (
>>> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow)
>>> refers
>>> to  "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs"
>>> instead?
>>>
>> What are you gonna use it for ?
>>
> I updated the page and got rid of the BINARY_STUB reference that is no
> longer needed.
>
>
>>  I'm happy to make the above changes myself but unsure of if / where you
>>> can
>>> sign up for an account, so I'm just throwing them here for now - if
>>> anyone
>>> could point me to the right place then that'd be great!
>>>
>> Steve. Can you give an advice ?
>>
> If you are looking to contribute (when you get to a good place), the
> process is well known and is followed by the everyone.
>
> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
>
>
>>  If I do ever manage to get this working (ha-ha) I'd also like to throw
>>> up a
>>> wiki page just detailing how to grab a gstreamer plugin and make the
>>> necessary changes to it to compile it into openjfx as a stop gap to then
>>> perhaps working on one or both of the above JIRA issues and seeing where
>>> I
>>> get - does

hg: openjfx/8u-dev/rt: RT-36375: Monocle, fix order of operations with Buffer in capture

Changeset: 85e8ec504bff
Author:ddhill
Date:  2014-03-25 17:40 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/85e8ec504bff

RT-36375: Monocle, fix order of operations with Buffer in capture
Reviewed-by: dblaukopf

! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleRobot.java

hg: openjfx/8u-dev/rt: [Accessibility] cosmetic changes

Changeset: e260e71603ca
Author:felipe
Date:  2014-03-25 13:43 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e260e71603ca

[Accessibility] cosmetic changes

! modules/graphics/src/main/java/com/sun/glass/ui/PlatformAccessible.java
! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java
! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java

[8u20] Review request for RT-35263: Win: Crashing VM in a JavaFX 3D app reading and writing STL files

2014-03-25 Thread Anthony Petrov


Hi Felipe, Steve,

Please review a fix for https://javafx-jira.kenai.com/browse/RT-35263

--
best regards,
Anthony

Re: Is Quicktime API calls inside JavaFX?

As I said, Apple does this. It took cocoa (a "nice" API) years until it
had the functionality of carbon (an "awful" API). Believe me, I have
experienced the trail of dead API and the pointless developer rewrites.

Steve

On 2014-03-25 4:02 PM, David DeHaven wrote:

Yes, this is true, but QuickTime (despite it's horrible component architecture)
was stable and actually useful for a very long time, then they dropped it and
replaced it with what amounts to absolutely nothing useful. Only in 10.8 did
they start putting useful bits back in, it's still a long ways to go to catch
up to the utility of QuickTime.

-DrD-

Apple has a long history of burning developers like this. It's the price of
running on their platform.

Steve

On 2014-03-25 3:30 PM, Phil Race wrote:

I see .. so AVFoundation was already there since 10.7, its AVKit that's new in
10.9
but AV Foundation is what FX would use.
It looks like Apple starting encouraging migration to AV Foundation about 18
months ago
based on the date of this document :-
https://developer.apple.com/library/mac/technotes/tn2300/_index.html
I suppose we need to learn read the apple seeds and interpret that as a big,
urgent, hint.

-phil.

On 3/25/2014 12:09 PM, David DeHaven wrote:

Therein lies The Problem, and why we had to go with QTKit when we supported
10.6... Every two releases they seem to deprecate half-baked APIs in favor of
some new half-baked API. At least as of 10.8 that seems to have stabilized
somewhat, as we transition more and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it wasn't
available on 10.6. It's supposed to work correctly (never had time to confirm)
on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to
stick with QTKit for older releases and move to AVFoundation in 10.8 and later.
Ideally, the QTKit component would be separate so it could be removed allowing
MAS apps to still support A/V playback. I think the QTKit component can be
dropped completely in FX 9 but it needs to be there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it doesn't
look useful for our purposes at first glance.

-DrD-

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 if its
unable to use QTKit since that's all there is on 10.8 or earlier.

Does the AppStore really disallow targeting something like half the installed
base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:

Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:

Thanks for the verification. No matter what state Quicktime is in it is no
longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could be
wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven
wrote:

Hi All,
Apparently the JavaFX includes some libraries that use the obsolete Quicktime.
When some submits to the Apple Store a JavaFX app it gets rejected based on
JavaFX having the obsolete API. I found out how to fix it from someone else
running into the same issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?


Yes, this is true, but QuickTime (despite it's horrible component architecture) 
was stable and actually useful for a very long time, then they dropped it and 
replaced it with what amounts to absolutely nothing useful. Only in 10.8 did 
they start putting useful bits back in, it's still a long ways to go to catch 
up to the utility of QuickTime.

-DrD-

> Apple has a long history of burning developers like this.  It's the price of 
> running on their platform.
> 
> Steve
> 
> On 2014-03-25 3:30 PM, Phil Race wrote:
>> I see .. so AVFoundation  was already there since 10.7, its AVKit that's new 
>> in 10.9
>> but AV Foundation is what FX would use.
>> It looks like Apple starting encouraging migration to AV Foundation about 18 
>> months ago
>> based on the date of this document :-
>> https://developer.apple.com/library/mac/technotes/tn2300/_index.html
>> I suppose we need to learn read the apple seeds and interpret that as a big, 
>> urgent, hint.
>> 
>> -phil.
>> 
>> 
>> 
>> 
>> On 3/25/2014 12:09 PM, David DeHaven wrote:
>>> Therein lies The Problem, and why we had to go with QTKit when we supported 
>>> 10.6... Every two releases they seem to deprecate half-baked APIs in favor 
>>> of some new half-baked API. At least as of 10.8 that seems to have 
>>> stabilized somewhat, as we transition more and more to an iOS clone.
>>> 
>>> We had issues with AVFoundation not working the way we needed and it wasn't 
>>> available on 10.6. It's supposed to work correctly (never had time to 
>>> confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll 
>>> likely have to stick with QTKit for older releases and move to AVFoundation 
>>> in 10.8 and later. Ideally, the QTKit component would be separate so it 
>>> could be removed allowing MAS apps to still support A/V playback. I think 
>>> the QTKit component can be dropped completely in FX 9 but it needs to be 
>>> there in FX 8.
>>> 
>>> AVKit is a high level component that sits on top of AVFoundation, it 
>>> doesn't look useful for our purposes at first glance.
>>> 
>>> -DrD-
>>> 
 I presume that Apple now want you to use AVKit which is new in 10.9.
 However I don't understand how you can develop an app that targets 10.8 if 
 its
 unable to use QTKit since that's all there is on  10.8 or earlier.
 
 Does the AppStore  really disallow targeting something like half the 
 installed base ??
 
 -phil.
 
 On 3/25/2014 9:19 AM, Stephen F Northover wrote:
> Here is the JIRA that is tracking this: 
> https://javafx-jira.kenai.com/browse/RT-34893
> 
> Steve
> 
> On 2014-03-25 11:46 AM, Tony Anecito wrote:
>> Thanks for the verification. No matter what state Quicktime is in it is 
>> no longer accepted by the Apple Store.
>> I am guessing these new rules will soon apply to everything but I could 
>> be wrong.
>> 
>> Regards,
>> -Tony
>> 
>> 
>> 
>> 
>> 
>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven 
>>  wrote:
>> 
>>> Hi All,
>>> Apparently the JavaFX includes some libraries that use the obsolete 
>>> Quicktime. When some submits to the Apple Store a JavaFX app it gets 
>>> rejected based on JavaFX having the obsolete API. I found out how to 
>>> fix it from someone else running into the same issue.
>>> 
>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage
>>>  
>> It uses the now deprecated QTKit to play media.
>> 
>> -DrD-
>> 
>

Re: Is Quicktime API calls inside JavaFX?

Apple has a long history of burning developers like this. It's the
price of running on their platform.

Steve

On 2014-03-25 3:30 PM, Phil Race wrote:
I see .. so AVFoundation was already there since 10.7, its AVKit
that's new in 10.9

but AV Foundation is what FX would use.
It looks like Apple starting encouraging migration to AV Foundation
about 18 months ago

based on the date of this document :-
https://developer.apple.com/library/mac/technotes/tn2300/_index.html
I suppose we need to learn read the apple seeds and interpret that as
a big, urgent, hint.

-phil.

On 3/25/2014 12:09 PM, David DeHaven wrote:
Therein lies The Problem, and why we had to go with QTKit when we
supported 10.6... Every two releases they seem to deprecate
half-baked APIs in favor of some new half-baked API. At least as of
10.8 that seems to have stabilized somewhat, as we transition more
and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it
wasn't available on 10.6. It's supposed to work correctly (never had
time to confirm) on 10.8 but that still leaves 10.7 out in the cold.
So we'll likely have to stick with QTKit for older releases and move
to AVFoundation in 10.8 and later. Ideally, the QTKit component would
be separate so it could be removed allowing MAS apps to still support
A/V playback. I think the QTKit component can be dropped completely
in FX 9 but it needs to be there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it
doesn't look useful for our purposes at first glance.

-DrD-

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets
10.8 if its

unable to use QTKit since that's all there is on 10.8 or earlier.

Does the AppStore really disallow targeting something like half the
installed base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:
Thanks for the verification. No matter what state Quicktime is in
it is no longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I
could be wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven
wrote:

Hi All,
Apparently the JavaFX includes some libraries that use the
obsolete Quicktime. When some submits to the Apple Store a JavaFX
app it gets rejected based on JavaFX having the obsolete API. I
found out how to fix it from someone else running into the same
issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread Phil Race

I see .. so AVFoundation was already there since 10.7, its AVKit that's
new in 10.9

but AV Foundation is what FX would use.
It looks like Apple starting encouraging migration to AV Foundation
about 18 months ago

based on the date of this document :-
https://developer.apple.com/library/mac/technotes/tn2300/_index.html
I suppose we need to learn read the apple seeds and interpret that as a
big, urgent, hint.

-phil.

On 3/25/2014 12:09 PM, David DeHaven wrote:

AVKit is a high level component that sits on top of AVFoundation, it doesn't
look useful for our purposes at first glance.

-DrD-

Does the AppStore really disallow targeting something like half the installed
base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:

Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:

Thanks for the verification. No matter what state Quicktime is in it is no
longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could be
wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven
wrote:

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

Therein lies The Problem, and why we had to go with QTKit when we supported 
10.6... Every two releases they seem to deprecate half-baked APIs in favor of 
some new half-baked API. At least as of 10.8 that seems to have stabilized 
somewhat, as we transition more and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it wasn't 
available on 10.6. It's supposed to work correctly (never had time to confirm) 
on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to 
stick with QTKit for older releases and move to AVFoundation in 10.8 and later. 
Ideally, the QTKit component would be separate so it could be removed allowing 
MAS apps to still support A/V playback. I think the QTKit component can be 
dropped completely in FX 9 but it needs to be there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it doesn't 
look useful for our purposes at first glance.

-DrD-

> I presume that Apple now want you to use AVKit which is new in 10.9.
> However I don't understand how you can develop an app that targets 10.8 if its
> unable to use QTKit since that's all there is on  10.8 or earlier.
> 
> Does the AppStore  really disallow targeting something like half the 
> installed base ??
> 
> -phil.
> 
> On 3/25/2014 9:19 AM, Stephen F Northover wrote:
>> Here is the JIRA that is tracking this: 
>> https://javafx-jira.kenai.com/browse/RT-34893
>> 
>> Steve
>> 
>> On 2014-03-25 11:46 AM, Tony Anecito wrote:
>>> Thanks for the verification. No matter what state Quicktime is in it is no 
>>> longer accepted by the Apple Store.
>>> I am guessing these new rules will soon apply to everything but I could be 
>>> wrong.
>>> 
>>> Regards,
>>> -Tony
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven 
>>>  wrote:
>>> 
 Hi All,
 Apparently the JavaFX includes some libraries that use the obsolete 
 Quicktime. When some submits to the Apple Store a JavaFX app it gets 
 rejected based on JavaFX having the obsolete API. I found out how to fix 
 it from someone else running into the same issue.

 http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

>>> It uses the now deprecated QTKit to play media.
>>> 
>>> -DrD-
>> 
>

Re: Glass Robot and getSCreenCapture

2014-03-25 Thread David Hill


On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:

Having heard a little feedback, here is my proposal in the form of a review 
request :-)



My recommendation would be modify the JavaDoc contract to specify that the x,y 
and x+width, y+height must be within the screen bounds, with an 
IllegalArgumentException if out of bounds. This would be checked in Robot, 
prior to calling the native impls.

This code is "internal" API, so I expect the real impact would be on SQE.

I really like the idea of adding a bounds restriction - so that the requested 
bounds must be within the Screen.
It seems the simplest solution to my issue of handling the odd edge case of out 
of bound pixels, with the least likely impact.

This means that existing code in the implementations are not affected.
I suspect that there will we little if any impact on SQE tests, given that most 
of us would avoid asking for a screen capture with undefined pixels. I do 
expect that we will encounter a few exceptions to this when tests are run on 
smaller displays (like embedded).

I also added bounds checking to Robot.getPixelColor() for consistency, and 
because Embedded passes this call through to common code for screen capture.

I did a grep through the JavaFX code base, and don't see any JavaFX use cases. I expect 
any "golden image" test code could be affected.

I separated out this internal API changes from my embedded changes so we have a 
clear and easy thing to review.

Jira: https://javafx-jira.kenai.com/browse/RT-36382

Patch: is inline in the Jira, but also here:

diff -r bb72bd2fa889 modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
--- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 
14:21:26 2014 -0400
+++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 
14:41:37 2014 -0400
@@ -144,9 +144,20 @@
 protected abstract int _getPixelColor(int x, int y);
 /**
  * Returns pixel color at specified screen coordinates in IntARGB format.
+ *
+ * If the requested pixel is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be >=0)
+ * @param y The screen Y of the requested capture (must be >=0)
  */
 public int getPixelColor(int x, int y) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x < 0 || y < 0 ||
+x >= s.getWidth() || y > s.getHeight()) {
+   throw new IllegalArgumentException("Capture out of bounds");
+}
 return _getPixelColor(x, y);
 }

@@ -162,13 +173,27 @@
  * will result in a Pixels object with dimensions (20x20). Calling code
  * should use the returned objects's getWidth() and getHeight() methods
  * to determine the image size.
- *
+ *
  * If (@code isHiDPI) is {@code false}, the returned Pixels object is of
  * the requested size. Note that in this case the image may be scaled in
  * order to fit to the requested dimensions if running on a HiDPI display.
+ *
+ * If the requested capture bounds is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be >=0)
+ * @param y The screen Y of the requested capture (must be >=0)
+ * @param width The of width the requested capture (must be >=1 and fit on 
the screen)
+ * @param height The of width the requested capture (must be >=1 and fit 
on the screen)
+ * @param isHiDPI return HiDPI if available
  */
 public Pixels getScreenCapture(int x, int y, int width, int height, 
boolean isHiDPI) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x < 0 || y < 0 ||
+x + width > s.getWidth() || y + height > s.getHeight()) {
+   throw new IllegalArgumentException("Capture out of bounds");
+}
 return _getScreenCapture(x, y, width, height, isHiDPI);
 }

@@ -176,6 +201,14 @@
  * Returns a capture of the specified area of the screen.
  * It is equivalent to calling getScreenCapture(x, y, width, height, 
false),
  * i.e. this method takes a "LowDPI" screen shot.
+ *
+ * If the requested capture bounds is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be >=0)
+ * @param y The screen Y of the requested capture (must be >=0)
+ * @param width The of width the requested capture (must be >=1 and fit on 
the screen)
+ * @param height The of width the requested capture (must be >=1 and fit 
on the screen)
  */
 public Pixels getScreenCapture(int x, int y, int width, int height) {
 return getScreenCapture(x, y, width, height, false);


--
David Hill 
Java Embedded Development

"On a clear disk, you can seek

Re: Is Quicktime API calls inside JavaFX?

Hi Phil,

What happened is when I submitted my app package it 
uploaded and Apple ran a check and pointed out the issue but did not 
suggest a solution.
There are other solutions for video out there but
 not sure Apple would approve. I will find out soon with my next app but
 for now trying not to throw too much technology at them at once.

Oracle may be interested in what I am up to and why I think it is very 
important I get my app approved for the Apple App Store.

http://www.myuniportal.com/screenshots.html

Best Regards,
Tony Anecito
Founder/President
MyUniPortal
http://www.myuniportal.com
Winner of Java Dukes Award

On Tuesday, March 25, 2014 11:27 AM, Tony Anecito  wrote:

Thanks I read it. I also added a new issue regarding Apple now needing a pinfo 
file for the jdk plugin inside the bundle created by JavaFX deploy.

Regards,
-Tony

On Tuesday, March 25, 2014 10:36 AM, Phil Race  wrote:

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 
if its
unable to use QTKit since that's all there is on  10.8 or earlier.

Does the AppStore  really disallow targeting something like half the 
installed base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
> Here is the JIRA that is tracking this: 
> https://javafx-jira.kenai.com/browse/RT-34893
>
> Steve
>
> On 2014-03-25 11:46 AM, Tony Anecito wrote:
>> Thanks for the verification. No matter what state Quicktime is in it 
>> is no longer accepted by the Apple Store.
>> I am guessing these new rules will soon apply to everything but I 
>> could be wrong.
>>
>> Regards,
>> -Tony
>>
>>
>>
>>
>>
>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven 
>>  wrote:
>>
>>> Hi All,
>>> Apparently the JavaFX includes some libraries that use the obsolete 
>>> Quicktime. When some submits to the Apple Store a JavaFX app it gets 
>>> rejected based on JavaFX having the obsolete API. I found out how to 
>>> fix it from someone else running into the same issue.
>>>
>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage
>>>  
>>>
>> It uses the now deprecated QTKit to play media.
>>
>> -DrD-
>

hg: openjfx/8u-dev/rt: Fix for RT-36360 [Monocle] Slight refactor; cache native display in java instead of native code.

Changeset: a4f4d7834a8f
Author:lisa.se...@oracle.com
Date:  2014-03-25 13:30 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a4f4d7834a8f

Fix for RT-36360 [Monocle] Slight refactor; cache native display in java 
instead of native code.

Reviewed by dblaukopf.  Tested with HelloSanity.

! 
modules/graphics/src/main/java/com/sun/glass/ui/monocle/mx6/MX6AcceleratedScreen.java
! modules/graphics/src/main/native-glass/monocle/mx6/MX6AcceleratedScreen.c

Re: Is Quicktime API calls inside JavaFX?

Thanks I read it. I also added a new issue regarding Apple now needing a pinfo 
file for the jdk plugin inside the bundle created by JavaFX deploy.

Regards,
-Tony

On Tuesday, March 25, 2014 10:36 AM, Phil Race  wrote:

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 
if its
unable to use QTKit since that's all there is on  10.8 or earlier.

Does the AppStore  really disallow targeting something like half the 
installed base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
> Here is the JIRA that is tracking this: 
> https://javafx-jira.kenai.com/browse/RT-34893
>
> Steve
>
> On 2014-03-25 11:46 AM, Tony Anecito wrote:
>> Thanks for the verification. No matter what state Quicktime is in it 
>> is no longer accepted by the Apple Store.
>> I am guessing these new rules will soon apply to everything but I 
>> could be wrong.
>>
>> Regards,
>> -Tony
>>
>>
>>
>>
>>
>> On Tuesday, March 25, 2014 9:27 AM, David DeHaven 
>>  wrote:
>>
>>> Hi All,
>>> Apparently the JavaFX includes some libraries that use the obsolete 
>>> Quicktime. When some submits to the Apple Store a JavaFX app it gets 
>>> rejected based on JavaFX having the obsolete API. I found out how to 
>>> fix it from someone else running into the same issue.
>>>
>>> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage
>>>  
>>>
>> It uses the now deprecated QTKit to play media.
>>
>> -DrD-
>

Re: Adding GStreamer plugins



On 2014-03-25 7:00 AM, Kirill Kirichenko wrote:

Hi Michael.
See my comments inline.

On 24.03.2014 04:31, Michael Berry wrote:

I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved external 
symbol
errors for functions it uses in glib - not entirely sure why at the 
moment,

as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer version, 
and I
can't quite work out the logic behind why things have been changed 
the way

they have - so even after the compilation issue is resolved I'm now less
confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could shed any
light on any of this, it would be hugely appreciated.
We did some changes in existing GStreamer code because it had errors 
and because we needed to expand some functionality. The changes are 
not very extensive.


However, putting the current problems aside for a bit, the snags I 
hit up

until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few additional points
for the wiki? These may be obvious to the majority reading here, but as
someone completely new to building JFX they had me stumped for a while!
I can give you some directions. There is no wiki. I'd appreciate if 
you created one.


  - It turns out that the Gstreamer stuff doesn't compile at all by 
default,

which is why I wasn't seeing any changes on the native level. To ensure
GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and uncomment the
"#COMPILE_MEDIA = true" line. (A similar scenario would appear to 
exist for

any webkit alterations as per the line above.)
You don't need to comment/uncomment anything. Just add 
-PCOMPILE_MEDIA=true to the gradle command line. You can however 
change the properties file too.



  - As well as the requirements listed, I needed the Windows SDK (
http://www.microsoft.com/en-gb/download/details.aspx?id=8279) 
installed for

GStreamer to compile successfully under Windows (7) - without it cygpath
just threw a rather confusing error.
You need windows 7.1a SDK and speaking precisely you need only samples 
from it because samples have BaseClasses at 
Samples/multimedia/directshow/baseclasses. BaseClasses are used for 
Oracle direchshowwrapper plugin.



  - The developer workflow page (
https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) 
refers
to  "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" 
instead?

What are you gonna use it for ?
I updated the page and got rid of the BINARY_STUB reference that is no 
longer needed.


I'm happy to make the above changes myself but unsure of if / where 
you can
sign up for an account, so I'm just throwing them here for now - if 
anyone

could point me to the right place then that'd be great!

Steve. Can you give an advice ?
If you are looking to contribute (when you get to a good place), the 
process is well known and is followed by the everyone.


https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews


If I do ever manage to get this working (ha-ha) I'd also like to 
throw up a

wiki page just detailing how to grab a gstreamer plugin and make the
necessary changes to it to compile it into openjfx as a stop gap to then
perhaps working on one or both of the above JIRA issues and seeing 
where I

get - does this sound reasonable?


Only committers can edit the wiki right now.  It is possible to become 
an Author and write to the wiki, but I would be happy to publish your 
recipe when you are happy with it.



It does.



On Mar 22, 2014, at 9:26 PM, Michael Berry  wrote:
However, I'm not sure if I'm going about including the matroska 
plugin

in

the right way - I've currently done the following:

- Downloaded the latest version of the plugins from here (
http://gstreamer.freedesktop.org/src/gst-plugins-good/), then 
added the

matroska one to the modules/media/src/main/native/gstreamer/plugins/
folder, as well as the

modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ 


folder (I'm unsure of this - should I add it to both these folders?).
Well you see. If you download the latest matroska plugin it 
potentially can have dependencies on the latest GStreamer platform. We 
don't have/use the latest gstreamer. The version we use is 0.10.35. 
And the latest available is 1.x. They are incompatible in some methods.



- Added all the C files from the first folder mentioned above to the
plugins.vcxproj file

- Added the relevant files and directory to Makefile.gstplugins

- Called the additional relevant plugin_init() function in
gstplugins-lite.c
There is one more thing you need to do here for Windows only apart 
from running gradle with -PCOMPILE_MEDIA=true. Windows build system 
has files that export symbols
1) from glib-lit

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread Phil Race


I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 
if its

unable to use QTKit since that's all there is on  10.8 or earlier.

Does the AppStore  really disallow targeting something like half the 
installed base ??


-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
Here is the JIRA that is tracking this: 
https://javafx-jira.kenai.com/browse/RT-34893


Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:
Thanks for the verification. No matter what state Quicktime is in it 
is no longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I 
could be wrong.


Regards,
-Tony





On Tuesday, March 25, 2014 9:27 AM, David DeHaven 
 wrote:



Hi All,
Apparently the JavaFX includes some libraries that use the obsolete 
Quicktime. When some submits to the Apple Store a JavaFX app it gets 
rejected based on JavaFX having the obsolete API. I found out how to 
fix it from someone else running into the same issue.


http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage 


It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

Here is the JIRA that is tracking this: 
https://javafx-jira.kenai.com/browse/RT-34893


Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:

Thanks for the verification. No matter what state Quicktime is in it is no 
longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could be 
wrong.

Regards,
-Tony





On Tuesday, March 25, 2014 9:27 AM, David DeHaven  
wrote:
  


Hi All,
Apparently the JavaFX includes some libraries that use the obsolete Quicktime. 
When some submits to the Apple Store a JavaFX app it gets rejected based on 
JavaFX having the obsolete API. I found out how to fix it from someone else 
running into the same issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

Hi All,
Apparently the JavaFX includes some libraries that use the obsolete Quicktime. 
When some submits to the Apple Store a JavaFX app it gets rejected based on 
JavaFX having the obsolete API. I found out how to fix it from someone else 
running into the same issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

Regards,
-Tony





On Tuesday, March 25, 2014 7:49 AM, Tony Anecito  wrote:
 
Hi All,
Is JavaFX using Apple Quicktime for video support?

Thanks,
-Tony

Re: Is Quicktime API calls inside JavaFX?

Thanks for the verification. No matter what state Quicktime is in it is no 
longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could be 
wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven  
wrote:

> Hi All,
> Apparently the JavaFX includes some libraries that use the obsolete 
> Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected 
> based on JavaFX having the obsolete API. I found out how to fix it from 
> someone else running into the same issue.
> 
> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Adding GStreamer plugins

2014-03-25 Thread Kirill Kirichenko




On 25.03.2014 17:21, Michael Berry wrote:

It seems the issue that I was having was indeed to do with the step you
outlined; I was getting unresolved external linker issues because it
couldn't find the functions I hadn't added. However, while the linker
errors associated with all the glib functions have now been resolved
through adding the methods (to both glib-lite.def and glib-liteD.def),
adding the relevant functions to gstreamer-lite.def complains about an
unresolved external symbol in the def file:

gstreamer-lite.def : error LNK2001: unresolved external symbol
gst_byte_writer_free
gstreamer-lite.def : error LNK2001: unresolved external symbol
gst_byte_writer_free_and_get_buffer
gstreamer-lite.def : error LNK2001: unresolved external symbol
gst_byte_writer_new_with_size

When they're not in the def file, I get the following linker errors instead:

libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external
symbol _gst_byte_writer_free referenced in function _gst_ebml_write_finalize
libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external
symbol _gst_byte_writer_new_with_size referenced in function
_gst_ebml_start_streamheader
libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external
symbol _gst_byte_writer_free_and_get_bufferreferenced in function
_gst_ebml_stop_streamheader

I've added these to the gstreamer-lite.def file in exactly the same way
as I added the glib functions to the glib files - any idea what I might
have missed?

gst_byte_writer_free_and_get_buffer@184NONAME
gst_byte_writer_free@185NONAME
gst_byte_writer_new_with_size@186NONAME
This is not necessary that you should add all methods to the def file. 
Here first you should look for where the symbols are implemented and you 
possibly miss this file from from makefile. Take all symbols that linker 
shows to you, strip leading underscore character, and find them in the 
vanilla glib. It's possible that we did not include the file where they 
are implemented to the sources.
In short: look where gst_byte_writer_free, gst_byte_writer_new_with_size 
and gst_byte_writer_free_and_get_bufferreferenced are implemented and 
make sure this file is compiled.


(I'm assuming NONAME is always there, and the number is sequential.) The
functions are in gstbytewriter.h which is there, though perhaps I need
to make the linker aware of that file specifically if it's not used
anywhere else? (I'm just guessing here though.)
NONAME is always there and the number is sequential. Also make sure use 
TABS between the columns. As far as I remember TABS are used, but do 
double check it.




Happy to look at upgrading gstreamer to the latest version as a next
task, so I'd be more than willing to give that a go. Though I would
quite like to get the matroska plugin working first - just so I've got
some experience at building in a working plugin, and have some end
result from what I'm trying to achieve here!

OK.



Many thanks,

Michael


On 25 March 2014 11:00, Kirill Kirichenko mailto:kirill.kiriche...@oracle.com>> wrote:

Hi Michael.
See my comments inline.


On 24.03.2014 04:31, Michael Berry wrote:

I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved
external symbol
errors for functions it uses in glib - not entirely sure why at
the moment,
as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer
version, and I
can't quite work out the logic behind why things have been
changed the way
they have - so even after the compilation issue is resolved I'm
now less
confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could
shed any
light on any of this, it would be hugely appreciated.

We did some changes in existing GStreamer code because it had errors
and because we needed to expand some functionality. The changes are
not very extensive.


However, putting the current problems aside for a bit, the snags
I hit up
until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few
additional points
for the wiki? These may be obvious to the majority reading here,
but as
someone completely new to building JFX they had me stumped for a
while!

I can give you some directions. There is no wiki. I'd appreciate if
you created one.


   - It turns out that the Gstreamer stuff doesn't compile at
all by default,
which is why I wasn't seeing any changes on the native level. To
ensure
GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and
unco

Re: Is Quicktime API calls inside JavaFX?


> Hi All,
> Apparently the JavaFX includes some libraries that use the obsolete 
> Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected 
> based on JavaFX having the obsolete API. I found out how to fix it from 
> someone else running into the same issue.
> 
> http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Is Quicktime API calls inside JavaFX?

Hi All,
Is JavaFX using Apple Quicktime for video support?

Thanks,
-Tony

Re: Adding GStreamer plugins

2014-03-25 Thread Michael Berry

Hi Kirill,

Many thanks for the detailed response, that's incredibly helpful. I had
noted already that you were using gstreamer 0.10.35 from downloading the
gstreamer modifications for JFX8 from Oracle's site, so was using the
appropriate version of the plugin already to try to ensure no compatibility
issues arose.

It seems the issue that I was having was indeed to do with the step you
outlined; I was getting unresolved external linker issues because it
couldn't find the functions I hadn't added. However, while the linker
errors associated with all the glib functions have now been resolved
through adding the methods (to both glib-lite.def and glib-liteD.def),
adding the relevant functions to gstreamer-lite.def complains about an
unresolved external symbol in the def file:

gstreamer-lite.def : error LNK2001: unresolved external symbol
gst_byte_writer_free
gstreamer-lite.def : error LNK2001: unresolved external symbol
gst_byte_writer_free_and_get_buffer
gstreamer-lite.def : error LNK2001: unresolved external symbol
gst_byte_writer_new_with_size

When they're not in the def file, I get the following linker errors instead:

libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external
symbol _gst_byte_writer_free referenced in function _gst_ebml_write_finalize
libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external
symbol _gst_byte_writer_new_with_size referenced in function
_gst_ebml_start_streamheader
libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external
symbol _gst_byte_writer_free_and_get_bufferreferenced in function
_gst_ebml_stop_streamheader

I've added these to the gstreamer-lite.def file in exactly the same way as
I added the glib functions to the glib files - any idea what I might have
missed?

gst_byte_writer_free_and_get_buffer @184 NONAME
gst_byte_writer_free @185 NONAME
gst_byte_writer_new_with_size @186 NONAME

(I'm assuming NONAME is always there, and the number is sequential.) The
functions are in gstbytewriter.h which is there, though perhaps I need to
make the linker aware of that file specifically if it's not used anywhere
else? (I'm just guessing here though.)

Happy to look at upgrading gstreamer to the latest version as a next task,
so I'd be more than willing to give that a go. Though I would quite like to
get the matroska plugin working first - just so I've got some experience at
building in a working plugin, and have some end result from what I'm trying
to achieve here!

Many thanks,

Michael

On 25 March 2014 11:00, Kirill Kirichenko wrote:

> Hi Michael.
> See my comments inline.
>
>
> On 24.03.2014 04:31, Michael Berry wrote:
>
>> I'm now a bit further along with this, though struggling to get the
>> matroska plugin to compile (getting a bunch of unresolved external symbol
>> errors for functions it uses in glib - not entirely sure why at the
>> moment,
>> as I said C is not my strong point.) I've also noticed the plugins
>> currently bundled have quite a few changes to the gstreamer version, and I
>> can't quite work out the logic behind why things have been changed the way
>> they have - so even after the compilation issue is resolved I'm now less
>> confident that it will just drop in and work! Again, if someone
>> knowledgeable in this area that's lurking in the shadows could shed any
>> light on any of this, it would be hugely appreciated.
>>
> We did some changes in existing GStreamer code because it had errors and
> because we needed to expand some functionality. The changes are not very
> extensive.
>
>
>  However, putting the current problems aside for a bit, the snags I hit up
>> until this point could I think be relatively easily addressed in the
>> documentation. With that in mind could I suggest a few additional points
>> for the wiki? These may be obvious to the majority reading here, but as
>> someone completely new to building JFX they had me stumped for a while!
>>
> I can give you some directions. There is no wiki. I'd appreciate if you
> created one.
>
>
>- It turns out that the Gstreamer stuff doesn't compile at all by
>> default,
>> which is why I wasn't seeing any changes on the native level. To ensure
>> GStreamer is actually compiled, you need to copy the
>> gradle.properties.template file to gradle.properties, and uncomment the
>> "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist
>> for
>> any webkit alterations as per the line above.)
>>
> You don't need to comment/uncomment anything. Just add
> -PCOMPILE_MEDIA=true to the gradle command line. You can however change the
> properties file too.
>
>
>- As well as the requirements listed, I needed the Windows SDK (
>> http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed
>> for
>> GStreamer to compile successfully under Windows (7) - without it cygpath
>> just threw a rather confusing error.
>>
> You need windows 7.1a SDK and speaking precisely you need only samples
> from it because samples have BaseClasses at 
> Sampl

Re: Adding GStreamer plugins

2014-03-25 Thread Kirill Kirichenko

Hi Michael.
See my comments inline.

On 24.03.2014 04:31, Michael Berry wrote:

I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved external symbol
errors for functions it uses in glib - not entirely sure why at the moment,
as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer version, and I
can't quite work out the logic behind why things have been changed the way
they have - so even after the compilation issue is resolved I'm now less
confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could shed any
light on any of this, it would be hugely appreciated.
We did some changes in existing GStreamer code because it had errors and
because we needed to expand some functionality. The changes are not very
extensive.

However, putting the current problems aside for a bit, the snags I hit up
until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few additional points
for the wiki? These may be obvious to the majority reading here, but as
someone completely new to building JFX they had me stumped for a while!
I can give you some directions. There is no wiki. I'd appreciate if you
created one.

- It turns out that the Gstreamer stuff doesn't compile at all by default,
which is why I wasn't seeing any changes on the native level. To ensure
GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and uncomment the
"#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist for
any webkit alterations as per the line above.)
You don't need to comment/uncomment anything. Just add
-PCOMPILE_MEDIA=true to the gradle command line. You can however change
the properties file too.

- As well as the requirements listed, I needed the Windows SDK (
http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for
GStreamer to compile successfully under Windows (7) - without it cygpath
just threw a rather confusing error.
You need windows 7.1a SDK and speaking precisely you need only samples
from it because samples have BaseClasses at
Samples/multimedia/directshow/baseclasses. BaseClasses are used for
Oracle direchshowwrapper plugin.

- The developer workflow page (
https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers
to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" instead?

What are you gonna use it for ?

I'm happy to make the above changes myself but unsure of if / where you can
sign up for an account, so I'm just throwing them here for now - if anyone
could point me to the right place then that'd be great!

Steve. Can you give an advice ?

If I do ever manage to get this working (ha-ha) I'd also like to throw up a
wiki page just detailing how to grab a gstreamer plugin and make the
necessary changes to it to compile it into openjfx as a stop gap to then
perhaps working on one or both of the above JIRA issues and seeing where I
get - does this sound reasonable?

It does.

On Mar 22, 2014, at 9:26 PM, Michael Berry wrote:

However, I'm not sure if I'm going about including the matroska plugin

the right way - I've currently done the following:

- Downloaded the latest version of the plugins from here (
http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the
matroska one to the modules/media/src/main/native/gstreamer/plugins/
folder, as well as the

modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/

folder (I'm unsure of this - should I add it to both these folders?).
Well you see. If you download the latest matroska plugin it potentially
can have dependencies on the latest GStreamer platform. We don't
have/use the latest gstreamer. The version we use is 0.10.35. And the
latest available is 1.x. They are incompatible in some methods.

- Added all the C files from the first folder mentioned above to the
plugins.vcxproj file

- Added the relevant files and directory to Makefile.gstplugins

- Called the additional relevant plugin_init() function in
gstplugins-lite.c
There is one more thing you need to do here for Windows only apart from
running gradle with -PCOMPILE_MEDIA=true. Windows build system has files
that export symbols
1) from glib-lite.dll
${jfxroot}/rt/modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.28.8/build/win32/vs100/{glib-lite.def|glib-liteD.def}

Here the version with "D" is used for debug build and may contain more
symbols for export.
2) from gstreamer-lite.dll
${jfxroot}/rt/modules/media/src/main/native/gstreamer/projects/win/gstreamer-lite.def
- used for both Release and Debug.

If your plugin uses some methods of gstreamer/glib libraries not
mentioned in the files you should add the methods to the files. Syntax
is pretty si

hg: openjfx/8u-dev/rt: RT-36238 [Ensemble8] SwingInterop throws IllegalStateException: Not on FX application thread

Changeset: c037c7fb6786
Author:Martin Sladecek 
Date:  2014-03-25 11:05 +0100
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c037c7fb6786

RT-36238 [Ensemble8] SwingInterop throws IllegalStateException: Not on FX 
application thread

- 
apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/ProcessListener.java
! 
apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInteropApp.java
! 
apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInteropService.java
! 
apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/swing/SwingInteropTask.java

hg: openjfx/8u-dev/rt: 2 new changesets