monomer VS static-haskell-nix

Yes - for example https://github.com/fjvallarino/monomer

I don't know about gloss, but building a game with sdl2 been fairly straightforward for a few years now, and I know of one gtk3 tutorial, but also monomer seem to have pretty good tutorials and examples.

I would like to suggest the following Haskell GUI-library for the desktop application: https://github.com/fjvallarino/monomer

I recently tried building a monomer application, hoping to get it to run on my phone phone (currently I'm running the latest Manjaro phosh demo).

i was considering an electron app with pure script or GHCJS and then i came across https://github.com/fjvallarino/monomer and i would like to pursue it. I am just wondering if anybody knows how does it perform compared to an electron based app?

Release notes: https://github.com/fjvallarino/monomer/releases/tag/1.4.1.0

If you're looking into creating UIs, Monomer provides a declarative style inspired on Elm's architecture.

If you used Swift UI and like creating GUIs declaratively, Monomer may interest you.

monomer is probably the newest GUI library for Haskell. It looks good, though I haven’t tried it.

Using Nix: https://github.com/nh2/static-haskell-nix

To debug this type of problem (I have to debug linker errors regularly as part of static-haskell-nix):

In static-haskell-nix there is currently this PR to enable support for that: https://github.com/nh2/static-haskell-nix/pull/108

I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs.

Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.

> if they could keep that libgtk_static around

Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.

> I'd be interested to hear if static linking GTK even has that many benefits

One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.

Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.

This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.

[1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

GTK can be statically linked.

Example executable:

https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

It lost this ability temporarily when switching to Meson, but I fixed it in GTK3 and GTK4. But I just checked and apparently it is broken again:

https://gitlab.gnome.org/GNOME/gtk/-/issues/3774#note_109746...