5 ms·

The omission of SWT made it very hard to read for me. It's really only relevant for the introduction (on the low level that a skia binding is, SWT is surely jus

by usrusr 6y ago

The omission of SWT made it very hard to read for me. It's really only relevant for the introduction (on the low level that a skia binding is, SWT is surely just going through AWT), but echoes of the omission still bounced around in my head in the later bits, distracting me. A quick dismissal (good or not) would have made the rest much easier to read. Unfortunately I find the last part a bit confusing: is this the lower level of the stack that beneath Compose Desktop? How is skiko related, or is it unrelated? Apparently Compose Desktop is built on Skijo (the github readme is much less confusing). Apparently the skiko build is also consuming skija as a dependency (in some very interesting ways, apparently planet kotlin still does enough java to lombok it), but the presentation on the blog would benefit a lot from a healthy dose of clear "that uses this" bragging. All in all as a slowly greying java guy, it's amazing to see this entirely unexpected breath of fresh air for the JVM. In this age of new desktop apps having been given up completely to electron and the like, desktop JVM could see a surprising renaissance as a lesser evil.

MaxBarraclough 6y ago
> SWT is surely just going through AWT Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. > desktop JVM could see a surprising renaissance as a lesser evil I'm not convinced that a whole new toolkit is the solution, with all the challenges that brings (lots of widgets to create, internationalisation, accessibility, multiple platforms to test on, etc). I figure the better move would be to work on improving JavaFX. As far as I can tell it's a pretty solid GUI toolkit, albeit one with little adoption. edit Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. Expecting the user to install the JVM isn't good enough, the application should bundle a JVM, or use ahead-of-time compilation. The user should never be made aware of what language you built the program in. As I understand it, OpenJDK has been making solid progress on the latter option. (And Excelsior JET no longer exists.)
- usrusr 6y ago
  > Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.
  - MaxBarraclough 6y ago
    > What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? I don't think SWT makes any use of AWT, I believe it does the latter. > SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop The article is making the case for a whole new GUI toolkit for Java, without making a persuasive case against JavaFX (I'm not convinced that its performance is a problem), and without mentioning SWT, the foremost 'unofficial' desktop GUI toolkit for Java. Skija may have its merits as a platform for 2D graphics, but that's not the point. Incidentally, the article's title is misleading. It's about GUI toolkits, not graphics libraries.
    - usrusr 6y ago
      The whole new GUI toolkit in question is Compose Native and that's not entirely new (only the desktop part is). Literally millions of Android devs would already feel more at home with it than with any other desktop UI toolkit. Maybe it's a bit dishonest to present Skija as if it was made for any other reason than to enable Compose Desktop, but it's very laudable to have the ambition to be more than an enabling component of that.
- usrusr 6y ago
  And about your edit, it's true of course, this is an issue. If you bundle the JRE feels wasteful and if you don't it feels uncaring for the less technical. Didn't JavaFX, beside being "Swing 2", consist of some native launcher component that would connect with an installed JRE if available (and sufficiently modern) and guide the user through download/installation if not? Memories are faint. Many similar approaches have been done, but none became a conveniently dominant go-to solution. Perhaps AOT compilation will finally bring a JRE bootstrapper component that is sufficiently "java" to find a wide footing in the java dev community and sufficiently friendly to end-users to end all "but maybe that other tool is even better" that kept all existing approaches niche.
- ksec 6y ago
  >Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. I just download Netbeans, this is 10+ years since I touch a Swing / Java apps. And nothing has changed, it still looks Java. It is still heavy, although start up speed are now better. But generally speaking an Electron Apps ( VS Code ) looks and works better than that. Eclipse is still better look wise, as it was 10+ years ago. That was basically the reason why I choose SWT back then. But it is still not perfect. So I decide to check out another consumer Desktop App from similar era, Vuze, or used to be called Azureus. And it is the same, Desktop Java Apps. And yes that was the reason why no many were using Consumer Desktop Java Apps. They dont look good, heavy on resources, need JDK etc.... As if nothing has changed in the past 15 years. I remember I was trying to use GCJ and SWT for Desktop Apps then, it was just too hard. I gave up. And it seems no one cares about decent, java desktop apps.
  - MaxBarraclough 6y ago
    > it still looks Java I think the Nimbus look is ok. [0] > It is still heavy, although start up speed are now better. It's certainly heavy. iirc NetBeans spins up over 20 threads even if you're not doing anything. As for startup times, is this on the same hardware? I imagine SSDs must help with NetBeans startup. > trying to use GCJ and SWT for Desktop Apps then, it was just too hard. There was a proprietary payware alternative to GCJ called Excelsior JET but it was discontinued 2 years ago. [1] [0] http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Screenshot_NBLookAndFeels.JPG http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Scree... [1] https://en.wikipedia.org/wiki/Excelsior_JET https://en.wikipedia.org/wiki/Excelsior_JET
- jspaetzel 6y ago
  JavaFX might turn out to be a winner but it's still partly proprietary and is still transitioning from Oracle to the OpenJDK community. There's good reasons for it having little adoption.

by usrusr 6y ago

MaxBarraclough 6y ago

> SWT is surely just going through AWT Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. > desktop JVM could see a surprising renaissance as a lesser evil I'm not convinced that a whole new toolkit is the solution, with all the challenges that brings (lots of widgets to create, internationalisation, accessibility, multiple platforms to test on, etc). I figure the better move would be to work on improving JavaFX. As far as I can tell it's a pretty solid GUI toolkit, albeit one with little adoption. edit Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. Expecting the user to install the JVM isn't good enough, the application should bundle a JVM, or use ahead-of-time compilation. The user should never be made aware of what language you built the program in. As I understand it, OpenJDK has been making solid progress on the latter option. (And Excelsior JET no longer exists.)

usrusr 6y ago
> Not so, SWT uses its own bindings to the OS's native GUI toolkit, using JNI. A right, I forgot that, thanks. What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? In any case this property of SWT kind of explains the omission, SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop.
- MaxBarraclough 6y ago
  > What's the SWT approach to use cases where you basically want a pixel canvas? Falling back to AWT on a surface allocated from the native API or its own facade for native APIs? I don't think SWT makes any use of AWT, I believe it does the latter. > SWT happens on a level that is two layers away from skija in the stack Jetbrains are building for Compose Desktop The article is making the case for a whole new GUI toolkit for Java, without making a persuasive case against JavaFX (I'm not convinced that its performance is a problem), and without mentioning SWT, the foremost 'unofficial' desktop GUI toolkit for Java. Skija may have its merits as a platform for 2D graphics, but that's not the point. Incidentally, the article's title is misleading. It's about GUI toolkits, not graphics libraries.
  - usrusr 6y ago
    The whole new GUI toolkit in question is Compose Native and that's not entirely new (only the desktop part is). Literally millions of Android devs would already feel more at home with it than with any other desktop UI toolkit. Maybe it's a bit dishonest to present Skija as if it was made for any other reason than to enable Compose Desktop, but it's very laudable to have the ambition to be more than an enabling component of that.
usrusr 6y ago
And about your edit, it's true of course, this is an issue. If you bundle the JRE feels wasteful and if you don't it feels uncaring for the less technical. Didn't JavaFX, beside being "Swing 2", consist of some native launcher component that would connect with an installed JRE if available (and sufficiently modern) and guide the user through download/installation if not? Memories are faint. Many similar approaches have been done, but none became a conveniently dominant go-to solution. Perhaps AOT compilation will finally bring a JRE bootstrapper component that is sufficiently "java" to find a wide footing in the java dev community and sufficiently friendly to end-users to end all "but maybe that other tool is even better" that kept all existing approaches niche.
ksec 6y ago
>Also, I suspect one of the things holding back Java desktop GUIs might be that they're often clumsy to distribute. I just download Netbeans, this is 10+ years since I touch a Swing / Java apps. And nothing has changed, it still looks Java. It is still heavy, although start up speed are now better. But generally speaking an Electron Apps ( VS Code ) looks and works better than that. Eclipse is still better look wise, as it was 10+ years ago. That was basically the reason why I choose SWT back then. But it is still not perfect. So I decide to check out another consumer Desktop App from similar era, Vuze, or used to be called Azureus. And it is the same, Desktop Java Apps. And yes that was the reason why no many were using Consumer Desktop Java Apps. They dont look good, heavy on resources, need JDK etc.... As if nothing has changed in the past 15 years. I remember I was trying to use GCJ and SWT for Desktop Apps then, it was just too hard. I gave up. And it seems no one cares about decent, java desktop apps.
- MaxBarraclough 6y ago
  > it still looks Java I think the Nimbus look is ok. [0] > It is still heavy, although start up speed are now better. It's certainly heavy. iirc NetBeans spins up over 20 threads even if you're not doing anything. As for startup times, is this on the same hardware? I imagine SSDs must help with NetBeans startup. > trying to use GCJ and SWT for Desktop Apps then, it was just too hard. There was a proprietary payware alternative to GCJ called Excelsior JET but it was discontinued 2 years ago. [1] [0] http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Screenshot_NBLookAndFeels.JPG http://wiki.netbeans.org/wiki/images/b/b2/Vista_Nimbus_Scree... [1] https://en.wikipedia.org/wiki/Excelsior_JET https://en.wikipedia.org/wiki/Excelsior_JET
jspaetzel 6y ago
JavaFX might turn out to be a winner but it's still partly proprietary and is still transitioning from Oracle to the OpenJDK community. There's good reasons for it having little adoption.