Owlkettle compared to other libraries in Nim and other languages.

[fabricio-p]

First of all, very cool library, very nice interface and the DSL is maybe the best part because it's not like you can do it this good and make it integrate so seamlessly in other language without getting dirty.

I have tried a few GUI frameworks/platforms and the web technologies usually have been the best experience. Owlkettle works the same if not better. One of the reasons is because JS frameworks tend to either drop into the JSX or the template team because of the limitations of the language meanwhile Nim supports pretty much everything you need to do.

The other one is the Python Kivy framework. Ignoring a few problems here and there and weird design decisions (coordinate system with origin at bottom left), it tries to separate the functionality and layout into different files and file formats. That reminds me how android dev with java and xml layouts is done and it works for small scale but it doesn't emphasize enough the separation into components and modular component structure so in the end you may end up with a big .kv file.

Besides those I have tried some android dev with java and xml. It is not bad but there is a lot of boilerplate and styles defined in xml files and whatnot. Lowers productivity in general.

Before Owlkettle I tried to use Fyne, a Go library. The main issue is that it requires too much work to get the layouts to work. Especially because it has unintuitive resizing mechanisms. Also the way you create your widget/layout (different things in Fyne) is a bit too much procedural and boilerplate-y.

All in all, Owlkettle seems like the silver bullet for now, it would have been cool if gtk4 worked for mobile or Owlekttle had a mobile backend. What are your experiences with other GUI platforms/frameworks/libraries and do you think they are better or worse than Owklettle? If so, why?

[PhilippMDoerner]

Mine would be Angular.

What Angular does better is tooling, by which I mean ng. It would be really helpful if we had an opinionated tool that helps you create an owlkettle project, during whose setup it'd ask you about which version of gtk/adwaita you plan on supporting to write a "compile" command for you in the nimble file. It could also initialize creating a viewable widget, essentially writing a nim file containing the widget + a css file specifically for that component which it also automatically adds to the core project file that contains the brew-call.

Also, storybook. So some kind of lib to just "present" and make configurable and searchable a list of widgets would be pretty useful. Luckily the playground should take care of a fairly large amount of that task, it would just be enabling code with which you can register dummy-widget files that then get displayed in a compileable "design-library" kind of thing.

[nylki]

I'd like to mention another one that is similar to Owlkettle in regards of its declarative GTK/Adwaita approach: adwaita-swift
I have only experimented a little bit with it, but my first impression is generally quite positive:

• automatically generated bindings for most widgets via gobject definition parsing (if I got that right) -> less maintenance overhead for maintainers/devs of the framework
• clean declarative interface, closely matching SwiftUI (for Apple platforms), making the learning curve easier for people familiar with SwiftUI
• relatively easy to generate a flatpak for distribution
• good documentation and examples
• persistent state features (saving ui-state values across app launches)

But the main disadvantage I currently see and experience is the limited Linux support of the Swift:
Also you kinda have to use the flatpak workflow to use the swift toolchain, otherwise installing the dependencies is a bit tricky. This could be either pro or con, depending on the situation.
- flaky/unreliable support for code autocompletion in Gnome Builder and VS-Code (possibly due to sandboxed flatpak development) (Apparently this is fixed)