GUI frameworks are big because they do a lot. These minimalist things usually only work until you reach the limits of what they can do and then you have to rewrite in something like Qt anyway, or sacrifice what your users want in a GUI for your own code aesthetics.
I disagree with the author, it's really easy to test the examples of Nuklear.<p>I made applications with Nuklear that runs on Android, iOS, macOS, Windows and share the same main C code. For me, it's a dream come true if you create a cross-platform application that needs a simple GUI.<p>Dear ImGui is also fantastic and more complete than Nuklear.<p>What I like a lot with Nukear and Dear Imgui is that you have a GUI that is GPU accelerated and so can be updated at 60 FPS without burning resources.
"<i>The solution (hint: there wasn't one until now)...</i>" That's quite the bold statement. I actually thought of IUP/Lua when I saw this line, and it turns out you precisely used IUP for the UI portion of your framework! Except you didn't use the Lua binding, instead you created a Janet binding.<p>Using something like luastatic[1], with whatever Lua libraries you want (including IUP), you can get something pretty similar to this system, except of course you'd be using Lua instead of Janet. Janet is really interesting and that alone justifies this framework very well.<p>[1]: <a href="https://github.com/ers35/luastatic" rel="nofollow">https://github.com/ers35/luastatic</a>
Seems to be based on iup that supports both Windows and Linux? <a href="http://webserver2.tecgraf.puc-rio.br/iup/" rel="nofollow">http://webserver2.tecgraf.puc-rio.br/iup/</a><p>The new crop of immediate mode cross platform GUI libraries are more interesting (such as nuklear and Dear Imgui). I also did some experimentation with these libs a few days ago: <a href="https://liuliu.me/eyes/write-cross-platform-gui-in-swift-like-it-is-1998/" rel="nofollow">https://liuliu.me/eyes/write-cross-platform-gui-in-swift-lik...</a>
For anyone needing a simple and fast cross-platform toolkit for C++, FLTK is really good. It is easy to build and statically link only the parts you need, and the API/widget selection is pretty good. It looks a little old school/non/native, but it has been useful for me.
With opengl, libuv, and libcurl, and Dear Imgui, I can write a C program resulting in a binary that's about 400kB unstripped, to put 5MB in perspective. And for a simple program like what you wrote, I don't even bother trying to free the memory myself sometimes, I just let the OS free it when I exit. With that design choice in mind, the end code is like <1000 lines, and a decent bit is reused snippets.<p>In the end, this feels like a an appraisal of IUP and Janet more than a demo of anything new. If that's the case, then familiarity with your stack is more important for this kind of productivity than anything else, so trying something new is less appealing to me.<p>But I was curious about Janet, so seeing some examples was nice.
Interesting pitch for Janet. Here [1] is a quick rewrite in Red language, which lives up to the author's requirements: 10 LOC, native support for all 3 major platforms, can be shipped as a single binary, and all that's required is a 1MB toolchain.<p>[1] <a href="https://gist.github.com/9214/dfa15d37342065dbf368eae35abcdc37" rel="nofollow">https://gist.github.com/9214/dfa15d37342065dbf368eae35abcdc3...</a>
<i>However, the elephant in the room (which I also like to ignore as a Clojure enthusiast) is that the start up time of a Java based GUI app is too slow (this is exacerbated even moreso when Clojure is involved)</i><p>I'm expecting a GraalVM rejoinder from someone. For anyone who's used GraalVM (particularly with Clojure) - what are the downsides and limitations?
What about macOS? So far Racket seems like the easiest solution for a lisp with easy cross-platform GUI support (Linux, Mac, Windows). It would be nice to have more easy choices, but also nice if all 3 major platforms were supported.
Subtracting all the delusional fluff about small sizes, this article is about a Janet binding to Gtk3.<p>ldd app.bin|rg -o '/usr/lib[^ ]+'|xargs stat -L -c %s|perl -lne'$s += $_; END {print $s}'<p>38120904
How about English? This is just programed as:<p>> Puppy is an app<p>OK, you run 'Puppy'. It doesn't do anything.<p>> RandomHost is '<a href="https://dog.ceo/api/breeds/image/random'" rel="nofollow">https://dog.ceo/api/breeds/image/random'</a><p>OK, 'RandomHost' is a constant, looks like a URL<p>> Get an image from RandomHost<p>OK, I think you meant Set Message to Read RandomHost retreiving UUENCODE.<p>> No. Get an image using json<p>Not the previous thing. I think you meant Set Message to Read RandomHost retrieving JSON, field Message.<p>> Get Image at Message<p>OK. I think you meant Read the URL Message and retrieve an image file<p>> Show the Image<p>OK. Displaying the Image on the screen<p>> Add Repeat Button<p>OK. Displaying a button named 'Repeat'<p>> App is While on Repeat, do the Display.<p>OK. App is set. Do display, Wait for Repeat button, Loop<p>> Puppy?<p>Puppy is an application:<p><pre><code> Repeat
RandomHost = 'https://dog.ceo/api/breeds/image/random'
Message = fetch(RandomHost, JSON)."message"
anImage = fetch(Message, DATA).ensure(IMAGE_TYPE)
Display.reset(Items [
Image: An Image,
Button: Repeat text "Repeat"
])
ClientSideWait Repeat.onPress
Forever
</code></pre>
> Problems?<p>Your app can run.<p>You have eight error conditions to discuss. Use 'Talk about errors' to decide how to handle them. Right now, the answer is 'ignore first, or just explode'.<p>>Push<p>Pushing transcript to GitLab.... Building App.... Pushing Build to GitLab.<p>> Move button above image.