3 ms·
It worth noting, that the application is written in JavaFX. For the text-hovering, what you are experiencing, is the default behaviour for JavaFX. The scrolling
by floriankirmaier 4y ago
It worth noting, that the application is written in JavaFX.
For the text-hovering, what you are experiencing, is the default behaviour for JavaFX.
The scrolling is also (sometimes) from JavaFX.
You are right, behaving like a normal website is very important.
Your observation with the scrolling is right.
https://www.jpro.one/ https://www.jpro.one/ uses the browser scrolling.
https://www.jfx-central.com/ https://www.jfx-central.com/ uses the scrolling of JavaFX, which is still a bit slow due to the hight traffic.
The text-selection is actually from the browser. The question remains why it behave different - which is something to improve.
Because we are using normal text elements (and normal links) the site is also indexed by google.
- nextaccountic 4y agoOh, this, like, renders JavaFX using the DOM? Wow, despite my criticisms from before, your project is very impressive! And there's lot of value in porting existing desktop apps to the web with minimal effort. Is there something from JavaFX that can't be represented in the DOM and then you need to lower to <canvas>? I'm thinking for example JavaFX charts, or maybe custom widgets > The scrolling is also (sometimes) from JavaFX. (...) Your observation with the scrolling is right. https://www.jpro.one/ https://www.jpro.one/ uses the browser scrolling. https://www.jfx-central.com/ https://www.jfx-central.com/ uses the scrolling of JavaFX, which is still a bit slow due to the hight traffic. But does JavaFX scrolling requires network requests? Are you like running JavaFX in the backend and making a network request for each scroll in https://www.jfx-central.com/ https://www.jfx-central.com/? And https://www.jpro.one/ https://www.jpro.one/ doesn't need this because the scroll is handled by the browser > You are right, behaving like a normal website is very important. Well I think that if you have this as a goal your project will surely improve. The text hovering one seems like a low hanging fruit: if you go through each widget you can verify what mouse cursor browsers typically use for that by default (for example, <button> is a normal cursor, <textarea> is an edit cursor, <a> is a clicking hand, etc), and use this by default (perhaps with an option to use the JavaFX defaults if someone wants them).
- invalidname 4y agoNo. It renders FX using Canvas or GL. Not the DOM. This seems to have lots of problems related to size, accessibility, etc. The implementation is pretty impressive. It's not as slow as some other previous attempts. It's "only" 1mb for a hello world 3+ for anything "decent". Both of these numbers are good for Java FX but they come with a lot of caveats. E.g. accessibility seems to be broken. Performance is lagging and rendering looks "off" because it uses the FX rendering instead of system rendering. Ultimately, FX lost the battle for the desktop, mobile, etc. this is an attempt to make it relevant again but unfortunately nothing will help FX at this point. It's a solution designed to combat Adobe Flash trying to compete in 2022. The RIA wars are over.
- nextaccountic 4y ago> It renders FX using Canvas or GL So the text selection is done by javafx too? But the comment above implied that the text selection was done by the browser
- invalidname 4y agoThere's no text selection when you run FX code. See the demos section.
- nextaccountic 4y agohttps://www.jfx-central.com/ https://www.jfx-central.com/ is listed as a demo and it has text selection
- invalidname 4y agoNot universally. Notice the widgets that have text selection seem like HTML. That's because they are. FX supports embedding HTML. But then it scrolls oddly.
- floriankirmaier 4y ago