On Windows, the application will have to be split into two files (client, server), because there is no support at the moment in Crystal for threads under windows (so it will have to be two processes, instead).
This is an alpha version, I have just been working on it for two days, but I believe that with a little bit of efforts it will work on Windows as well.
It works on Mac OS (and in Principe also under Linux, because it contains nothing Mac specific).
As far as the makefile is concerned, it uses exclusively Linux/Mac OS commands; The idea was to use it via MingW on Windows (not from the Windows terminal), but as mentioned before, Iāll have to develop a workaround for the lack of multithreaded support on Windows in a first instance.
Yes, it is just a matter of adding the corresponding entries in the makefile.
I know Vue 3 superficially, but well enough to add basic support for Vue on relatively short term.
I can do it next week if you want.
The advantage of Svelte, beyond the fact that it is very simple to use, is that it comes with its own development server and its own packaging (bundling) utility, so integrating it in the makefile of CrystApp was very easy.
Since Vue can use Vite as well, as you mentioned it, it should be easy.
I am in the process of replacing the Makefile by a command line utility (an executable written in Crystal), so thatās a first step towards making the application more portable (independence from āmakeā).
Well, it compiles in CI, so i just made a fork that allowed to download resulting dll: try4 Ā· konovod/webview@8bc83af Ā· GitHub
It works for me (iāve slightly changed webview shard too to use dll instead of static compilation), but i understand that proper shard should use more ācivilizedā approach.
As for a topic app - it was shown in my github recommendations and I thought - wow, so great. But after discovering webview shard i donāt really see a point - if shard allows you to call crystal functions directly from JS world, why use server and communicate through sockets?
then examples work. My usecase is ājust for own useā though, as for general case:
Iām not sure it is possible to statically link webview using MSYS2, because Crystal itself uses MSVC linker
Iāve no idea on how to make GUI app (i.e. how to make app that donāt show console window on start). Simply passing @[Link(ldflags: "/subsystem:windows")] isnāt enough, something should be fixed in crystal stdlib.
At this point, Iām wondering if the easiest way to build a portable app using Crystal is not to use a regular browser (in ākioskā mode) for the front-end app (instead of WebView) and to replace the JS-to-Crystal bindings with simple HTTP communication.
Well, right now iām using GTK2 + LCL + kipar / No No GUI Ā· GitLab wrapper for some embedded development. Yes, this is madness, but it works. Sadly gtk2 is going to be dead soon.
Idea to use GTK4 or Qt5 bindings is nice, but i would prefer to wrap GUI library in a dll with minimal contact surface, instead of adding pretty big bindings to not-so-fast compile times (and chance that something will be broken after next compiler update).
LibUI would be ideal, but it has way too little features.
Webview2 looks like possible alternative, iām going to investigate it. I donāt like an approach that uses browser for things that are not related to network communication, but well, if it works it works.
I donāt like Electron-like approach (and approach with kiosk-mode browser) too, but well, thatās just my opinion.
You are not alone in that
Every other day i dream of starting exploration into getting cross-platform gui development in crystal.
Maybe Iāll do some day, if someone invents 38 hour days.