Andy Nutter-Upham, I just realized I didn't answer this exact question by you in full details (I read the original message on the phone while being quite busy with something a couple of weeks ago, and I somehow missed some of intricacies of your question): "If I missed the documentation and someone knows where it is, I'd love to read it. I think though that since this is a wrapper library there is instead reference to the underlying documentation (whose method names are a bit different, and whose arguments are a bit different) and I find that translation very challenging; especially since glimmer-dsl-libui is not yet complete, so your run into ineffective keywords if you rely on the underlying glimmer docs." Glimmer DSL for LibUI actually does have full documentation for the Ruby API: https://github.com/AndyObtiva/glimmer-dsl-libui#supported-keywords Someone asked me to add the documentation early on when the project was new, and I added it to that person's satisfaction. I hope it's helpful to you too. By the way, I also do mention under the "Original API" section that you could use the LibUI Go documentation as a reference: https://pkg.go.dev/github.com/andlabs/ui But, the most complete reference is the actual C headers: https://github.com/andlabs/libui/blob/master/ui.h And, the C headers are exposed as low-level FFI functions in Ruby as per the Original API (but it's not recommended that you use these method directly of course): https://github.com/AndyObtiva/glimmer-dsl-libui#original-api To give you an example of how the mapping from the C API to Ruby happens, suppose we have this C function: uiWindowSetTitle('My Application') The word before the "Set" or "Get" operation is the control object (e.g. window), and the word after it is the attribute (e.g. title). So, the equivalent of that in the Glimmer GUI DSL: window { title 'My Application' } Basically, we are declaring a window control with one nested attribute of title having the value 'My Application' The C API is procedural and imperative whereas the Glimmer GUI DSL is object-oriented and declarative, better mapping to the way we think of concepts visually while looking at a screen given that you could nest controls (widgets) within each other. If you need further help, do not hesitate to ask further questions at the Glimmer Gitter chat: https://app.gitter.im/#/room/#AndyObtiva_glimmer:gitter.im You shouldn't really get bogged down unless you are missing foundational grounding in software engineering concepts relating to desktop development in general, like MVC (Model View Controller). I've done GUI development professionally in older technologies like Java Swing in the past, and by comparison, Glimmer lets me leapfrog past productivity by 4x at least, sometimes 10x or even more (and it's that much faster in productivity than web development too, so it's great for building quick local apps or tools that don't need the web as it's much simpler, demanding a tiny fraction of web code only). But, it does assume you know MVC (Model View Controller) very well, and it benefits from also knowing MVP (Model View Presenter). Once you get the main ideas behind Glimmer, everything clicks, and things like exact APIs or detailed documentation wouldn't matter much anymore because the way you think with MVC/MVP is you start with the View layer from a GUI mockup to support a specific user workflow, and you either use native controls (like text and button, by looking them up in examples or the docs mentioned above) or you invent your own custom controls (both options are available in Glimmer DSL for LibUI). Of course, the native controls are only as complete as what is implemented by the underlying LibUI library. I know the authors of it are working on adding many new features, like a Tree control, Table sorting listeners, and some other missing features. They will all be added to Glimmer DSL for LibUI in due time when they get released in C LibUI. But, that shouldn't stop someone from learning the library and using whatever is available in it for now, or at least mastering the current features until more features are added in the future (especially given that you could always temporarily polyfill missing features by building your own custom controls if really needed). Cheers, Andy Maleh On Tue, Feb 14, 2023 at 9:27 PM grigoris charam &lt;xargrigoris(a)gmail.com&gt; wrote: -- Andy Maleh LinkedIn: https://www.linkedin.com/in/andymaleh <https://www.linkedin.com/in/andymaleh> Blog: http://andymaleh.blogspot.com GitHub: http://www.github.com/AndyObtiva Twitter: @AndyObtiva <https://twitter.com/AndyObtiva> ______________________________________________ ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org ruby-talk info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…