libui-ng VS panama-foreign

I remember a few years ago, a few really cool cross-platform UI libraries were starting to emerge such as libui [0] that got me excited. I've kind of lost track of them since then (libui itself went dormant for a while before this fork) so I am not sure how mature/useful they are now, but the potential for writing native desktop UIs in basically any language seemed like an absolute dream. Perhaps it's feasible for very basic things?

[0] https://github.com/libui-ng/libui-ng

Linux/Windows/MacOS: https://github.com/libui-ng/libui-ng

There are a few libraries for GUI (for example, capy), and you can easily use any C libraries out there with @cImport (like libui), but it is still a work in progress.

It exists, at least for simple use cases. You are looking for libui-ng. wxWidgets of course also exists, but it is less a basic native wrapper than it is a complete toolkit emulating what doesn't exist where as libui seems to be more lowest common denominator (not sure but I think there might be a small amount of emulation, but not like wx I don't think).

There's now libui-ng [1] which seems to be active and already has many wrappers

[1] https://libui-ng.github.io/libui-ng/

Going to copy my Reddit comment over to HN because I think it's valuable:

---

One of the coolest things that's been worked on (by this same author, no less!) isn't even in the article!

Per has written a pretty-printer for MemorySegments and ByteBuffers that can hex-dump memory or render memory/buffers as their "struct" representations given some MemoryLayout.

You can also customize it with your own printers, it's wicked cool and helps so much to debug buffers when working with them.

https://github.com/openjdk/panama-foreign/pull/695

What do I mean by that? Have a look at this comment for an image of a raw memory structure layout I represented with MemoryLayout, and the pretty-print rendering of it:

https://github.com/openjdk/panama-foreign/pull/695#issuecomm...

[Here's the project github](https://github.com/openjdk/panama-foreign)

I am not using any special flag (is there one?) but the overhead seems quite high, especially considering the explanation on how these methods are compiled https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md

https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md ..look at these examples

I found the full context for the change written up here https://github.com/openjdk/panama-foreign/pull/554

Incentive for JVM devs? We know that C interoperability, malloc, free, structs are already supported on JVM natively since Java 14 with project panama's foreign-memory-api without JNI. I've been using sun.misc.Unsafe since Java8 and also LWJGL's C API.