Re: Handling Enter key presses on Buttons in JavaFX

[Michael Berry]

On 7 June 2016 at 23:04, Tomas Mikula  wrote:

> What about forgetting the whole notion of a "default button" and the only
> effect of setting the default property to true being that the button will
> start as focused?
>
> So I add a question:
>
> 3) Would anyone miss the "default button"?
>

Afraid I would - I find the visual difference of the default button rather
useful. While it would be possible to just use CSS to style it differently,
this (in my mind) would be a step backwards (and that's before the issues
that would arise from a backwards-compatibility standpoint due to removing
an existing property.)

Michael


>
> Tomas
>
> On Tue, Jun 7, 2016 at 5:47 PM, Jonathan Giles 
> wrote:
>
> > Hi all,
> >
> > One thing I've been looking into recently is the issue of what the Enter
> > key should do when it is pushed with regards to buttons in a UI where one
> > of those buttons is a 'default' button. There are number of Jira issues
> on
> > this topic, and I wanted to poll the community to understand its
> opinions.
> >
> > The current situation is that the Enter key does not fire the focused
> > Button. The Enter key is reserved for firing the 'default' Button in the
> UI
> > (i.e. if someone has created a Button instance with the default property
> > set to true). A default button is rendered slightly differently (in
> Modena
> > it is blue for example). To fire the focused Button, the user must press
> > the Space key.
> >
> > Tom Schindl filed a bug (JDK-8139510) that is a good example of the
> > 'problem' this creates. In the bug report, a dialog is shown to the user.
> > In the dialog is an OK button and a Cancel button. The OK button has been
> > made the 'default' button. Regardless of which button has focus, the
> Enter
> > key always fires the OK button. The only way to fire the Cancel button is
> > via the Space key. This can be very confusing for users who have tabbed
> > specifically to the 'Cancel' button and then pressed the Enter key, only
> to
> > find they unwittingly fired the 'OK' action.
> >
> > To me this has always been a little counter-intuitive, because of my
> > heritage as a long-time Windows user. I believe Linux is much the same as
> > Windows. For others who grew up on Mac, I'm less sure on what people
> expect
> > (but it seems to be that the Enter key fires the default button, not the
> > focused button, i.e. JavaFX current behavior matches what is expected on
> OS
> > X).
> >
> > What I'm proposing we do is to change the behavior as follows:
> >
> > 1) On OS X we do not change behavior at all - we keep the current 'Enter
> > means default' and 'Space means focus' semantics.
> >
> > 2) On non-OS X platforms, we change the behavior so that Enter (and
> Space)
> > will fire the _focused_ key, if one is focused. If no Button is focused
> > (e.g. focus is in a TextField, etc), then Enter will work as it currently
> > does and fire the default button, if one is specified. In short, default
> > buttons will still be rendered blue to hint to the user that they are the
> > default button, but they will be less prevalently fired by Enter key
> > presses - only when they also have focus.
> >
> > The two questions that I have are:
> >
> > 1) Will this confuse users when there is a behavior change (and
> > presumably, this change will be made in JDK 9 and not backported to JDK
> 8).
> > If it will confuse users, is it still the right thing to do?
> >
> > 2) Do we want to have different behaviors for OS X and non-OS X? I'm a
> > newly inducted member into the cult of Mac, and I don't yet have all my
> > bearings sorted out, so I don't have a strong opinion here.
> >
> > Your thoughts, as always, are appreciated.
> > -- Jonathan
> >
>



-- 
Thanks,

Michael


Virus-free.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Handling Enter key presses on Buttons in JavaFX

[Michael Berry]

I can't comment on behalf of the Mac guys, but certainly from a Windows
perspective I find the current behaviour confusing - I would ideally expect
the enter key to fire the focused button, and the "default" button would
get fired by default purely because it is the one first selected (as oppose
to it being universally tied to the enter key.)

Of course, there's always the potential that it may confuse existing users,
but IMO keeping the same behaviour would probably confuse more users in the
long run! So yes, I'd say it's the right thing to do.

In any case, a command line option could be introduced to force behaviour
one way or the other for those that really need it to always be the same on
each platform - but from my perspective this does seem somewhat overkill.

Michael



Virus-free.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On 7 June 2016 at 22:47, Jonathan Giles  wrote:

> Hi all,
>
> One thing I've been looking into recently is the issue of what the Enter
> key should do when it is pushed with regards to buttons in a UI where one
> of those buttons is a 'default' button. There are number of Jira issues on
> this topic, and I wanted to poll the community to understand its opinions.
>
> The current situation is that the Enter key does not fire the focused
> Button. The Enter key is reserved for firing the 'default' Button in the UI
> (i.e. if someone has created a Button instance with the default property
> set to true). A default button is rendered slightly differently (in Modena
> it is blue for example). To fire the focused Button, the user must press
> the Space key.
>
> Tom Schindl filed a bug (JDK-8139510) that is a good example of the
> 'problem' this creates. In the bug report, a dialog is shown to the user.
> In the dialog is an OK button and a Cancel button. The OK button has been
> made the 'default' button. Regardless of which button has focus, the Enter
> key always fires the OK button. The only way to fire the Cancel button is
> via the Space key. This can be very confusing for users who have tabbed
> specifically to the 'Cancel' button and then pressed the Enter key, only to
> find they unwittingly fired the 'OK' action.
>
> To me this has always been a little counter-intuitive, because of my
> heritage as a long-time Windows user. I believe Linux is much the same as
> Windows. For others who grew up on Mac, I'm less sure on what people expect
> (but it seems to be that the Enter key fires the default button, not the
> focused button, i.e. JavaFX current behavior matches what is expected on OS
> X).
>
> What I'm proposing we do is to change the behavior as follows:
>
> 1) On OS X we do not change behavior at all - we keep the current 'Enter
> means default' and 'Space means focus' semantics.
>
> 2) On non-OS X platforms, we change the behavior so that Enter (and Space)
> will fire the _focused_ key, if one is focused. If no Button is focused
> (e.g. focus is in a TextField, etc), then Enter will work as it currently
> does and fire the default button, if one is specified. In short, default
> buttons will still be rendered blue to hint to the user that they are the
> default button, but they will be less prevalently fired by Enter key
> presses - only when they also have focus.
>
> The two questions that I have are:
>
> 1) Will this confuse users when there is a behavior change (and
> presumably, this change will be made in JDK 9 and not backported to JDK 8).
> If it will confuse users, is it still the right thing to do?
>
> 2) Do we want to have different behaviors for OS X and non-OS X? I'm a
> newly inducted member into the cult of Mac, and I don't yet have all my
> bearings sorted out, so I don't have a strong opinion here.
>
> Your thoughts, as always, are appreciated.
> -- Jonathan
>



-- 
Thanks,

Michael

Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats

[Michael Berry]

On 27 August 2015 at 19:53, David DeHaven david.deha...@oracle.com wrote:


  +1 for deprecation - I haven't used VP6 in a long while, and would value
  the whole thing being open source more than its inclusion.
 
  Out of interest, is this anything to do with JEP 257? I started looking
 at
  this with Kirill's guidance a year or so ago, but sadly many other things
  had to take precedence so I didn't really have the time.

 No, that's unrelated. I suspect we'll hear something about that soon...
 Oh, I see Kevin let the cat out of the bag. Well, there you go :)


Awesome, that's good to hear!




  I agree that codecs that are usable by the system’s default media
  framework should work.  However, I believe that is already supported in
  most cases, is it not?
 
 
  It's not - JavaFX can decode the audio / video / container formats that
 it
  knows about through its GStreamer plugins, and nothing else (unless you
  compile them in yourself, which isn't all that hard.)

 Not entirely true... on the Mac, GStreamer does not support HLS, that gets
 routed through QTKit (for = 10.7) or AVFoundation (10.8+). With VP6 gone
 there will actually be no need for GStreamer on Mac at all.

Sorry, my mistake - I'm used to the media stack on Windows where this is (I
think) always the case.



 It *used* to be the case that we allowed anything the native platform
 provided, in the previous media stack (JMC if anyone was paying attention).

 The big issue, as Kirill pointed out, was it was very difficult to support
 due to the vast combinations of operating systems and codecs/media formats
 and (more importantly) there are security implications.

Perhaps a political issue as oppose to a technical one, but (on the support
side of things rather than the security side) would best efforts here
with a warning that it might not work 100% reliably be better than not at
all?


 There are internal discussions ongoing about how we're approaching this
 problem. The security aspects only affect webstart and plugin, standalone
 applications aren't as much of a concern (except from a supportability
 standpoint) so maybe some compromise can be reached.

Without wishing to drag this further off topic (perhaps it should be split
into a separate discussion!), from memory at the moment the Java code won't
allow any format down to the native layer (gstreamer) unless it matches one
of the types it's aware of. Would it be possible to remove this hard
requirement (perhaps with a flag?) If this was done then it would probably
be a small bit of boilerplate in the native layer to pass the stream down
to the relevant plugin. If it doesn't exist then we haven't lost anything,
if it does then the stream can be played without an issue.

This wouldn't change anything by default, but it would mean that anyone
could then drag custom gstreamer plugins into the correct JRE directory and
have them work straight off. Considering that many applications bundle a
JRE anyway these days, that would make it trivial for those who wanted to
to support any other codec / container type that GStreamer offered, and
would (presumably) remove the support / legal burden on Oracle of
distributing and maintaining these plugins. Hopefully that ticks the
sustainability and security boxes?

Michael


 I would actually favor allowing formats supplied by the underlying native
 platform over trying to figure out how to provide a pluggable codec
 interface, but it needs to be done in a way that's sustainable and does not
 expose security vulnerabilities.


 Again, I'm not promising anything, just know that complaints and requests
 have been heard and are being taken into consideration.

 -DrD-




-- 
Thanks,

Michael

Combobox issue with Windows 10

[Michael Berry]

After upgrading to windows 10, I've had many reports of users hitting this
issue (https://bugs.openjdk.java.net/browse/JDK-8132897) whereby clicking
any unfocused combobox in our application completely freezes it up.
(Interestingly, tabbing so the combobox is selected first before clicking
provides a workaround, but clearly this is not a good solution.) I haven't
been able to reproduce unfortunately, but it's certainly causing problems
our end and I can't imagine we're the only ones.

Has anyone else noticed this and been able to reproduce it more reliably? I
would look to contribute a fix, but not being able to reproduce makes it
pretty much impossible.

Michael

Re: Why Javafx UI hangs or become unresponsive on using Plarform.runLater() ?

[Michael Berry]

Perhaps a silly question - but do you really need millions of lines in the
text area? When you're displaying this much text then from my understanding
things are bound to hang (simply because of the processing overload) and
there's not really a great deal you can do about it. You can see if there's
any extraneous delay by profiling and seeing if there's any GC bottlenecks
(or suchlike) then tweak those options, but I doubt you'll ever get to no
delay at all with dumping this much data in a textarea.

I'm not aware of the details of your application, but can you just create
the text in memory somewhere else, and create an FX component that acts
like a text area, but dynamically reads the text in from memory as the user
scrolls? This way you'll just be altering a relatively small amount of text
much more continuously, and shouldn't notice much of a delay. (I took a
similar approach with Swing a long while ago for a project, but sadly can't
find the source for that now.)

Michael

On 19 October 2014 16:58, Navdeep Singh Sidhu 
navdeepsingh.sidh...@gmail.com wrote:

 Hello,

 I know this mailing list is for OpenJFX developers and to discuss
 development related issues. I don't know it is OK to post my query here or
 not. But i assume if you people are developing the OpenJFX, so there will
 be no other person better than you or have more knowledge related OpenJFX
 than you guys :) .

 My query is that i'm trying to develop an IDE for parallel computing
 integrated with framework and output from all nodes has to be represented
 in TextArea. I am using multiple threads to collect Output from all the
 nodes and appending that output on TextArea using Platform.runLater(), i am
 even using flags to reduce the flood on UI thread, that output will be
 appended if the output is larger than 5 lines then after each 5
 lines to TextArea else it will be appended as it is. Even submitting one
 task in the system, UI hangs when trying to print millions of line output
 on TextArea and i couldn't test it with multiple tasks. Can you suggest me
 something to prevent UI thread from becoming unresponsive. I know i'm not
 good programmer as you guys but i'm trying to learn JFX and new to this.

 BTW thank you guys for such a beautiful interface in JAVA. :)

 Regards
 Navdeep Singh Sidhu

British english on JavaFX controls

[Michael Berry]

Hello,

I'm trying to get the JavaFX controls (specifically the ColorPicker) to
display British English labels, that is Colour instead of Color, but
don't seem to be getting anywhere - do I need to do anything more than
setting the default Locale?

For instance:

public void start(Stage primaryStage) {
Locale.setDefault(Locale.UK);
primaryStage.setScene(new Scene(new ColorPicker()));
primaryStage.show();
}

...gives me the ColorPicker with the US spelling of color. (Setting the
locale to other languages seems to work fine.)

Any ideas?

Thanks,

Michael

Re: British english on JavaFX controls

[Michael Berry]

Thanks for the suggested fix - unfortunately though that doesn't seem to
work. The following:

@Override
public void start(Stage primaryStage) throws Exception {
Locale.setDefault(new Locale(en, UK));

System.out.println(ResourceBundle.getBundle(com/sun/javafx/scene/control/skin/resources/controls).getString(ColorPicker.customColorLink));
primaryStage.setScene(new Scene(new ColorPicker()));
primaryStage.show();
}

...prints out Custom colour (British spelling), but the control doesn't
pick this up.

Any idea if I could force a refresh on this somehow to get it to pick up
the british labels?

Thanks,

Michael

On 16 October 2014 13:37, Jim Clarke jimclar...@me.com wrote:

 Wouldn't you also have to fix the call to setLocale to en_UK?

 Sent from my iPhone

  On Oct 16, 2014, at 8:34 AM, Tom Schindl tom.schi...@bestsolution.at
 wrote:
 
  Looking at the com/sun/javafx/scene/control/skin/resources/controls
  package there's not extra properties file for en nor one for en_UK.
 
  Wild guess you can fix this is that you put such a properties file in
  exactly this package of of your application and it will be picked up.
 
  Tom
 
  On 16.10.14 14:06, Michael Berry wrote:
  Hello,
 
  I'm trying to get the JavaFX controls (specifically the ColorPicker) to
  display British English labels, that is Colour instead of Color, but
  don't seem to be getting anywhere - do I need to do anything more than
  setting the default Locale?
 
  For instance:
 
  public void start(Stage primaryStage) {
 Locale.setDefault(Locale.UK);
 primaryStage.setScene(new Scene(new ColorPicker()));
 primaryStage.show();
  }
 
  ...gives me the ColorPicker with the US spelling of color. (Setting the
  locale to other languages seems to work fine.)
 
  Any ideas?
 
  Thanks,
 
  Michael
 

Re: British english on JavaFX controls

[Michael Berry]

Hi Tom,

Sure, that makes sense, thanks for the info. Don't suppose there's a
workaround you know of?

This is for an application which has a bundled JRE, so I can potentially
just add the language file in the proper location - it'd just be nice to
have a fix that doesn't require modification if possible!

Michael

On 16 October 2014 15:20, Tom Schindl tom.schi...@bestsolution.at wrote:

 On 16.10.14 16:15, Tom Schindl wrote:
  Ok - it ResourceBundle.getBundle() uses the classloader of the caller
  which means the ExtensionClassloader so having the additional properties
  in your local dir does help.

 does NOT help!

 Tom

Re: British english on JavaFX controls

[Michael Berry]

Sure, JIRA is here: https://javafx-jira.kenai.com/browse/RT-39004

Afraid I'm not sure about AWT / Swing, I've never tried to add a
translation there!

Michael

On 16 October 2014 15:38, Stephen F Northover steve.x.northo...@oracle.com
wrote:

 Please enter a JIRA for the missing translation.  If AWT/Swing is missing
 a translation, is there a way to add it short of modifying the system?

 Steve


 On 2014-10-16, 10:28 AM, Michael Berry wrote:

 Hi Tom,

 Sure, that makes sense, thanks for the info. Don't suppose there's a
 workaround you know of?

 This is for an application which has a bundled JRE, so I can potentially
 just add the language file in the proper location - it'd just be nice to
 have a fix that doesn't require modification if possible!

 Michael

 On 16 October 2014 15:20, Tom Schindl tom.schi...@bestsolution.at
 wrote:

  On 16.10.14 16:15, Tom Schindl wrote:

 Ok - it ResourceBundle.getBundle() uses the classloader of the caller
 which means the ExtensionClassloader so having the additional properties
 in your local dir does help.

  does NOT help!

 Tom

Re: OT: Netbeans ported to JFX?

[Michael Berry]

It would be nice in a utopian sense - though I'd have to question if it
would really be worth the resources required?

Personally I'd be much more in favour of further development of JavaFX
itself...

Michael


On 9 July 2014 10:52, Tobias Bley t...@ultramixer.com wrote:

 very interesting question ;)

 Will there be a android and iOS version of Netbeans in the future ;)?


  Am 09.07.2014 um 11:40 schrieb Robert Krüger krue...@lesspain.de:
 
  Hi,
 
  it is a little off-topic but the people reading this list are most
  likely the ones who could answer this.
 
  Is a port of Netbeans to JFX planned or even ongoing? It would
  certainly be a huge project but I am asking myself, if there is a way
  around that with Swing being de-facto legacy if Netbeans isn't dropped
  as a whole. It would certainly demonstrate Oracle's commitment to JFX
  as the future for Desktop UIs and would surely help the maturity of
  JFX which IMHO needs tons of real-world apps to be thrown at it.
 
  I would not be surprised not to get an answer for all sorts of
  understandable reasons but I thought I'd give it a shot anyway.
 
  Best regards,
 
  Robert

Re: macosx fullscreen and window manager

[Michael Berry]

Hi Erik,

Not a full solution by any means - but in terms of the mouse pointer being
shown, you could just set a blank cursor using setCursor(Cursor.NONE) on
Scene.

Thanks,

Michael


On 31 March 2014 11:54, Anthony Petrov anthony.pet...@oracle.com wrote:

 Hi Erik,

 What you're asking for is kind of exclusive full screen mode (as it's
 known in AWT/Swing). And no, JavaFX does not support this currently. Please
 file a new issue in JIRA at https://javafx-jira.kenai.com/

 PS. Regarding your current code: you don't really need to call
 setResizable, setIconified, toFront, or centerOnScreen() because these
 calls are useless for a full screen window.

 --
 best regards,
 Anthony


 On 3/29/2014 4:06 PM, Erik Colson wrote:

 On March 29, 2014 12:43:18 PM CET, cogmission1 . 
 cognitionmiss...@gmail.com wrote:

 Hi,

 Just as a clarification, it sounds like what you're asking for is kind
 of
 like a Kiosk mode?


 On Sat, Mar 29, 2014 at 4:08 AM, Erik Colson e...@ecocode.net wrote:

  Hi,

 Is it possible to use JavaFX for developping a fullscreen macosx
 application that skips the window manager ? I have currently an app

 that

 does fullscreen but :
 - the 'hot corners' still work, letting the user switch to another

 app

 - the screensaver is still working
 - the mouse pointer is still shown

 The app is ment to become something like a Slideshow. Therefor those

 3

 points need to be solved.

 This is what I have for now:

 Screen screen = Screen.getPrimary();
 primaryStage.initStyle(StageStyle.UNDECORATED);
 primaryStage.setResizable(false);
 primaryStage.setIconified(false);
 primaryStage.setFullScreenExitHint();
 primaryStage.setFullScreen(true);
 primaryStage.setScene(scene);
 primaryStage.toFront(); // not really needed I think
 primaryStage.centerOnScreen();
 primaryStage.show();

 thanks !
 --
 erik colson


 Yep. That's it!
 --
 erik colson

Re: Adding GStreamer plugins

[Michael Berry]

Hi Kirill,

Ok, so with help from here (https://github.com/pgregory/libffi-msvc) I
think I've now got a VS project / makefile that builds libffi.lib, but I
can't work out how to get the build script to build the visual studio
project!

The project is in modules\media\src\main\native\vs_project\libffi, and I've
updated FXMedia.sln to include it - this builds ok, but the makefile then
expects the object files in
modules\media\build\native\win\Release\obj\3rd_party\libffi-lite (I
deliberately kept this structure for consistency with the other projects),
and I can't seem to work out where in the script they're copied across from
the visual studio project (I feel like this should be the easy bit of this
step!)

If I copy them there manually it works and builds libffi-lite.lib, but
obviously this isn't ideal - if it's not too much hassle could someone
point me at the relevant place?

Many thanks,

Michael


On 27 March 2014 08:58, Kirill Kirichenko kirill.kiriche...@oracle.comwrote:



 On 27.03.2014 03:53, Michael Berry wrote:

 Unfortunately I seem to have become a bit stuck at step one! I'm
 probably missing a few things that are rather obvious, but haven't
 really got much experience at all in this area, so am relying on
 haphazard Googling and a bit of guesswork! It may well be that updating
 the framework is a bit beyond my skillset for the time I have available
 at the moment, but I'll keep pushing on if anyone's willing to give me a
 bit of guidance on it.

 Yes. It's not trivial at all. You need to have enough patience to go
 through all the steps.


  Firstly libffi - I've downloaded that, put it in the 3rd_party folder,
 and have run ./configure, make, then make install (all under
 cygwin.) That seems fine; so I've now got libffi.a (as well as
 cygffi-6.dll) in 3rd_party\libffi\i686-pc-cygwin\.libs.

 The challenge here is first to build libffi with Mircosoft C compiler and
 linker. Here at the first stage you should take libffi and put it somewhere
 separately from javafx. Then try to build it with VisualStudio. Once you
 succeed you should create a makefile in the manner of javafx makefiles for
 Media. As the result of this step you'll get a bunch of C/Header files, the
 makefile. Everything else can be deleted. The resulting makefile should be
 able to build libffi.lib - statically linked library.

  I've then grabbed glib 2.40, placed that in the glib folder, and
 attempted the same process - this first complained about a lack of
 libiconv, so I grabbed that and set the appropriate flags to point to
 it, and now I get the following:

 /configure: error: in
 `/cygdrive/c/Users/Michael/Documents/JFX8/modules/media/
 src/main/native/gstreamer/3rd_party/glib/glib-2.28.8':/
 /configure: error: The pkg-config script could not be found or is too

 old.  Make sure it is in your PATH or set the PKG_CONFIG environment
 variable to the full path to pkg-config./
 /
 /
 /Alternatively, you may set the environment variables LIBFFI_CFLAGS and
 LIBFFI_LIBS to avoid the need to call pkg-config./


 For GLib you can disable iconv in configure. This is the next step. Let's
 start with libffi first.



 I'm assuming this is something to do with the fact it can't find libffi,
 but I'm unaware of how to tell it that libffi is in the given folder!
 I'm also assuming that calling config / make etc. manually is the way to
 go for the time being - I think I'd be at even more of a loss trying to
 integrate it into the gradle build script.

 The reason for this to be such non trivial is/was the download size. We
 aimed the minimal possible download size. This is probably not an issue
 anymore and we can switch to simpler solutions like you originally did -
 download, unzip, run configure and here we go.

 K

Re: Adding GStreamer plugins

[Michael Berry]

Hi David,

Sure - I'm aware there's legal issues surrounding many of the formats,
though one of the reasons I picked MKV to start with was because it's an
open container format. I'm certainly not aware of any restrictions
surrounding it (though please correct me if I'm wrong on that front!)

A switch certainly sounds like a good idea though, especially for formats
with more restrictions surrounding their use; I'll bear that in mind if I
add any additional plugins.

Thanks,

Michael

On 26 March 2014 02:03, David DeHaven david.deha...@oracle.com wrote:


  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

[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 kirill.kiriche...@oracle.comwrote:

 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

Re: Adding GStreamer plugins

[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 steve.x.northo...@oracle.comwrote:


 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

Re: Adding GStreamer plugins

[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 richard.b...@oracle.com 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

[Michael Berry]

Hi Scott,

Sure, that's in fact my eventual goal - but in order to successfully get
that far I need to work out how to compile OpenJFX with other GStreamer
plugins first, and unfortunately at the moment I seem to be getting stuck
at that hurdle!

Time permitting, I do indeed plan to look at addressing 2684 if I can get
that far.

Thanks,

Michael


On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote:

 I applaud your effort, but please consider while you are doing this:
 Addressing RT-18009 is good
 Addressing RT-2684 is way better.
 https://javafx-jira.kenai.com/browse/RT-2684

 If there is a mechanism to write a stub plugin that hooks into the
 GStreamer plugin mechanism such that end users of JavaFX can write a module
 (in Java, with the option of using JNI) that supplies the uncompressed
 frames via a NativeByteBuffer, that would be a great start.

 Scott


 On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote:

  Hi all,
 
  I've managed to clone and build OpenJFX successfully, and am now in the
  process of trying to see how feasible it would be to add support for
 other
  media formats. As a first port of call I'm attempting to see if I can get
  the framework accepting the Matroska plugin, but seem to be coming a bit
  unstuck on the native side of things (including the plugin with
 GStreamer.)
  I've made the relevant modifications on the Java side of things to
 persuade
  the platform to accept MKV files and pass them down to the GStreamer
 layer,
  and that compiles and runs without any issues.
 
  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?).
 
  - 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
 
  However, after the above I still get the same result having touched none
 of
  the native code, that being that GSTMediaPlayer throws a MediaException
  with flag 257, which seems to mean it couldn't create the required media
  from the given location.
 
  So at this point I'm a bit stuck really - of course, the whole task may
 be
  much more complicated than I'm assuming it should be. I'm not even sure
 if
  the default gradle sdk task is actually reflecting the changes I've
 made
  - certainly gstreamer-lite.dll seems to be exactly the same size as
 before,
  though I'm unsure if the additional plugin is meant to be embedded in
 this
  file or not. I'm experienced with Java but much less so with C++, and
  completely new to gradle (as of yesterday.)
 
  Is there anything obvious I'm not doing correctly, and if so would
 someone
  be kind enough to give me a bit of a nudge in the right direction?
 
  Many thanks,
 
  Michael




-- 
Thanks,

Michael

Re: Adding GStreamer plugins

[Michael Berry]

Hi all,

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.

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!

 - 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.)

 - 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.

 - The DirectX SDK failed to install for me, Googling found the fix
relatively easily (
http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023),
but perhaps this could be included just for reference.

 - 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?

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!

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?

Many thanks,

Michael




On 23 March 2014 15:32, Michael Berry berry...@gmail.com wrote:

 Hi Scott,

 Sure, that's in fact my eventual goal - but in order to successfully get
 that far I need to work out how to compile OpenJFX with other GStreamer
 plugins first, and unfortunately at the moment I seem to be getting stuck
 at that hurdle!

 Time permitting, I do indeed plan to look at addressing 2684 if I can get
 that far.

 Thanks,

 Michael


 On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote:

 I applaud your effort, but please consider while you are doing this:
 Addressing RT-18009 is good
 Addressing RT-2684 is way better.
 https://javafx-jira.kenai.com/browse/RT-2684

 If there is a mechanism to write a stub plugin that hooks into the
 GStreamer plugin mechanism such that end users of JavaFX can write a module
 (in Java, with the option of using JNI) that supplies the uncompressed
 frames via a NativeByteBuffer, that would be a great start.

 Scott


 On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote:

  Hi all,
 
  I've managed to clone and build OpenJFX successfully, and am now in the
  process of trying to see how feasible it would be to add support for
 other
  media formats. As a first port of call I'm attempting to see if I can
 get
  the framework accepting the Matroska plugin, but seem to be coming a bit
  unstuck on the native side of things (including the plugin with
 GStreamer.)
  I've made the relevant modifications on the Java side of things to
 persuade
  the platform to accept MKV files and pass them down to the GStreamer
 layer,
  and that compiles and runs without any issues.
 
  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?).
 
  - Added all the C files from the first folder mentioned above to the
  plugins.vcxproj file
 
  - Added the relevant files and directory

LNK1123: failure during conversion to COFF when building under windows

[Michael Berry]

Hi,

I'm currently trying to build OpenJFX from source on Windows - I've
followed the instructions on the build page and have Visual Studio 2010,
the June 2010 directx sdk, cygwin and its relevant modules installed.
However, when building it fails at the buildJavaFXPackage task (output
below.)

I'm not sure if those warnings are normal or not, but they definitely look
suspicious. It seems the actual error that's stopping things is the fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt
line, though all I've found searching around for that error is that
incremental:off should be set to avoid it, which it already is in the
gradle task.

Any ideas?

Thanks,

Michael

:fxml:jar
:fxml:assemble
:fxpackager:buildJavaFXPackager
javafxpackager.cpp
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258)
: warning C4018: '' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269)
: warning C4018: '' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286)
: warning C4018: '' : signed/unsigned mismatch
C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426)
: warning C4996: 'getenv': This function or variable may be unsafe.
Consider using _dupenv_s instead. To disable deprecation,use
_CRT_SECURE_NO_WARNINGS. See online help for details.
C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal
error LNK1123: failure during conversion to COFF: file invalid or corrupt
:fxpackager:buildJavaFXPackager FAILED

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817

* What went wrong:
Execution failed for task ':fxpackager:buildJavaFXPackager'.
 Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio
10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123

Re: LNK1123: failure during conversion to COFF when building under windows

[Michael Berry]

Hi Kevin,

Many thanks for that - that has solved the problem! Perhaps the wiki
pagehttps://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFXshould
be updated to note that SP1 should be installed as well as vanilla
VS2010? I would do it myself, but don't have the privileges.

Thanks,

Michael


On 22 March 2014 14:46, Kevin Rushforth kevin.rushfo...@oracle.com wrote:

  Do you have VS 2010 Service Pack 1? I've seen this failure on machines
 that don't have SP1 installed.

 -- Kevin



 Michael Berry wrote:

 Hi,

 I'm currently trying to build OpenJFX from source on Windows - I've
 followed the instructions on the build page and have Visual Studio 2010,
 the June 2010 directx sdk, cygwin and its relevant modules installed.
 However, when building it fails at the buildJavaFXPackage task (output
 below.)

 I'm not sure if those warnings are normal or not, but they definitely look
 suspicious. It seems the actual error that's stopping things is the fatal
 error LNK1123: failure during conversion to COFF: file invalid or corrupt
 line, though all I've found searching around for that error is that
 incremental:off should be set to avoid it, which it already is in the
 gradle task.

 Any ideas?

 Thanks,

 Michael

 :fxml:jar
 :fxml:assemble
 :fxpackager:buildJavaFXPackager
 javafxpackager.cpp
 C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(258)
 : warning C4018: '' : signed/unsigned mismatch
 C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(269)
 : warning C4018: '' : signed/unsigned mismatch
 C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(286)
 : warning C4018: '' : signed/unsigned mismatch
 C:\Users\Michael\Documents\JFX8-dev\modules\fxpackager\src\main\native\javafxpackager\win\javafxpackager.cpp(426)
 : warning C4996: 'getenv': This function or variable may be unsafe.
 Consider using _dupenv_s instead. To disable deprecation,use
 _CRT_SECURE_NO_WARNINGS. See online help for details.
 C:/Program Files (x86)/Microsoft Visual Studio
 10.0/VC/INCLUDE\stdlib.h(433) : see declaration of 'getenv'LINK : fatal
 error LNK1123: failure during conversion to COFF: file invalid or corrupt
 :fxpackager:buildJavaFXPackager FAILED

 FAILURE: Build failed with an exception.

 * Where:
 Build file 'C:\Users\Michael\Documents\JFX8-dev\build.gradle' line: 1817

 * What went wrong:
 Execution failed for task ':fxpackager:buildJavaFXPackager'.


  Process 'command 'C:/Program Files (x86)/Microsoft Visual Studio


  10.0/VC/BIN/link.exe'' finished with non-zero exit value 1123

Adding GStreamer plugins

[Michael Berry]

Hi all,

I've managed to clone and build OpenJFX successfully, and am now in the
process of trying to see how feasible it would be to add support for other
media formats. As a first port of call I'm attempting to see if I can get
the framework accepting the Matroska plugin, but seem to be coming a bit
unstuck on the native side of things (including the plugin with GStreamer.)
I've made the relevant modifications on the Java side of things to persuade
the platform to accept MKV files and pass them down to the GStreamer layer,
and that compiles and runs without any issues.

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?).

 - 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

However, after the above I still get the same result having touched none of
the native code, that being that GSTMediaPlayer throws a MediaException
with flag 257, which seems to mean it couldn't create the required media
from the given location.

So at this point I'm a bit stuck really - of course, the whole task may be
much more complicated than I'm assuming it should be. I'm not even sure if
the default gradle sdk task is actually reflecting the changes I've made
- certainly gstreamer-lite.dll seems to be exactly the same size as before,
though I'm unsure if the additional plugin is meant to be embedded in this
file or not. I'm experienced with Java but much less so with C++, and
completely new to gradle (as of yesterday.)

Is there anything obvious I'm not doing correctly, and if so would someone
be kind enough to give me a bit of a nudge in the right direction?

Many thanks,

Michael