API simplifications with regards to the ruby side of libui-ng (LibUI)

[rubyFeedback]

Hey there kojix2,

LibUI has some code that could possibly be simplified.

For instance, the examples typically have this:

LibUI.main
LibUI.uninit

Or, as another example, to indicate what should happen when the main window
is closed:

LibUI.window_on_closing(main_window) {
  LibUI.quit
  1
}

I assume that this is largely inspired by the C side of libui; probably there
are functions that correspond to:

LibUI.main
LibUI.uninit

From the ruby side, though, this is a bit cumbersome. It is not a big issue at
all, of course, but could the API be simplified a bit, in addition to the current
status quo?

For instance, LibUI.main and LibUI.uninit, could perhaps either be coupled
to just LibUI.uninit (which then also calls LibUI.main), or if you want to keep
it separate then a helper function could be added, such as (just giving some
name examples):

LibUI.loop
LibUI.complete
LibUI.finalize
LibUI.start
LibUI.main
LibUI.muninit # not a great name though, hehe
LibUI.demain
LibUI.unmain
LibUI.main_then_uninit # not good because ideally the method name should be short
LibUI.main_uninit

Anyway just some examples. Perhaps there may be even ways to omit these completely,
such as via:

require 'libui/autoclose' # or some other .rb file that could be used for this

For the other example:

  LibUI.quit
  1

Perhaps LibUI.quit could return 1 by default; or it could be used to quit anyway,
and the return value may not be necessary.

My thinking here is that we could try to simplify some of the libui code in general.
There may be other areas where libui could be simplified perhaps; I am thinking
of the ffi calls, perhaps some could be abstracted into a helper module that is
optional and bundled via the ruby libui bindings, but this issue here is mostly
about just making libui a bit more ruby-like than C-like. See also your own example
at uing with the DSL. :)

(I don't know the C internals, perhaps a wrapper module may be necessary to
separate concerns here; I am mostly just thinking in terms of ruby code that
goes into .rb files. ruby-gtk also used to have, I think, Gtk.init for a long time,
before it was removed; or it was Gtk.main, I forgot. This was I think before kou
maintained it, Masao Mutoh or so was the maintainer before, I don't fully
recall the name correctly perhaps, but I think it was in the time period from
2005 to 2010 or so, give or take.)

[kojix2]

This looks simple, but it is not simple. The reason is garbage collection.

It is not just about writing cleaner code. The problem is deeper than that.
libui-ng has some memory management built in. Before UI.uninit runs, it checks one thing: has all the memory already been freed?
To make a good Ruby API, we need more than that. We need a system that frees memory automatically, before UI.uninit runs. To do this properly, we would need to build something like a reference counter on the Ruby side. This would take a lot of work.

Of course, it would be possible to just use block syntax and leave memory cleanup up to the user. But in my understanding, that would create a mismatch between what the syntax suggests and what actually happens

The truth is: libui was not designed to be easy for Ruby or Python. If I could redesign libui from scratch, I would probably change its API design. I would change the rule about who allocates memory and who frees it. I would make this rule easier for languages with garbage collection, like Ruby, Python, and Crystal.

So yes, libui looks easy on the surface, but it is not so easy or simple to use. Maybe this problem will be solved one day, if someone builds a new version — something like "libui2".

[kojix2]

libui and Garbage Collection - Challenges in Creating Ruby and Crystal Bindings

[kojix2]

Actually, libui-ng has a lot of conventions. But in reality, people don't always follow them correctly. For example, the Crystal bindings that existed before uing did not handle closures well. They still worked, but they probably caused unexpected errors at random, unpredictable times. I suspect this is not unique to Crystal — bindings in other languages are probably often like this too.

Also, libui-ng itself had many bugs. Recently, I used AI to help fix many of these bugs, and libui-ng should be considerably more stable now than before. In other words, not everyone follows libui's conventions, and libui-ng itself was not clean either. And honestly, my own programming skills were not strong enough — without AI to investigate and explain things to me, I would never have reached this understanding on my own. That's the reality of it.

Of course, Ruby's LibUI is not perfect either, and it has many rough edges.
Software is always unfinished — I think that's just how reality works.

In that sense, my comment here might not feel entirely fair.
You have your own opinion too. This isn't meant to change your mind — please just take it as my personal impression :)