I experimented a bit with mouse-wheel scrolling an...

# compose-desktop

[Michael Paus]

I experimented a bit with mouse-wheel scrolling and I am wondering why it is so different from pre-existing solutions (e.g. JavaFX).
1. Why is the sign of scrollDelta.y just the opposite of the one from JavaFX.
2. Why is the value so different? A single mouse-wheel tick is +-0.1 for Compose but +-1.0 for JavaFX.
3. What is the meaning of the scrollDelta offset values?
4. Is there a way to distinguish text scrolling from pixel scrolling?
5. There does not seem to be a possibility to distinguish different event sources. E.g. it is important to distinguish between a scroll event from a mouse-wheel or an attached trackpad because you might want to perform a different action depending on the source.
6. Is it possible that not all the associated API is accessible from commonMain?

[Kirill Grouchnikov]

Not answering for the team, but. Why would JavaFX - or any other UI toolkit - be the "golden" standard for 1 and 2? Maybe you have prior experience with that particular toolkit, but that doesn't mean that a new toolkit is supposed to follow its conventions - unless there's an overwhelming majority of prior "agreement" across multiple major toolkits.

As for number 5 - how do you envision this working across a variety of input devices. Some more commonplace like mousewheel and trackpad, but some perhaps more esoteric. And some that haven't been invented yet. How would a UI toolkit address this? And how would something like "SourceUnknown" be a great fallback choice?

[Michael Paus]

1. JavaFX is certainly not the gold standard. That’s why I said “e.g.“. I just think it is wise to follow established standards if there is no compelling reason to deviate from them. I haven’t checked it but I think Swing, e.g., is following the same convention.
2. In JavaFX the value has a documented meaning. It is supposed to be roughly equivalent to 1 pixel. For Compose this value is vastly different and does not seem to have any documented meaning.
5. Why not handle what you know and mark the rest as unknown. Always looking for a 100% solution leads to nowhere. (May I dare to say that JavaFX does make this distinction?)

[Kirill Grouchnikov]

To be honest, and my personal opinion of course, but JavaFX is a mere footnote in the landscape of desktop UI toolkits. Not to mention that while this channel is for the desktop variant of it, Compose is not a desktop-only toolkit. It builds on top of Swing for windowing APIs, but I don't see a good argument to be made for its APIs (across mobile, desktop and hopefully soon web) to be driven by a particular desktop toolkit.