New release in 2025?

[rubyFeedback]

Hey there everyone using ruby-libui,

This is mostly a question for kojix2.

Should we aim for a (at the least one) release in 2025, for ruby-libui?

I am not quite done with all functions/widgets in examples2/ (about 52% or so), so I am not saying this should happen
soon. I'll have some more time to polish things there in the coming days - but perhaps we could aim for a release for
ruby-libui in 2025, say, May, June or July? Could be later too of course, August, or September or October.

One small reason for this idea for another release, is to change the necessity to use:

gem install libui --pre

It is documented, but I twice accidentally forgot using the --pre flag before, and it then confused me that some code
was not working, before I realised the code is in the pre-release of ruby-libui. (I now aliased it to "gem_install_libui" as
well as "install_libui", so I no longer install the wrong libui version.)

But perhaps we can also look to improve other parts for ruby-libui or see that libui-ng itself upstream may adopt some
changes, such as those available in libui-dev (I haven't checked all of those additions yet, so I do not know what was
changed there, but I think it would be nice, if libui-ng itself could adopt and integrate the changes. Then ruby-libui
could support these too. Or, if it is too late, to have a new release for ruby-libui, and then also another --pre release,
but I would recommend for the intermediate step, to perhaps go for one stable release of ruby-libui without --pre
flag for 2025)

Anyway, this is more of a question. I think if we have a loose milestone for 2025, we could look at the time to polish
a few things here or there and perhaps also see that libui-ng may get a few additions. So I may start a discussion in
libui-ng about this, and perhaps libui-dev as well, but before I do so, I'd like to ask about your opinion kojix2, as
the project here was started by you (plus, I don't understand the fiddle-specific code yet; perhaps eventually I
can dive into C again, but for now I am more focused on ruby).

Cheers!

[kojix2]

The difficult part of LibUI is not releasing the code itself, but how to prepare the binary files for libui-ng, especially the shared libraries that need to be included in the Gem.

The shared libraries of libui-ng must be created separately for Windows, Mac, and Linux. However, libui-ng does not have an official release. The only available builds are Nightly Builds provided through GitHub Actions. Unfortunately, these builds do not include the shared library for Windows. Because of this, I forked the libui-ng repository and build the shared libraries myself.

• Forked repository: kojix2/libui-ng (pre-build branch)
• GitHub Actions build settings: pre-build.yml

Maintaining this kind of setup is very difficult.

While working on the libui binding for Crystal and figuring out the correct link flags, I realized that managing libraries on Windows is much more complicated than I thought. To create a shared library that works on different Windows environments, you need advanced knowledge of Windows. This is likely one of the reasons why an official release of libui-ng has not been made.

(Translation from Japanese by ChatGPT)

[kojix2]

I wrote again a more technical background in Japanese, as the previous explanation may not have been clear enough. Then I asked ChatGPT to organize the content and translated it into English. I hope this new answer will help your understanding.

---

Check the contents of the LibUI Gem

First, let’s check the contents of the LibUI Gem.
Download the Gem file using the following command.

Before doing this, it's a good idea to create a working directory, as this process will generate multiple files.

cd ~/Download
mkdir libui
cd libui

Now, fetch the LibUI Gem.

gem fetch libui

This will download a file named:

libui-<version>-<platform>.gem

This .gem file is actually a simple .tar.gz archive.
So, you can extract it with:

tar -xzf libui-<version>-<platform>.gem

After extraction, you will see the following three files:

ls *.gz
# checksums.yaml.gz  data.tar.gz  metadata.gz

Among these, data.tar.gz contains the main content of the Gem.
Extract this file as well:

tar -xzf data.tar.gz

Now, you should see a directory named vendor.

---

Check the shared libraries

Inside the vendor directory, you will find shared libraries corresponding to different platforms:

• Windows: libui.dll
• Mac: libui.dylib
• Linux: libui.so

These binary files are packaged inside the Gem, allowing LibUI to work immediately after installation.

---

Should the Ruby side really manage these shared libraries?

Normally, shared libraries should be provided by the upstream project, such as libui-ng or libui-dev.

However, since libui-ng does not have an official release, the Ruby side has to manually build these binaries and include them in the Gem.

In open-source software (OSS) communities, there is no single person responsible for everything.
When there is a problem, we often have to find our own solutions.

---

Shared libraries are not standalone

These shared libraries do not work by themselves.
Each of them is linked to system libraries on the operating system.

For example:

• Linux: libui.so is linked to GTK3.
• Mac: libui.dylib is linked to AppKit.framework.
• Windows: libui.dll has a more complex set of dependencies.

To check which system libraries a shared library is linked to, you can use these commands:

ldd libui.so    # For Linux
otool -L libui.dylib  # For Mac

Windows has a different mechanism, and its library dependencies are more complicated.

Ensuring that these shared libraries work immediately after installation on different platforms requires deep technical knowledge and extensive testing across multiple environments.

---

I hope this explanation helps clarify the technical background of this issue.

[kojix2]

Yesterday, I compiled and debugged libui-ng and libui-dev for Windows by myself to use the libui bindings in Crystal. I initially intended it as a distraction, but it ended up taking a lot of time and draining my energy. I'm increasingly feeling that I shouldn't be managing this issue on my own. What we really need is someone well-versed in Windows application development. However, since most hobbyist programmers use Linux or Mac unless forced to do otherwise for work, such talent has become increasingly rare. (Translated by ChatGPT)

[kojix2]

One of the few good news was that I learned that in the MinGW environment, you can debug using gdb on Windows just as you can on Linux. I am not an expert in using gdb, but AI will politely show you how to do it. rubyfeedback, if you are going to tackle C, I suggest you use gdb. It is one of my favorite tools.

[kojix2]

In the past few days, I have built libui-ng many times from the pre-build branch of the kojix2/libui-ng repository. My goal is to use it with the Crystal programming language.

Building on Windows is surprisingly difficult. There are several conflicting factors:

1. CPU architecture: x86 / x64 / ARM
2. Compiler: MSVC or MinGW
3. C runtime: MSVCRT (older), UCRT (newer), or MinGW’s libc
4. Version control using manifest files

Mixing these options can easily cause build problems.

When using libui from Ruby, things are a bit simpler. We usually use fiddle to load the dynamic library at runtime, so we don't need to worry about linking issues like in Crystal.

Now I understand a bit more why the libui-ng team hasn't made an official release yet — it's complicated and quite a hassle.