Closed rubyFeedback closed 10 months ago
kojix2
commented
10 months ago Hi @rubyFeedback
Sorry for the delay in getting back to you, but I think if you click on the blame button on GitHub you will get the information you are looking for. Is this what you were looking for?
kojix2
commented
10 months ago I think this issue is a good opportunity to explain what I am actually doing.
(1) Check that all libui-ng functions have been added to LibUI. (use the scripts in the script directory) (2) Add C functions to the FFI class.
That's all. Scripts can miss changes, so when in doubt, use the BLAME button above to track changes.
To tell you the truth, I am mechanically adding a new function and have not fully checked the behavior.
If the function signature in C and the method signature in Ruby's Fiddle are the same, it should work.
But if you find any strange behavior, please report it.
Other than that
(3) Build libui-ng periodically using GitHub Actions (4) Check behavior when problems are reported (5) For issues that are difficult for me, I consult with kou, the fiddle maintainer
See also https://github.com/red-data-tools/GR.rb/wiki/How-to-update-GR.rb I should also prepare a document to help me maintain LibUI even when I'm sleepy.
I want to have a DSL too one day
Please go your own way.
Hey there kojix2 and everyone else who may be reading this,
Upstream libui-ng has a CHANGELOG file cody maintains (at the least sometimes). It can be found here:
https://github.com/libui-ng/libui-ng/blob/master/CHANGELOG.md
Rationale: I sometimes look at what is new (in libui-ng, and also in ruby gem LibUI here) and then I want to experiment (and add support) for things that kojix2 adds to LibUI, into the libui_paradise gem. But I often don't know what has been added (or I have not kept track for some days or weeks), and what has not yet been added (which is tied to ruby gem libui releases of course). Sometimes this is made a bit more complicated in that there are LibUI pre releases, but I often don't know what new features they bring. So I lag behind and may also miss out new features that the gem here already supports. So this is also a knowledge gap from my side.
Would it be possible for the project here to also keep a kind of compatibility table? In the simplest sense this could just be copy/pasted from upstream libui-ng, kept in the primary README, as a markdown table, and then we could add one more entry such as:
or
With the top header of that table then showing "SUPPORTED" (and a binary yes/no).
That way I know what is supported by the libui gem, and then I can add specific support for this into the libui_paradise gem.
Right now I am lacking behind in this because I don't quite know what is supported and what is not. Whereas, with a compatibility table, I can quickly say "ok set_width() should not work according to kojix2, so I can add code support for this into libui_paradise and also put a standalone example into the example/ subdirectory". This would also be super-convenient because my long term goal is to use one unified code base, to then support as many GUI toolkits, but also the world wide web + javascript, as well as commandline / terminal use cases one day - a bit like glimmer, but not as sophisticated (Andy goes the primary route of a DSL; I want to have a DSL too one day, but I am going the oldschool OOP-centric way first, as that is easier for my poor brain to understand. I am a slow learner these days).
At any rate thank you for reading this!