Helper-module for ruby-libui?

[rubyFeedback]

Hey there kojix2 and everyone else interested in reading about an idea,

The ruby wrapper over libui-ng is primarily based on fiddle, as the
example of this code, written by kojix2, shows:

https://github.com/kojix2/LibUI/blob/main/lib/libui/ffi.rb

This is, I assume, basically a wrapper over the functionality offered
by C, more or less 1:1. And I assume kojix2 probably wrote most of
this by hand; would be interesting to see whether AI could help here,
but that's an aside off-track idea.

For the most part the code works very well; the examples distributed
work, and people can build more complicated stuff with this too.
kojix2 even demonstrated this for crystal via uing, such as seen here
in the gallery:

https://github.com/kojix2/uing?tab=readme-ov-file#examples-gallery

kojix2 even showed a DSL example for crystal here:

https://github.com/kojix2/uing?tab=readme-ov-file#dsl-style

Now - most of ruby-libui is quite simple to use, but there are also
C-internal things that I find a bit complicated. An example is here:

https://github.com/kojix2/LibUI/blob/main/examples/basic_draw_text.rb#L72

I understand that this is done largely to deal with the underlying C
structure, e. g. using .malloc or RUBY_FREE and so forth, avoiding segmentation
faults and other scary things.

For my brain, though, this is difficult to handle and process. So one of my basic
ideas here was to be able to abstract away (and simplify) this - but ideally do so
on the ruby-libui bindings themselves, so that we don't have to do so
manually in our own downstream code.

So that is my first idea.

The second idea is somewhat related to this, in that I'd love to have
some kind of useful functions (code) that we can use in our applications.

For instance, if I have a widget, then I'd love to do:

widget.set_font('Hack 35')
widget.set_tooltip(
  "Pressing this button will print out the user's current data."
)

These are just examples. More functionality could be made available.

Of course, for this to work, the underlying widgets would have to
support it. But these are just examples, anyway. Perhaps libui-dev
supports tooltips already.

I would like to thus ask whether we could add some kind of helper-module
to ruby-libui itself. What should this module be able to do?

Well - for one, it could bundle useful functionality. With that I mean
things that people may need in downstream applications.

For instance, in the basic_draw_text.rb example:

https://github.com/kojix2/LibUI/blob/main/examples/basic_draw_text.rb#L72

We have to set various aspects of the font at hand such as:

default_font.Family = Georgia
default_font.Size = 13
default_font.Weight = 500
default_font.Italic = 0
default_font.Stretch = 4

I think unifying this into a specific method-call, would be more
convenient. As said the API could be:

set_font('Georgia 13')

We could assume more though such as:

set_font('Georgia 13 italic')
set_font('Georgia italic 13')

And so forth. Or extra-arguments to font, via block and/or extra
arguments to the method at hand.

The names are just examples. We can think of better names, of course.

For instance, in my downstream code, I sometimes create a text label
widget in ruby-gtk, and then I call:

.make_bold

To use the bold variant of the font at hand, same size, only bold as
main difference. I like having such a simple API because it is very
easy to understand it (for me). But this is not so much about my own
personal preferences; I think more of helper-code that ruby-libui could
include, that several people may find useful.

I have no specific suggestions which API and functionality would be
useful here - my main point is more a question. Should or could we
offer such a helper-module? Would it be useful? These are perhaps
different discussions that could be had too. My question here is more
whether we should bundle - and thus make available - such helper
functionality, to simplify writing application code.

Somewhat related to this is whether we could or should also add and
offer a DSL. I have no strong preference here either; we could adopt
the same DSL in crystal just fine. One benefit of the same DSL would
be that people don't have to learn something special. We could also
then suggest to other language bindings to also consider implementing
similar DSLs. Ideally the DSLs could even share the same method name,
but this is not necessarily that important. They could also implement
the screenshot gallery kojix2 made available for crystal. I think if
many different developers would kind of agree on the same, this would
be a good outcome for everyone. Of course we may still have to solve
the issue of maintaining libui-ng itself, but perhaps opportunities
present themselves in the future, not unlike how it was for andlabs
libui too. People come, people go, that is unavoidable, but ideas
can remain and persist, and perhaps be extended. Anyway, this was my
idea for the most part. I am not suggesting that anyone specifically
would implement this, mind you - this is more a suggestion as to whether
this could be useful for more people in the long run. Right now I don't
know how many folks are using ruby-libui for instance. 228 are starring
the project, so I assume they may have used ruby-libui, but probably
more than 228 use ruby-libui, so ...

[kojix2]

Hello,
A few things I wanted to share:

• I don't remember the details clearly, but many of the more complex examples were AI-generated. The simpler ones were built one by one, usually with a mix of hand-coding and AI help.

• The RUBY_FREE style in Fiddle was, if I remember right, there for backward compatibility with older versions of Fiddle. Newer Fiddle handles this more cleanly. Backward compatibility was a big concern for the ruby-LibUI project at the time, and while I'm busier these days, that's still my general philosophy.

• I'm not a web engineer, so most of my programming is hobby work. My interests have moved toward lower-level things — I'm especially fond of Crystal, and lately I've been curious about how Crystal and LLVM work internally. If anything, I'd like to improve the long-term sustainability of libui-ng itself. Adding helper utilities to LibUI is not really something I'm looking to do.

  • To be clear: I'm not a static typing advocate. I actually prefer Ruby's dynamic style over Crystal's from a syntax standpoint. Unnecessary type constraints on functions are, in my opinion, best avoided. The trend is moving toward static languages, but I think object-oriented programming and metaprogramming still have a lot of unexplored potential — and I think that will become clear in time. Of course, that comes at the cost of the performance that draws me to Crystal in the first place: its speed and memory efficiency.

• One suggestion: try asking an AI agent to explain the libui-ng C source code to you. AI is quite good at explanation, and that side of things has improved a lot over the past year — not just generation. It should help you get a better handle on the C internals and related topics. Ask it lots of questions; you'll learn a lot.

(Translated from Japanese with Claude)

[kojix2]

Let me explain more concretely. The easiest approach is to ask DeepWiki questions.

https://deepwiki.com/libui-ng/libui-ng

For example, suppose there's a feature you want in libui-ng. You might ask questions like:

• "Is it possible to do ○○?"
• "Why doesn't ○○ exist? What's your opinion?"
• "How would I go about adding ○○?"
• "What would be the hardest parts of implementing ○○?"
• "Is it possible to achieve ○○ across all platforms?"
• "What would the API look like in that case?"

Also, since libui is a collection of three different implementations, it can be useful to ask things like:

• "How is ○○ implemented on Linux, how on Mac, and how on Windows?"
• "What happens on Linux when you call the function ○○?"

Keep in mind that DeepWiki's answers are not always correct — the accuracy is around 85% or so. But then again, that's roughly the same as a human expert from a different field.
The important point is this: coming up with questions that reflect your own interests and curiosity is your job, not the AI's. This is something AI cannot replace.