Just saw this released pretty recently for ImGUI: https://github.com/oprypin/crystal-imgui
Seems pretty neat for simple GUIs. I haven’t used it personally though, so I can’t give much of an opinion on it.
Just saw this released pretty recently for ImGUI: https://github.com/oprypin/crystal-imgui
Seems pretty neat for simple GUIs. I haven’t used it personally though, so I can’t give much of an opinion on it.
What do you plan to use for drawing? SDL2 (boring, bugs, bugs in scaling, no antialiased drawing), SFML, or what?
I know there’s already bindings out there for good libraries but I’m particularly passionate about pure crystal implementations. So I plan to draw from scratch. I’ve been experimenting with graphics here https://github.com/da1nerd/prism and plan to take what I learned and build something specifically for UI.
I really like how https://github.com/da1nerd/prism is coming along!
Also, maybe webdriver don’t fit every case, but for those interested in a webdriver approach, these look interesting:
install webdrivers:
https://shards.info/github/matthewmcgarvey/webdrivers.cr/#readme
using webdrivers:
https://shards.info/search?query=webdriver
I’m quite new here and I’m trying to understand what is the Crystal GUI situation one year after the opening of this topic.
As of January 2021, it looks like there are usable and maintained bindings at least for GTK3 (jhass, via GObject) and for Qt5 (papierkorb, via bindgen). Am I wrong?
Do these bindings are actually usable (at least for a personal, hobby project) or they have hidden limitations that I still cannot see and that prevent them to be used?
Papierkorb’s Qt5 project seems to be particularly fine because of bindgen. Using an automatic binding generator could solve at least a part of the problems related to the lack of time and developers that usually plague such projects. (It is also worth noting that Qt is a C++ library, not C, and that this seems to indicate that Crystal can easily bind to any other C++ library).
Besides this, the “Nikola Motors’ approach”, that follows the Electron paradigm, seems to be a viable solution, even if it requires to have an HTTP server (Kemal?) and a (huge and bloated) HTML5/CSS/JS client. The main drawback seems to be that all of the real GUI would have to be developed in HTML/CSS and Javascript. At that point, it would be easier and more natural to use Node.Js and Javascript on both the client and the server, as usual.
Anyway, I wonder if anybody tried to develop anything like Electron Framework for Crystal or anything like Python’s Eel library (see: GitHub - ChrisKnott/Eel: A little Python library for making simple Electron-like HTML/JS GUI apps ).
So, what is the status of the GUI libraries/frameworks for Crystal as of today?
Here’s a mini GUI update. Last summer I took a break from building a game engine in crystal and started a GUI project (seemed more important). It was collecting dust over the fall, but I was able to start working on it again this last week.
Here’s a video showing my progress https://youtu.be/BACmF6C5Kfc. Keep in mind this is still very rough, but it’s all in 100% crystal! The only bindings are to OpenGL.
This is very interesting. The fact that is pure Crystal would free us from those dependencies that so far blocked many other projects. Hope to see more soon.
Is it possible to create bindings to a Rust library like OrbTk (GitHub - redox-os/orbtk: The Rust UI-Toolkit.)?
If so, is there any documentation/tutorial on how to get started doing that and how hard is it likely to be?
If you search “how to call Rust from C” (or any other language) it will be similar.
You link to a compiled Rust library like to a C library. This should get you started on C bindings in Crystal: C bindings - Crystal
Maybe a tool like GitHub - crystal-lang/crystal_lib: Automatic binding generator for native libraries in Crystal could help with setting up the lib bindings in Crystal.
Thanks @asterite and @straight-shoota
Both projects use automatic bindings generation. This is good because it makes it easy to support new versions of qT/gtk, but this also makes you dependent from one more pretty complicated library. Crystal isn’t 1.0 yet, so changes in language can make bindings unusable and it won’t be trivial to fix it (because you’ll likely have to fix the generator, not bindings, and generator isn’t simple).
This doesn’t matter much for hobby project though, I’ve successfully used gtk bindings for sample programs and qt should be ok too.
Thanks. This makes GTK bindings even more interesting for me (I’m looking for a Linux-only solution). Maintaining a working automatic binding generator is very hard but I still hope these generators will find the required support in the future. They can make the difference between a “good” language and a fantastic ecosystem. Much of Python’s success, for example, is related to its ability to bind C and C++ libraries.
GTK bindings works nicely, the only problem I had/have writing my beloved text editor was using GtkSourceView4, Crystal GC just starts messing up with the memory allocated by it and make the whole problem crash. But in my tests, using GTK alone doesn’t have this problem, or at least I couldn’t see it.
Your editor app is probably one of the biggest native Desktop GUI apps made with Crystal so far. It’d be nice to have a list of similar non-trivial GUI apps like this
Tijolo installs (from .deb package) and works fine on my Linux Mint 20 machine. This project is a clear demonstration that GTK (GObject, actually) bindings work fine and can be already used for non-trivial projects.
Strangely enough, Crystal-GTK bindings are not even mentioned on GTK website (see: The GTK Project - A free and open-source cross-platform widget toolkit ) and are described as “just GObject” on the Wikipedia page dedicated to GTK bindings (see: https://www.wikiwand.com/en/List_of_language_bindings_for_GTK ).
It’s because the current shard is mainly a binding generator for libs using GObject introspection. Ideally a gtk
shard should exists and just use the binding generator. So the current shard have just few adjustments on the code generated automatically by the generator.
I have some other fixes on Tijolo repo to make GTK API smelling not too bad, mostly very simple, that wasn’t upstreamed anywhere due to the lack of tests or because I think there’s a pattern and it should be somehow automatized.
This is my project, Alizarin. It helps you build Linux GUI applications using Web Technologies (HTML5, CSS3, JS), also allows you extending JavaScriptCore using Crystal
An interesting alternative to GTK+:
A C version of FLTK (originally in C++)
A pure C library (converterd from C++ to C) which can be compiled statically (unlike GTK+) yielding files in the shape of one single executable binary (easy to distribute).
A potential candidate for creating multi-platform GUIs (bindings), by calling these C functions from Crystal.
My plan is to use @naqvis github.com/naqvis/webview binding to C’s webview, to produce universal desktop apps (Linux, Mac and Windows) using web technologies.
It’s almost the same approach of @TheEEs github.com/TheEEs/alizarin, but desktop OS agnostic.
When we use the already present web engine from OS, contrary to Electron’s approach, the overhead is minimum and, on recent tests of projects with the same approach, we can see apps using as low as 2.7MB of RAM (see “Memory Usage” line, on “Neutralino” column)
If we improve this strategy by intercepting the requests, we can completely discard the necessity of a local web server (reducing even more the RAM usage), by already returning the data needed.