<_davinci_>
enebo: as you can see in this link (https://openjfx.io/openjfx-docs/#install-javafx), it is possible to compile a JavaFX Helloworld refering installation dir. I have done it and the dir only has the jar files, so I think it is enough with that.
nirvdrum has joined #jruby
<_davinci_>
Hi
_davinci_ has quit [Quit: WeeChat 2.9]
david2 has joined #jruby
ruurd has quit [Quit: bye folks]
david2 is now known as _davinci_
nirvdrum has quit [Ping timeout: 272 seconds]
<enebo[m]>
doh he left...but yeah Java module stuff allows stuff to load somehow which I am unaware of but the location of the sdk is why it can work so it can load those shared libraries
zacts has quit [Quit: leaving]
zacts has joined #jruby
nirvdrum has joined #jruby
<_davinci_>
enebo[m]: I am here :)
<_davinci_>
But I think they are Java shared libraries, not JavaFX specific
<_davinci_>
In fact, I can compile HelloWorld and use packages downloaded by Maven and moved to the script directory
<_davinci_>
But I can't do the same with my JRuby example :(
<_davinci_>
And the jars are the same
<enebo[m]>
_davinci_: I am wondering if Java modules are doing the loading. I mean I have worked with JavaFX since it started and it has always required the native component to work
<enebo[m]>
byteit101: are you around?
<_davinci_>
enebo[m]: in that case, JRuby should proceed in the same form, I think. What can be out in JRuby for not performing the same load? I don't understand what is missing :(
<enebo[m]>
Are you doing those module adds on the jruby command line?
<_davinci_>
Yes, as with the Java HelloWorld example
<_davinci_>
Yes, in that form. But it doesn't work
<enebo[m]>
I can try after lunch. I am guessing module-path will add jmods which load the native bits but perhaps there is something we do not support well with modules
<enebo[m]>
but if that is the case I do not see why you would include all the jars
<enebo[m]>
or even have them...they would be in the sdk
<enebo[m]>
unless your problem is all those jar requires in the first place?
<enebo[m]>
gotta eat though...be back in 30
<_davinci_>
JavaFX is not included with OpenJdk
<_davinci_>
Great. If you discover something I'll read your results :)
<headius[m]>
NameError: missing class name (`javafx.application.Application')
<headius[m]>
oh I'm on a bad branch
<enebo[m]>
yeah but nonetheless I am there now as well
<enebo[m]>
if you add-modules then it gets mired loading those before hitting the script
<enebo[m]>
I predict module incantation is right or whatnot then the Application error goes away
<enebo[m]>
If I remember right we get a more interesting error if we java_import with a string
<enebo[m]>
shoot need to be afk about 20 minutes
<headius[m]>
I'll poke at it a bit
<_davinci_>
=8)
<headius[m]>
if I do `java --module-path /Users/headius/Downloads/javafx-sdk-15/lib --list-modules` it does print out all the javafx modules
subbu is now known as subbu|lunch
<headius[m]>
well I got past that but I don't think this is going to work this way
<headius[m]>
it's supposed to be HelloFX.launch which calls Application.launch which reflectively instantiates the class and calls start (I think) and that won't work with JRuby extension
<headius[m]>
ugh
<headius[m]>
it seems like you can't have two --module-path or the second one wipes out the first
<headius[m]>
the command line ends up using two of them if you just add this to JAVA_OPTS:
<headius[m]>
byteit101: I'd like to chat with you about launching javafx apps and maybe we can come up with a patch for them that doesn't require all this class reflection nonsense
<headius[m]>
enebo: and you too
<headius[m]>
I dipped my toe into proxy generation and it may be possible to create a no-arg constructor that would be suitable for javafx to call
<headius[m]>
it would basically do the work of calling the Ruby new+initialize and then the proxy class constructor using a cached runtime instance
<headius[m]>
the bigger and better solution would be to add something to javafx that allows booting from an instance rather than a class
<enebo[m]>
So it is a little different and likely is a copy of the launcher. byteit101 did this originally for fxml support I think so I do not recall how we originally did it
<_davinci_>
It seems there is some advance with JavaFX :)
<enebo[m]>
_davinci_: I totally forgot how much effort we put into making fx work in jrubyfx.
<enebo[m]>
Most of the original work was 2013ish and some earlier as @nahi had originally did it as a much much smaller library
<_davinci_>
I think using JavaFX without jrubyfx should be enough
<_davinci_>
Perhaps jrubyfx adds some great magic, but I don't know it
<enebo[m]>
_davinci_: it definitely is possible but there is some work
<_davinci_>
Much work?
<enebo[m]>
jrubyfx does three things 1) this initial boostrapping/setup 2) Ruby DSL which can be simpler than scripting the Java 3) ability to more easily use JavaFX XML
<enebo[m]>
those links above show the two parts of bootstrapping
<enebo[m]>
if you want to make your own base concrete class in Java and use that as Application then maybe you do not need to do as much work
<enebo[m]>
since that class will be reflectable like headius shows in that version of launch() and it will background startup the backend for you
<_davinci_>
One thing I saw in jrubyfx was the possibility of defining handlers with Ruby blocks. I missed the option of defining what in JavaFX call "filters" in the same form
<enebo[m]>
if the last argument for the filter is an interface you should still be able to do that
<enebo[m]>
just pass a block and if it is an interface it will just call the block as if it was the method on the interface
<_davinci_>
Oh, great :)
<enebo[m]>
in some cases I think we do just add a method which will accept a block though
<enebo[m]>
on JRuby side the java we are calling can add additional methods that the ruby side can see
<_davinci_>
What kind of methods?
<enebo[m]>
well it you had a method in java setFilter but it did not have an interface as last arg you could just 'def filter(&code)... on that Java class
<enebo[m]>
the impl of that would call setFilter and do the thing Java expects
<enebo[m]>
The ruby side of things can now use this more friendly method
<enebo[m]>
The Java side cannot actually see it so that is a limitation but it is very useful at times
<enebo[m]>
So this is a case where to_a and to_ary end up being useful for coercion within Ruby itself so we just add them and then Geometry instances are usable in that way
<enebo[m]>
jrubyfx core_ext where we do this is pretty elaborate we wrote a lot of infrastructure around converting so it looks a little less obvious in how do some of this stuff