9 ms·

Capy – Cross-platform library for making native GUIs in Zig

164 points by Sparkenstein 4y ago

fassssst 4y ago
If you want it to be “native” on Windows then the Windows backend should use controls from Windows App SDK, not GDI.
- pjmlp 4y ago
  As someone that spends most of my development life on Windows, I wouldn't bet anything on WinAppSDK until the likes of Office or VS make use of it. Right now its future is as certain as UWP.
  - yesimahuman 4y ago
    Having used Windows App SDK extensively, I tend to agree. It’s got a ways to go and its support for traditional unpackaged/win32 apps is just not there yet.
    - yesimahuman 4y ago
      Also I should note that WinUI 3 is separate from Windows App SDK so it can theoretically become the standard UI kit for other Windows dev approaches as well but it’s still early.
- tomcam 4y ago
  What? Why? Do you expect support for Windows’ original API to be dropped soon?
  - pjmlp 4y ago
    Nah, maybe they are an agent of WinUI 3.0 team in disguise. :) Still plenty of catch up with Win32 to do, when adding up all issues across WinUI, WinAppSDK, CsWinRT, C++/WinRT and new kid in town, Rust/WinRT. Assuming they don't reboot the whole teams yet again by next BUILD.
  - fassssst 4y ago
    The “native” controls of Windows 11 use WinUI. The Settings app demos most of them.
comex 4y ago
There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. 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.
- abainbridge 4y ago
  There is no consistent native look/behaviour on Windows. Even a single program (Excel), written by MS themselves, has no consistent style. I think I see 7 different styles in these search results: https://www.google.com/search?q=excel+%22save+changes%22+dialog https://www.google.com/search?q=excel+%22save+changes%22+dia... Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell. If I redo the experiment on my own Windows 10 machine, I see 7 different kinds of save-changes dialogs, from these 7 programs: VS 2013, Notepad++, Paint.NET, Photoshop CS6, TextPad, UltraEdit and WordPad. Again, this isn't a perfect test because many of those programs are using non-native GUI frameworks. But my point is that as a Windows user, I can't tell what native is, because approximately every program looks different.
  - ThinkBeat 4y ago
mattanimation 4y ago
Oh nice, I was literally testing imgui in zig today, but I'll have to give this a test too.
tnodir 4y ago
Also see https://github.com/frang75/nappgui_src https://github.com/frang75/nappgui_src
malkia 4y ago
LispWorks GUI is named similarly :) - Capi - http://www.lispworks.com/products/capi.html http://www.lispworks.com/products/capi.html - it just reminded me of it when I've read the name, that's all...
sharikous 4y ago
Nice. Is zig easily callable with the C ABI? This could be a really nice thing to have for everybody using a different language too
- dosshell 4y ago
  Zig and C are best friends. Zig can even compile C.
  - norman784 4y ago
    IIRC there were some limitations with C macros, if that is a think, my understanding of C is very limited, but I was interested in zig a while ago and watched some presentations.
    - cturtle 4y ago
      Yes not everything can be imported perfectly. With my project making a Lua wrapper library in Zig I had to fix a few poorly translated macros. Overall though most translated just fine. I think with some work on Zig’s end a few more cases could be handled though.
- Zen1th 4y ago
  Yea :) In fact I'm planning to add a C ABI to Capy (I already did some small tests in the c_exemples folder)
- LAC-Tech 4y ago
  In Zig you literally just import a C header and start coding. There's no FFI like rust and no header guards like C++.
  - Tozen 4y ago
    By the way, Vlang has that level of C interop as well (https://github.com/vlang/v/blob/master/doc/docs.md https://github.com/vlang/v/blob/master/doc/docs.md), plus an outright C2V transpiler (https://github.com/vlang/c2v https://github.com/vlang/c2v) and can be compiled to human-readable C.
ducktective 4y ago
Fantastic! This is similar to the C library `libui` since it also acts as a wrapper of native libraries of each platform. 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. https://github.com/andlabs/libui https://github.com/andlabs/libui https://github.com/janet-lang/janetui https://github.com/janet-lang/janetui
nine_k 4y ago
Very nice! 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!)
- eyelidlessness 4y ago
  Many (maybe all?) native UI environments have a concept like a “logical pixel” which is scaled appropriately. I don’t know how much this project avails itself of those, but I did see that the web/WASM implementation uses `px` which in CSS is such a “logical pixel”. That has other issues on web of course, but I’d generally expect such a project to degrade on web because the native “UI” is very low level and unopinionated.
- Zen1th 4y ago
  It's already handled, each Window has a `source_dpi` which is the DPI for which the layout was made, and depending on that and the monitor's DPI, Capy will habdle the scaling.
rvz 4y ago
Great library, however: > 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.
- badsectoracula 4y ago
  Sadly Gtk developers were in a position during Gtk2's peak to help solve that by making Gtk2 "the" Unix desktop GUI API - it was used and targeted to by pretty much everything and it being a C API meant that it could remain backwards compatible for pretty much forever. But they instead decided to break the API with Gtk3, repeating the Gtk1 to Gtk2 transition mistake (which at the time it wasn't that big of a deal since Gtk1.x was never as popular or widespread as Gtk2). And just as some projects finally managed to convert their Gtk2 code to Gtk3 code, sometimes after years of work, the Gtk developers awarded them for their effort by breaking the API again in Gtk4. IMO at this point relying on anything Gtk4 is a mistake, though sadly there aren't many alternatives. Qt, being essentially a commercial middleware that also happens to have OSS-licensed code drops, has different priorities - and even if they wanted, being written in C++ which has no real stable ABI means they wouldn't be able to provide stable APIs anyway. Other toolkits are asphyxiated by the oxygen that Gtk and Qt are siphoning away so they barely get any support. EFL seemed to be ok (in that it was a sort of usable, sort of existing, C-based API that is apparently good enough for a desktop environment to be made with) but the author seems to have decided at some point to refactor (and thus break) the entire thing. Motif has been stable since the 90s, but it also has seen little improvement since the 90s either - it is also too tied to X11, meaning that having a crossplatform version (which is something that people would want) is quite hard. And thus we get Electron, which is almost a step before bundling an entire VM and OS inside a window.
- jakearmitage 4y ago
madeofpalk 4y ago
What does "native" even mean? How is this native in a way that HTML - which renders OS-native text input and button widgets - isnt?
- rafram 4y ago
  > which renders OS-native text input and button widgets Not anymore in browsers with content process isolation (which is essentially all of them). Native controls have to be imitated.
  - eyelidlessness 4y ago
    I’m confused. Why would browsers’ isolation of anything preclude rendering native controls? Native controls aren’t all in some global singleton process shared across non-browser apps (at least not in any environment I’m aware of, and the thought of a design like that fills me with dread). All a browser needs to do to render native controls securely is to render them as opaque to the JS/DOM runtime. This has even been formalized as “shadow DOM”. At least so far as I’m aware, Safari still renders native controls by default. Other browsers vary in their use of native controls but that’s been the case for decades.
    - jcelerier 4y ago
      > Native controls aren’t all in some global singleton process windows used to render scrollbars in-kernel (idk if it still does but it even did for 10: https://www.fortinet.com/blog/threat-research/one-bit-to-rule-them-all-bypassing-windows-10-protections-using-a-single-bit https://www.fortinet.com/blog/threat-research/one-bit-to-rul... )
      - eyelidlessness 4y ago
        Holy hell
mark_l_watson 4y ago
I first read “Capy” as CAPI, LispWork’s proprietary cross platform UI library (that is really very good - I am a LispWorks customer). 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.

164 points by Sparkenstein 4y ago

fassssst 4y ago

If you want it to be “native” on Windows then the Windows backend should use controls from Windows App SDK, not GDI.

pjmlp 4y ago
As someone that spends most of my development life on Windows, I wouldn't bet anything on WinAppSDK until the likes of Office or VS make use of it. Right now its future is as certain as UWP.
- yesimahuman 4y ago
  Having used Windows App SDK extensively, I tend to agree. It’s got a ways to go and its support for traditional unpackaged/win32 apps is just not there yet.
  - yesimahuman 4y ago
    Also I should note that WinUI 3 is separate from Windows App SDK so it can theoretically become the standard UI kit for other Windows dev approaches as well but it’s still early.
tomcam 4y ago
What? Why? Do you expect support for Windows’ original API to be dropped soon?
- pjmlp 4y ago
  Nah, maybe they are an agent of WinUI 3.0 team in disguise. :) Still plenty of catch up with Win32 to do, when adding up all issues across WinUI, WinAppSDK, CsWinRT, C++/WinRT and new kid in town, Rust/WinRT. Assuming they don't reboot the whole teams yet again by next BUILD.
- fassssst 4y ago
  The “native” controls of Windows 11 use WinUI. The Settings app demos most of them.

comex 4y ago

There's a severe lack of good libraries of this type; all the UI libraries want to invent their own controls and rendering instead. 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.

abainbridge 4y ago
There is no consistent native look/behaviour on Windows. Even a single program (Excel), written by MS themselves, has no consistent style. I think I see 7 different styles in these search results: https://www.google.com/search?q=excel+%22save+changes%22+dialog https://www.google.com/search?q=excel+%22save+changes%22+dia... Maybe some of those variations are due to running the same Excel on different versions of Windows, and it conforming to what it thinks native looks like on each. It's hard to tell. If I redo the experiment on my own Windows 10 machine, I see 7 different kinds of save-changes dialogs, from these 7 programs: VS 2013, Notepad++, Paint.NET, Photoshop CS6, TextPad, UltraEdit and WordPad. Again, this isn't a perfect test because many of those programs are using non-native GUI frameworks. But my point is that as a Windows user, I can't tell what native is, because approximately every program looks different.
- ThinkBeat 4y ago

mattanimation 4y ago

Oh nice, I was literally testing imgui in zig today, but I'll have to give this a test too.

tnodir 4y ago

Also see https://github.com/frang75/nappgui_src https://github.com/frang75/nappgui_src

malkia 4y ago

LispWorks GUI is named similarly :) - Capi - http://www.lispworks.com/products/capi.html http://www.lispworks.com/products/capi.html - it just reminded me of it when I've read the name, that's all...

sharikous 4y ago

Nice. Is zig easily callable with the C ABI? This could be a really nice thing to have for everybody using a different language too

dosshell 4y ago
Zig and C are best friends. Zig can even compile C.
- norman784 4y ago
  IIRC there were some limitations with C macros, if that is a think, my understanding of C is very limited, but I was interested in zig a while ago and watched some presentations.
  - cturtle 4y ago
    Yes not everything can be imported perfectly. With my project making a Lua wrapper library in Zig I had to fix a few poorly translated macros. Overall though most translated just fine. I think with some work on Zig’s end a few more cases could be handled though.
Zen1th 4y ago
Yea :) In fact I'm planning to add a C ABI to Capy (I already did some small tests in the c_exemples folder)
LAC-Tech 4y ago
In Zig you literally just import a C header and start coding. There's no FFI like rust and no header guards like C++.
- Tozen 4y ago
  By the way, Vlang has that level of C interop as well (https://github.com/vlang/v/blob/master/doc/docs.md https://github.com/vlang/v/blob/master/doc/docs.md), plus an outright C2V transpiler (https://github.com/vlang/c2v https://github.com/vlang/c2v) and can be compiled to human-readable C.

ducktective 4y ago

Fantastic! This is similar to the C library `libui` since it also acts as a wrapper of native libraries of each platform. 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. https://github.com/andlabs/libui https://github.com/andlabs/libui https://github.com/janet-lang/janetui https://github.com/janet-lang/janetui

nine_k 4y ago

Very nice! 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!)

eyelidlessness 4y ago
Many (maybe all?) native UI environments have a concept like a “logical pixel” which is scaled appropriately. I don’t know how much this project avails itself of those, but I did see that the web/WASM implementation uses `px` which in CSS is such a “logical pixel”. That has other issues on web of course, but I’d generally expect such a project to degrade on web because the native “UI” is very low level and unopinionated.
Zen1th 4y ago
It's already handled, each Window has a `source_dpi` which is the DPI for which the layout was made, and depending on that and the monitor's DPI, Capy will habdle the scaling.

rvz 4y ago

Great library, however: > 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.

badsectoracula 4y ago
Sadly Gtk developers were in a position during Gtk2's peak to help solve that by making Gtk2 "the" Unix desktop GUI API - it was used and targeted to by pretty much everything and it being a C API meant that it could remain backwards compatible for pretty much forever. But they instead decided to break the API with Gtk3, repeating the Gtk1 to Gtk2 transition mistake (which at the time it wasn't that big of a deal since Gtk1.x was never as popular or widespread as Gtk2). And just as some projects finally managed to convert their Gtk2 code to Gtk3 code, sometimes after years of work, the Gtk developers awarded them for their effort by breaking the API again in Gtk4. IMO at this point relying on anything Gtk4 is a mistake, though sadly there aren't many alternatives. Qt, being essentially a commercial middleware that also happens to have OSS-licensed code drops, has different priorities - and even if they wanted, being written in C++ which has no real stable ABI means they wouldn't be able to provide stable APIs anyway. Other toolkits are asphyxiated by the oxygen that Gtk and Qt are siphoning away so they barely get any support. EFL seemed to be ok (in that it was a sort of usable, sort of existing, C-based API that is apparently good enough for a desktop environment to be made with) but the author seems to have decided at some point to refactor (and thus break) the entire thing. Motif has been stable since the 90s, but it also has seen little improvement since the 90s either - it is also too tied to X11, meaning that having a crossplatform version (which is something that people would want) is quite hard. And thus we get Electron, which is almost a step before bundling an entire VM and OS inside a window.
jakearmitage 4y ago

madeofpalk 4y ago

What does "native" even mean? How is this native in a way that HTML - which renders OS-native text input and button widgets - isnt?

rafram 4y ago
> which renders OS-native text input and button widgets Not anymore in browsers with content process isolation (which is essentially all of them). Native controls have to be imitated.
- eyelidlessness 4y ago
  I’m confused. Why would browsers’ isolation of anything preclude rendering native controls? Native controls aren’t all in some global singleton process shared across non-browser apps (at least not in any environment I’m aware of, and the thought of a design like that fills me with dread). All a browser needs to do to render native controls securely is to render them as opaque to the JS/DOM runtime. This has even been formalized as “shadow DOM”. At least so far as I’m aware, Safari still renders native controls by default. Other browsers vary in their use of native controls but that’s been the case for decades.
  - jcelerier 4y ago
    > Native controls aren’t all in some global singleton process windows used to render scrollbars in-kernel (idk if it still does but it even did for 10: https://www.fortinet.com/blog/threat-research/one-bit-to-rule-them-all-bypassing-windows-10-protections-using-a-single-bit https://www.fortinet.com/blog/threat-research/one-bit-to-rul... )
    - eyelidlessness 4y ago
      Holy hell

mark_l_watson 4y ago

I first read “Capy” as CAPI, LispWork’s proprietary cross platform UI library (that is really very good - I am a LispWorks customer). 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.