Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rubyFeedback opened this issue Dec 25, 2023 · 1 comment

Comments

@rubyFeedback
Copy link
Collaborator

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
Copy link
Collaborator

AndyObtiva commented Dec 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants