Custom toplevel methods: aiming to enhance LibUI

[rubyFeedback]

Heya kojix2,

I would like to try to convince you a little bit of making it "nicer" to work with LibUI. :)

Let me explain what I mean with this.

Consider the following file:

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

In it the text is defined via several method calls (I believe these are method
calls but could be function calls, probably wrappers over ffi and C):

default_font.to_ptr.free = Fiddle::RUBY_FREE
default_font.Family = Georgia
default_font.Size = 13
default_font.Weight = 500
default_font.Italic = 0
default_font.Stretch = 4

And Georgia as constant refers to the string:

Georgia = 'Georgia'

Additionally tons of fiddling have to be done via malloc. This is the hard
part for non-C programmers.

For instance:

handler_draw_event = Fiddle::Closure::BlockCaller.new(0, [1, 1, 1]) do |_, _, adp|

And several more calls, many of which are not easy to understand.

Would it be possible for LibUI to support simpler APIs? For instance:

LibUI.set_font('Georgia 13')
LibUI.set_font('Georgia 13px')

Or something like that? Could be other names. Data omitted can default
to some values, such as in the example above default value for italic
being 0 and for stretch being 4.

If I understand your point then you want to closely map towards the LibUI C code
to reduce workload for bindings and writing code in ruby, e. g. supporting files
such as:

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

That use case is fine. But I am also coming from another use case in that I'd
love to be able to more easily make changes, such as using different fonts,
perhaps colour support and so forth too.

I am not necessarily suggesting that every font-related activity, such as BOLD
text or underline or italic, has to be supported via module LibUI as such. But
the part that I really find difficult is to understand all the malloc-specific things
and I'd like to try to avoid or bypass them if I can. So a toplevel API, or perhaps
a custom class that I can subclass from, or another way, would be really neat.
It could also make LibUI easier to work with directly and people may need
less code e. g. all the font-specific part or malloc-specific part could become
part of LibUI.

If you don't want to have this directly, by default, then perhaps LibUI could
add a secondary helper .rb file? So, we could then perhaps require that
.rb file and in that .rb file you could provide a few helpful methods that can
simplify working with libui code. I am not suggesting that all of ruby-libui
becomes like that, but in particular the malloc specific stuff I'd ideally love
to completely bypass and ignore.

Anyway, if this takes too much time don't worry too much. It is just a
suggestion. :)

Best regards and like always please feel free to close this issue at any
moment in time!

[AndyObtiva]

I think you posted this issue in the wrong project. LibUI is a Ruby C binding, so it is meant to be as simple as possible and just a basic mapping from C to Ruby.

You’re not supposed to fiddle with malloc directly. You’re supposed to use the high level Glimmer DSL for LibUI to write code the Ruby way, and it automates all management of low level calls and malloc/free usage.

Right now, in Glimmer DSL for LibUI, you write font code like this:

font family: 'Helvetica', size: 12, weight: :normal, italic: :normal, stretch: :normal

Or just:

font family: 'Helvetica', size: 12

This is as simple as it gets. It’s very readable and human friendly, and you don’t have to fuss with malloc.

If you have requests for improvements, please post them at the Glimmer DSL for LibUI project.

[kojix2]

@rubyFeedback
Please open source what you are making on Github or Gitlab. Not all of it, just some of it. Otherwise, it's hard for me to collaborate with you. I'm not sure what's stopping you, I think you'll get used to using Git after 2-3 days of exposure. It's worth it. Give it a try. This is the shortest route to solving the problem. If you are having trouble with this, please ask an engineer you know for remote help. If you are good at Japanese, it could be me...