by Sparkenstein on 8/2/22, 3:17 AM with 52 comments
by comex on 8/2/22, 5:10 AM
I think this is a shame, demonstrating more than a small amount of NIH. Yes, different platforms have different widgets and different design guidelines, so a cross-platform UI using greatest-common-denominator set of native widgets will never look quite native. But at least text boxes will work the way text boxes should work, with keyboard shortcuts, the special characters menu, IME, the works. That already puts you ahead of most cross-platform UI frameworks that aren't browser engines! Menus will work the way menus should work. HiDPI will work (failing to support that is less common these days, but it still happens). Text rendering will look native.
With custom rendering, you have to invest a mammoth amount of effort to even approach native platform behavior. Which means that most small UI libraries produce UIs that feel like toys, and even the big ones have an uncanny valley feel. With native controls, even with a relatively small library, you can make a UI that feels fundamentally _usable_.
While this project is immature, I hope it has a bright future. If it matures into a high-quality library, I would learn Zig for the sole purpose of using it. I'm also keeping my eye on libui and libui-ng, similar libraries which are written in C.
by ducktective on 8/2/22, 8:24 AM
If only there was a way to interface to these using some declarative minimal and highly opinionated programming language and paradigm...
There is a Janet binding for it but it looks abandoned.
by tnodir on 8/2/22, 5:57 AM
by sharikous on 8/2/22, 6:31 AM
by malkia on 8/2/22, 6:07 AM
by mattanimation on 8/2/22, 5:13 AM
by nine_k on 8/2/22, 10:29 AM
My only issue is with using literal pixels. With screens that have 3x-4x difference in DPI in wide use, it's easy to shoot oneself in the foot and make a GUI that looks indiscernible on a retina screen, or colossal on a low-end laptop screen.
I hope this will be addressed in a future version (and that there'll be more future versions! and wide adoption!)
by rvz on 8/2/22, 11:05 AM
> Note: As there's no "official" GUI library for Linux, GTK 3 has been chosen as it is the one that works and can be configured on the most distros. It's also the reason Libadwaita won't be adopted, as it's meant for GNOME and GNOME only by disallowing styling and integration with other DEs.
The never ending unsolvable problems, in-fighting and conflicts that keep plaguing the Linux Desktop has now spread onto aspiring cross-platform GUI libraries to make a compromise to avoid certain integration(s) with other libraries that will limit future functionality if someone decides to use it.
This is a solved issue for macOS and Windows, but never Desktop Linux which is a terrible shame for more than 20+ years.
by mark_l_watson on 8/2/22, 1:49 PM
When designing something like Capy, it would seem like a very good idea to start with something well designed for another language, think about how to support a different programming language, and make whatever changes seem joyful to you, as a developer. I am not suggesting cargo culting, rather appreciate and be inspired by people,solving the same problems.
by fassssst on 8/2/22, 4:15 AM
by madeofpalk on 8/2/22, 11:13 AM