kojix2 / LibUI

A portable GUI library for Ruby
MIT License
208 stars 10 forks source link

[Question mostly] A conceptual API-question: passing 1 (or 0), as opposed to true (or false), in libui #83

Open rubyFeedback opened 11 months ago

rubyFeedback commented 11 months ago

Hey there,

We can create a new entry in LibUI via:

entry = LibUI.new_entry

Then, we can set it read-only, via:

LibUI.entry_set_read_only
LibUI.entry_set_read_only(entry, 1) # so 1 means true, aka yes, aka "yes, make this entry read-only".

However had the 1 there is awkward. I assume in C we work with 0 and 1 rather than false and true, correspondingly. So this part I can understand. C expects 0 or 1 - no problem there.

My question is, though: could we modify this to also allow true and false values, from within ruby? Such that this API is also possible:

LibUI.entry_set_read_only(entry, true)

I don't know enough about C and fiddle to understand whether this is feasible, but I think when working with ruby, it is nicer to stay "within" thinking about ruby (e. g. true and false, rather than 0 or 1.

In my gem libui_paradise this is not a problem because I use helper methods, such as:

entry = create_entry entry.readonly

So I don't even pass 1 or 0 directly, when writing code for GUIs. But in "raw" libui, it is a bit awkward to have to use 0 and 1. ("raw" libui is, in this context, examples with working ruby-libui code where I do not use any external dependencies. I distribute both standalone-examples as well as non-standalone examples; the reason for providing standalone examples is so that other people can learn from these examples; but also as some kind of weak "test suite" so I can ensure things work fine with the "raw" libui bindings, rather than me making a mistake with add-on helper code that I wrote, and may be buggy).

Anyway. This is not so much an issue request for any change; I am more interested if this were possible, in theory. Perhaps I should ask kou - he knows everything. :)

Please feel free to close this issue at your leisure.

AndyObtiva commented 11 months ago

Glimmer DSL for LibUI already supports what you ask for (and has supported for more than a year). You can write the simplest code possible in existence with it, and it works with real true / false boolean values in Ruby.

require 'glimmer-dsl-libui'

include Glimmer

window('Read Only Entry') {
  entry {
    read_only true
    text 'Read Only'
  }
}.show

Screenshot 2023-12-25 at 8 31 12 PM

Declaratively typing read_only true is as simple as it ever can be possible! It can't get any simpler than that. That's because the declarative Glimmer GUI DSL is even simpler than normal imperative Object Oriented Programming. That said, the Glimmer GUI DSL is Object-Oriented (all the DSL control calls return normal Ruby objects), so you do Object Oriented Programming with it a different way that is more suitable for representing the structure of GUI (declarative instead of imperative), resulting in less code to maintain, better readability, and higher productivity. It's much simpler to do Object-Oriented Programming with a DSL than without a DSL when there is a need to specify a visual hierarchy declaratively.

In Layered Architecture, what you ask for is considered above the level of abstraction of the LibUI Ruby binding that focuses on C to Ruby direct mapping, and can be handled in a higher level library like Glimmer DSL for LibUI that follows the Adapter Design Pattern to adapt C 1/0 values into Ruby true/false values.

The LibUI Ruby binding needs to have a close 1-to-1 mapping to the C API in order to remain as simple as possible. Adding higher abstractions to the same library breaks the idea of Layered Architecture and forces complexity into the Ruby binding, which makes its maintainability more expensive. So, it's not a good idea.

You always seem to ask questions about things that are already solved and handled well enough by Glimmer DSL for LibUI, which is an award winning library that won a Fukuoka Ruby 2022 special award by Matz the creator of Ruby and got presented twice at RubyConf in 2022 and 2023 (in addition to the older original Glimmer [for SWT] getting presented at RubyConf 2008). Just use it and support me. Be nice and provide support. Any smart person would use the library that Matz liked, not intentionally ignore what Matz gave an award to, and would support the library in every way possible to help it grow (like by writing tutorials, docs, blog posts, libraries, apps, etc...). Wasting time asking about problems that are already solved or asking for unimportant features like cross-toolkit compatibility or cross-language compatibility is a total waste of time if you didn't even build a single thing with Glimmer in Ruby yet. The library is an open source project, so it can use all the support it can get. You can at least implement some of the ideas you suggest instead of lazily asking for stuff given that you are a Senior Software Engineer. Respect my effort and hard work instead of trying to undercut my accomplishments! Don't be mean or unhelpful and intentionally try to re-invent the wheel or undercut the Glimmer project even though most problems you are thinking of are already solved well enough in Glimmer DSL for LibUI. Just use it and support it like any normal nice person would! Or, if something is not simple enough, provide feedback to improve and respond to PRs until you are satisfied enough. That's what's considered nice supportive behavior. I don't like it when you create PRs and then disappear so that after I respond, you never respond back to tell me if I addressed your concerns. That's not productive at all. It comes across as trolling.