Racket GUI Screenshots(alex-hhh.github.io)
alex-hhh.github.io
Racket GUI Screenshots
https://alex-hhh.github.io/2021/09/screenshots.html
5 comments
Racket has a surprisingly good cross-platform GUI library. I've been building a tool for streamlining some testing at work, and building in Racket makes it almost trivial for it to work across Mac/Win/Linux, even the GUI bits, and you get that Schemey goodness.
Racket's native GUI lib really blew me away.
Bogdan Popa has been doing some interesting work on declarative GUIs in Racket: https://youtu.be/AXJ9tTVGDwU
He put the first Racket app in the Mac App Store
Oh wow I'm kind of shocked this is the first time I am seeing this. I have mostly gravitated to eclipse SWT with a bit of dabbling in JavaFX.
I just started playing around with clojure last week, but I have yet to do any GUI work with it.
I intended to try out Racket at some point, but this GUI library looks so nice I might start soon.
I wonder if anyone has implemented cassowary contraints yet for Racket and combined the two.
I just started playing around with clojure last week, but I have yet to do any GUI work with it.
I intended to try out Racket at some point, but this GUI library looks so nice I might start soon.
I wonder if anyone has implemented cassowary contraints yet for Racket and combined the two.
So I tried it out a little. It's a really nice api, buuuuuuut I am really disappointed in the resource consumption. A simple form with a few fields and a submit button was consuming 238mb of ram on my macbook m1 air. Then when I used raco exe the resulting executable size was 65mb! So for maybe large scale app it would be fine, but that feels really heavy for something small.
Its still smaller and less resource intensive than say electron, but man that executable size is pretty brutal for a native app.
For reference the same form made with Haxe + SWT + GraalVM on an intel mac(graalvm native image is not supported on m1 yet) is about 13mb and uses 100mb of ram. Also A jlinked and packaged swt app would probably have better memory management, and end up with a package size in the ball park of 70mb as well.
Again though the Racket API seems nice, but it doesn't expose the native window handle like SWT does which would prevent you from embedding a third party graphics context like GLFW which is kind of a bummer. I've done that with Nim+Tcl to have ab opengl context with Tcltk controls as well as Haxe + SWT + GLFW to have bgfx with native controls.
Its still smaller and less resource intensive than say electron, but man that executable size is pretty brutal for a native app.
For reference the same form made with Haxe + SWT + GraalVM on an intel mac(graalvm native image is not supported on m1 yet) is about 13mb and uses 100mb of ram. Also A jlinked and packaged swt app would probably have better memory management, and end up with a package size in the ball park of 70mb as well.
Again though the Racket API seems nice, but it doesn't expose the native window handle like SWT does which would prevent you from embedding a third party graphics context like GLFW which is kind of a bummer. I've done that with Nim+Tcl to have ab opengl context with Tcltk controls as well as Haxe + SWT + GLFW to have bgfx with native controls.
FYI, Racket has a `get-handle` method to get a native handle from a `window<%>`: https://docs.racket-lang.org/gui/window___.html#%28meth._%28...
There are ways to optimize executable size with various tradeoffs, though they require compiling Racket yourself or using a Racket BC distribution. By default, Racket generates machine code (including natively on M1), which tends to be larger than bytecode. That's only been the default since February 2021, so I'd bet there's still room for improvement in code size for the default configuration.
There are ways to optimize executable size with various tradeoffs, though they require compiling Racket yourself or using a Racket BC distribution. By default, Racket generates machine code (including natively on M1), which tends to be larger than bytecode. That's only been the default since February 2021, so I'd bet there's still room for improvement in code size for the default configuration.
Racket/gui is far from having every feature under the sun like JavaFX or QT, but what it lacks in breadth it makes up in flexibility and customizability. It's seriously one of the very best cross-platform, easy to set up solutions available.
Impressive motivation for a hobby project! It's true that Racket makes that very simple compared to other more popular options, but still...
Oh wow. There are a few cross platform gui tools but what else looks this good?
People usually mention Lazarus[0] (an IDE for Free Pascal) which people on HN have claimed has amazing cross-platform support.
[0]: https://www.lazarus-ide.org/
[0]: https://www.lazarus-ide.org/
I wouldn't call the GUI side "amazing" in its cross platform support as each platform works by using different backends (win32, qt, gtk, etc) and as such each backend has its own quirks. Also since most toolkit developers nowadays love to break their working code, there is a lot of (wasted) effort into porting LCL (Lazarus' framework) to newer versions (only to become obsolete when it is done).
Win32 is expectedly the most stable because the API hasn't changed for decades, so the effort was spent on stabilizing and fixing bugs over the years.
Gtk2 is also stable and should work fine. It is the most stable of Linux backends at the moment,
Gtk1 was stable until development dropped some years ago, though AFAIK recently someone tried it and fixed any issues. It doesn't really get much love though.
Gtk3 is not feature complete but simple stuff should work, judging from a recent message in the development mailing list there isn't anyone interested in fully working on it - there is development but not any dedicated developer. Makes sense, personally i wouldn't bother to work on something i knew will soon be deprecated.
Gtk4 isn't even a think yet AFAIK.
Qt4 should be around as stable as Gtk2, perhaps a bit less. Requires dragging around the qt4pas shared library though since Free Pascal cant link against C++ libraries directly (Gtk binaries are self-contained and can link against the system Gtk with compatibility going several years).
Qt5 is newer but i think it started as a copy of Qt4 so it should be around the same quality, perhaps better in trunk as it gets most of the Qt development. Like Qt4 you need to drag a shared library around to use it.
Carbon was the most stable on Mac OS side but of course it isn't available in newer Macs. Not that it was ever beyond alpha quality, but at least it worked.
Cocoa should be fine nowadays but i think there isn't any dedicated developer and its quality is hit or miss as it only picked up whatever Mac development was going on only recently when it became impossible to do 32bit programming.
There are some other backends but they are in various stages of not working.
In practice however you can release binaries for all major platforms, you just wont get the shiniest backend versions outside of Win32. In my experience the most stable are Win32 and Gtk2. I think Qt5 should be somewhere next to that so if you make a Mac application and behaves weirdly you can use the Qt5 backend instead of the Cocoa backend (this was a common workaround for 64bit applications when Carbon was still usable but only available for 32bit applications). Of course this means you have to drag not only the qt-to-pascal interface library but also the entirety of Qt. Though that should still be less than Electron and you'd still get to use "native" widgets on other platforms.
Win32 is expectedly the most stable because the API hasn't changed for decades, so the effort was spent on stabilizing and fixing bugs over the years.
Gtk2 is also stable and should work fine. It is the most stable of Linux backends at the moment,
Gtk1 was stable until development dropped some years ago, though AFAIK recently someone tried it and fixed any issues. It doesn't really get much love though.
Gtk3 is not feature complete but simple stuff should work, judging from a recent message in the development mailing list there isn't anyone interested in fully working on it - there is development but not any dedicated developer. Makes sense, personally i wouldn't bother to work on something i knew will soon be deprecated.
Gtk4 isn't even a think yet AFAIK.
Qt4 should be around as stable as Gtk2, perhaps a bit less. Requires dragging around the qt4pas shared library though since Free Pascal cant link against C++ libraries directly (Gtk binaries are self-contained and can link against the system Gtk with compatibility going several years).
Qt5 is newer but i think it started as a copy of Qt4 so it should be around the same quality, perhaps better in trunk as it gets most of the Qt development. Like Qt4 you need to drag a shared library around to use it.
Carbon was the most stable on Mac OS side but of course it isn't available in newer Macs. Not that it was ever beyond alpha quality, but at least it worked.
Cocoa should be fine nowadays but i think there isn't any dedicated developer and its quality is hit or miss as it only picked up whatever Mac development was going on only recently when it became impossible to do 32bit programming.
There are some other backends but they are in various stages of not working.
In practice however you can release binaries for all major platforms, you just wont get the shiniest backend versions outside of Win32. In my experience the most stable are Win32 and Gtk2. I think Qt5 should be somewhere next to that so if you make a Mac application and behaves weirdly you can use the Qt5 backend instead of the Cocoa backend (this was a common workaround for 64bit applications when Carbon was still usable but only available for 32bit applications). Of course this means you have to drag not only the qt-to-pascal interface library but also the entirety of Qt. Though that should still be less than Electron and you'd still get to use "native" widgets on other platforms.
Do they?
Down votes! I seriously never heard of lazurus before. Where is the community active?
There are links to the community wiki on the Lazarus website (linked in the parent answer). Lazarus is not a language but a FOSS 'fork' of Delphi based upon object Pascal. Since there are many old-timers there, my guess is they hang out on IRC.