Always better to check, but for most operations JavaFX is really fast. Excited to see what you come up with!

For the moment, I base my work on D3js because a lot of work as been done here. But it’s very close to svg and dom. The challenge will be to find how to manage differently some parts which will not be compatible. The main point is the d3-selection which is the heart of data binding in d3 and heavily based on DOM.

@gaetan is d3-selection that important? If a visualisation doesn't benefit from the general update pattern d3-selection feels very cumbersome to use without providing many benefits.

@teedee I have no definitive thought on that now. I find this pattern not very understandable. But I want to be sure that we can create all use cases without it. So we’ll continue our experiments before taking any definitive decision.

For this experiment : http://data2viz.io/dist/voronoiSphere.html I used something very similar to d3-selection. I must try some other implementations.

In that case, I found that d3-selection was a trick, a workaround on svg rendering limitations. In the browser, when you have an animation, all the code is ran before rendering. You can remove some elements (lines in that case) and add others but the rendering phase is not done in the same order. So you can still have the removed elements and the added ones. It’s very ugly. Using the d3-selection pattern, you reuse elements you planned to remove, by translating them.

yes I think I get it. That's the most defining part about d3-selection I think, being able to see what is coming in and what is leaving the visualisation. However I think the fluent api for selecting and appending elements to svg's could be replaced by a kotlin builder but looking at the example dsl in the data2viz repo it seems you're already doing something like that.

Yes the fluent API of d3 is not understandable. You never know at what level you are. Kotlin’s DSL can be a great alternative here, and with code completion…

An example:

g {
            transform {
                translate(margin.left, margin.top)
            }

            rect {
                width = totalWidth - margin.horizontalMargins
                height = totalHeight - margin.verticalMargins
                fill = rgba(0, 0, 0, .1)
            }

I think it’s way more understandable.

Yes, a complete svg kotlin builder would be an enormous advantage over d3's fluent api. React is also declarative but JSX is still rather limited. With this you have the full power of Kotlin while constructing visualisations. it looks incredibly promising

Hello! I have a model extending ItemViewModel, and I want to make a fragment to view the item in the model. But if I try to inject it, specifying the type ItemViewModel (private val model: ItemViewModel<WeekTimetable> by inject()), and setting in the scope instance of class WeekTimetableDataModel : ItemViewModel<WeekTimetable>, than it does not work. I plan to use this fragment in several other places, can it be achieved without the need to specify WeekTimetableDataModel class explicitly in the body of viewer fragment?

No, you have to specify the exact type you want to have injected. If you think about it, what if you had two scope instances that extended from

ItemViewModel<WeekTimetable>

- how would the framework choose? What you could do however, is pass a parameter to the Fragment, and use

find(specificSubclass)

to look up the ViewModel instead.

We have an interesting bug report on issue #362. It looks like this is the first time extensions functions are biting us a little. Not sure what the best solution would be: https://github.com/edvin/tornadofx/issues/362

I think one possible solution would be to create a subclass of

Properties

instead, and make the extension functions now defined on

Properties

into real functions on that subclass instead.

Yeah, that seems to be working.

Another nice bonus of this fix was that the inline function to create a jsonModel didn't need to be repeated in

Component

and

App

. It's the only extension function in there that used reified generics, so it had to be treated specially until now.

@edvin Thank you! That actually makes sense 😉

@borboss Did you implement a solution to your issue or do you need some help?

@edvin Thanks! I made a workaround, I use “advanced” model for editing, that is a descendant of ItemViewModel only in one place. So in the editor I just put an extra simple ItemViewModel in the scope, that is bound to the WeekTimetableDataModel. A bit ugly, but works 😉

OK. Is your code public?

@edvin Yeah, sure. I’ll post a nice example today a bit later 😉

Great! I would like to see if we can do something smoother here 🙂

@ron Was the

--stopOnUpDateErrors

function only intentioned to be used from the command line, and not configured with the deployment?

@User uploaded a file: my crazy code

@edvin I suppose that with such code I have much more serious problems, that injecting ItemViewModels, but I tried to make an example, of what I was doing with tornadofx 😉

Hehe, I admit I do have some questions about that code 🙂 Will look at it in more detail later today!

Just wanted to share with you all one of the reasons I've been less productive lately. I'm creating a Kotlin Video course for Packt 🙂

I'm done with the outline and I'm about to finish the first section (today).