I'm thinking of moving OSGi section to Appendix B.

What will be beneficial about leveraging the Appendix sections is we can feel less bad about evolving content there and documenting prototyped/experimental/cutting-edge functionality while leaving the core functionality documentation alone. That way we can have a "published" book quickly but allow the Appendix to evolve post-publishing.

By the way @edvin, @Ruckus, and whomever else is interested... can you review my proposal for the Kotlin stdlib to add

moveXXX()

functions to

List<T>

? JetBrains looks to be interested in implementing them, and I am doing my best to design it up to their standards.

The latest implementation is here... https://github.com/thomasnield/kotlin-collection-extras/blob/master/src/main/kotlin/MutableListMoveExt.kt

just to mention jpro also does not support Canvas at the moment...testing it t home at the moment...

@hansolo_ Ah, lame. I guess I'll have to shelve that idea for a while.

@thomasnield I'll try to get to it today

well it's impressive and useful for special kind of apps. I hope they will come up with Canvas support in the near future. The problem is that they use a SVG tree in the browser where Canvas doesn't really fit in and might lead to slower performance. This might really be a problem where Canvas is a "node saver" on the JavaFX scene graph

That makes sense. There's just an app I've been working on that uses Canvas rather heavily as I didn't want to create a whole bunch of new custom nodes and panes. Maybe I'll have to suck it up and go all in.

You're repos and Friday Fun Components are super awesome and helpful by the way. Thanks 🙂

@thomasnield - I think that column resizing should remain with the tableview functionality in the guide - it's a common requirement when working with tableview that TornadoFx makes really easy. Just my 2 cents 🙂

@thomasnield I think I agree with Grant about the resizing. It's a feature almost everybody would want to use I think. If you want to keep it in the appendix, maybe we could just mention it and refer to it together with the table info at least?

@thomasnield I looked at your code for the Kotlin proposal when you posted it and I think it looked good. I also think the names for the functions are good, allthough I suspect JetBrains might have something to say about a few of them to make it fit even better with the other collections functions.

@edvin @gtnarg that's what I was going to suggest next, just referring to the Appendix from the chapter. Also will put in a bit about the resizeColumnsToFitContent() function.

@edvin thank you!

@thomasnield Sweet. I find myself removing the

resizeColumnsToFitContent

and just replacing it with

columnResizePolicy = SmartResize.POLICY

all over btw. It seems to be very useful and it gives JavaFX tables a much more polished look just by applying it.

@hansolo_ I kind of hope JPro ends up with going the TeaVM road that Jonathan mentioned. Then we would actually be running JavaFX in the browser and it would enable a whole host of new app possibilities that just aren't practical when everything is running on the server. I wonder if startup time and performance would ever be good enough though.

@edvin What about Kotlin's JavaScript interop?

@carlw Without the JavaFX runtime loaded into the JavaScript VM that doesn't get us closer to JavaFX in the browser, but it is still a very interesting project. I think some new shiny HTML5 frameworks will pop up when that thing is final 🙂

@edvin How would TeaVM get the JavaFX runtime into the browser? Doesn't someone still need to translate VBox into a <div>?

@carlw I think they would need to implement the complete graphics pipeline, but they have kind of already done that at JPro with the server-side version.

The amount of code needed in the JavaScript VM would be huge however, so I'm unsure if that will ever be possible. I just saw that Jonathan mentioned it and found it extremely intriguing.

(Well, it could be possible with a reimplementation of all JavaFX APIs. In fact, I think that's the only possible solution, but that undertaking is brutally huge, even compared to what they have already done)

@carlw But no, they don't translate a VBox to a div, they render the JavaFX UI as a huge SVG blob. Right now it is updated using a binary websocket transport, but that could be changed to something running inside the JavaScript client.

@edvin I was writing about Kotlin JavaScript interop to translate VBox to a div or a VBox into GWT...

That's what the JPro guys told us at JavaOne...so let's hope they will manage to get that done soon 🙂

@hansolo_ Oh my.. if that day ever comes :)))

@edvin Maybe the easiest thing to do is a global search on Plugin and replace it with "Browser Extension" to get the JVM back on the client side

@carlw Indeed. I think it's sad that we weren't able to support Java via a browser plugin in a secure way. It should be just as doable as supporting JavaScript in the browser. That's where the real solution to the web lies IMO 🙂 Sadly, I don't think it will ever happen. Suddenly we could be running JavaFX and all the JVM languages on all desktops and mobile platforms in the world.