@permalmberg I know how that is 🙂

@permalmberg What if you record

pane.content.boundsInParent.height

before the scroll starts and check it again when the scroll ends - wouldn't that give you the precise value?

I'm drawing an line (and updating it as the mouse moves) between point x,y and x2,y2 and it works fine as long as the scrollpane is at its "home" position. As soon as it scrolled, I get an offset...

Hm.. I guess height is not what you would need to record, but maybe

y

or something?

Sorry, forget what I said, I guess that doesn't change when you scroll.

No, it doesn't.

what I posted above is the closest I've managed so far

Next idea. What about the scrollpane's

viewportBounds

value?

Been there - it also seems to remain unchanged

the only thing that changes (afaik) is

pane.vvalue

I'm thinking that I need another height than what I'm using so that the math is correct regardless of how much I scroll

What about comparing

layoutBounds

to

boundsInLocal

?

hm, possibly. Though there ought to be a "correct" height that works with

vvalue

`layoutBounds`and

boundsInLocal

are the same before and after scrolling

of

scrollpane.content

that is

dinner, bbl

@edvin yeah let's take COMPONENT and GLOBAL. Is there a reason way we use proprty files instead of json I think Json is more flexible?

@porokorodev has left the channel

@User uploaded a file: Changing Y during scrolling and commented: @permalmberg This comes at the scrolling from a different angle. Instead of trying to the internal scrolling values, key off of the contents. You have to use the Scene coordinates since the local and parent coordinates won't change; they'll always refer to a full-sized container that can exceed the current view.

@carlw I actually just solved it. Using `pane.viewportBounds.minX`and `pane.viewportBounds.minY`was what was needed

@permalmberg good. you can also track the parent vbox in my example instead of the individual labels in case they come-and-go

@nimakro It's possible to change to JsonObject, but there are a couple of caveats. First, it would partly break the API, because the

config

field would be of a different type. That's not a big deal because of the way it's used though (`config.set`/`config.save()` etc), so we would just need to make sure we add those functions to

JsonObject

. The biggest issue is that

JsonObject

is not writable, so the

set

function etc would need to do a Copy On Write and create a new

JsonObject

. Not hard to do, but still. The config object should be of type

tornadofx.Config : JsonObject

, or something so we can add the appropriate save function. The

Config

object also needs a field for the type (

COMPONENT

or

GLOBAL

) so it knows where to save itself.

@permalmberg Sweet, good to know.

@edvin @nimakro I prefer the flat properties file because it’s easier for an operations person to edit. You should validate all the properties anyway, but the ops people might need a JSON validator to make sure that all the brackets and quotes line up.

@carlw I agree with that, and I see that it would add some complexity to support it as json. Making

javax.json.JsonObject

is also a bit tricky, since a copy on write would result in a new instance, and that would be very problematic if the user kept a reference to it. I think we'd actually need to reimplement the whole thing. I think there is a mechanism we can plug into so we can return

TornadoJsonObject

instead, so it might be possible to do cleanly.

@carlw I agree, but if you have a few hierarchies in the file then the keys in the property file get long and ugly.. But we can keep the properties for now and change it later if we want to, or we could even allow to define in the application if it should store it as json or flat files.

The benefit of Json is that it can hold arrays etc. that gets cumbersome in a flat properties file. just my 2 cents

@permalmberg A value can be a JsonObject of arbitrary depth.

@edvin Why would we have to copy the

JsonObject

on write?

@nimakro Because

JsonObject

isn't writable.