[Idea / Suggestion] "Glimmer components": the idea is to have different glimmer widgets, no matter the style, that could be integrated / included and re-used. For instance, rubio-radio to be embedded in a tabbed notebook with a weather-displaying widget

[rubyFeedback]

[Idea / Suggestion] Glimmer for president erm ... "Glimmer components"

Hey there Andy,

My apologies for this rush of ideas. Please don't waste too much time
thinking about all the work implementing these ideas would bring. I
am more interested to see how glimmer evolves and changes and
improves; not all ideas I suggest are great. They are fragments of
a chaotic mind ... :D

Recently you (and I suppose kojix2 too) worked on ruby-radio, I mean,
rubio-radio. You mentioned this on your blog at
https://andymaleh.blogspot.com/ lately.

(I have not yet checked it on windows. A lot of the GUI I do is
actually for windows really, because on linux the commandline
works very well for my own personal use case. But I have a few
elderly relatives who have all sorts of health problems, so
I am trying to make things a bit better there - but also for
selfish reasons, so I can try to keep the time investment to
help them lower, so I can focus on other things lateron.
That's one big reason for me why I invest more time into
GUIs. But GUIs are also quite interesting in general, IMO -
I remember Alan Kay's old lectures, if you haven't watched
them yet, it's quite interesting how he spoke about really
old GUIs. But I digress so back on topic.)

So let's assume rubio-radio works, and is feature complete
and is described via the glimmer DSL. Ok, all is fine.

I am also working on a small libui widget for windows that
helps me compile things there. Perhaps via msys2 and gcc,
but I also want to try cl.exe from Visual Studio and see
whether I can use it correctly; and whether I may turn
autoconfigure-based projects into working "Makefiles".
(I have a set of scripts that I could adapt here.)

Anyway. This is just a lengthy introduction so far. Sorry
for that.

Now let's say I am bored on windows, and while I am compiling
something, I want to listen to rubio-radio!

I can have two different widgets, so one for the compile related
GUI; and one rubio-radio. But I could also want to combine these
two, via a tabbed notebook. First tab is the compile widget,
second one rubio-radio.

This is just an example. I am sure you can find many more examples
similar to this. And perhaps we can have a big libui desktop-like
widget set too! But anyway.

So my idea is ... "ok, the code for rubio-radio works
and I want to integrate it ... but how?".

This is where "components" come into play.

My idea would be that glimmer itself could return/yield
the widgets for such components. So we probably omit
the window, and just get the "core" (the "meat" of
it, if you don't mind - vegetarians may not relate
to this so let's settle for "core") of an application.

So once I have the core, I could attach/add it to the tabbed
notebook, for instance. Or vice versa, we could use glimmer
DSL to attach/add different widgets, even those written by
kojix2 in the examples output (for the glimmer gem he maintains).
That would actually be the best, I think, if glimmer could
integrate these examples via a tabbed interface (notebook
like widget). But this is only an example. Of course we
could use a grid or vbox/hbox, but I think tabs make sense
for the user since you can kind of shift between them in
the same application, rather than having open several
different GUI applications at the same time.

The ideal thing would be where we could integrate all different
libui projects, no matter the "style" (DSL, or classic/original
verbose LibUI or monkey-patching fiddle).

I write this a lot about libui, but this could be extended to
the whole glimmer suite, where we can integrate glimmer with
other widgets, even if they don't use the glimmer DSL. I assume
you would prefer more applications in the glimmer DSL, but it
is not necessarily trivial to learn (well, not for everyone),
so this could be a baby step towards people becoming more
familiar with glimmer slowly, and gradually.

I don't know if and how you have a modular structure in glimmer
that would allow for this, and I am not proposing that this is
implemented when it takes too much time, so no worries - it's
meant just as an idea really. But if you ever come around to
think about this, it could be useful for people in general, for
when they use glimmer. Kind of like an additional entry point
eventually. I imagine something like the old superkaramba,
where people would write tons of glimmer-related applications.
(This may also need better styling support e. g. to make it
look pretty. But functionality is more important than pretty
at the least as a FIRST step. I usually focus on the
functionality first, and then afterwards I focus more on
styling or adapting it. I do that with HTML/CSS as well
as with ruby-gtk3. With libui obviously this is a bit more
limited right now but who knows what will happen in the
future.)

The ideal situation would be like a meta-glimmer or meta-meta-glimmer
where we can integrate and re-use widgets written/defined by different
people seamlessly. Like an "AppUniverse" for glimmer. And perhaps even
in different programming language (well ... if rubocop could perhaps
be repurposed to translate from ruby to crystal that would be pretty
cool - I imagine a speed improvement there if that would work well).

Anyway - this is just a rough idea. Don't worry too much about
implementing this.

Glimmer on! \o/

PS: I mentioned the weather-displaying widget. I forgot where but I think
you wrote one somewhere. Not sure if there is a variant for libui. Something
simple if it does not exist may be nice, if it does not exist yet. Or I simply
forgot where it was or misremember hmmm ...

[AndyObtiva]

I didn't finish reading your very long message, but half-way through reading it, I know the answer already.

What you ask for is ALREADY supported!

It's part of the reason why I encourage people to now build Glimmer DSL for LibUI apps with include Glimmer::LibUI::CustomWindow or Glimmer::LibUI::Application. If you build your app that way, it AUTOMATICALLY becomes a REUSABLE custom control (custom widget) that you can EMBED in another app!

I am in the middle of watching a baseball game. When I have some free time, I'll finish reading your message and respond with some examples.

Cheers and keep the ideas coming! But, I also hope to see more contributions or complete works from you in the future in addition to ideas! Open-source is always a two-way street.

[AndyObtiva]

Here is an example of reusing an app as a component (as I mentioned it is already supported).

First run this command under CRuby:

gem install rubio-radio

Next, add the following code to a file called launcher.rb:

require 'glimmer-dsl-libui'

# import reusable component defined with `include Glimmer::LibUI::CustomWindow` in Rubio-Radio
require 'rubio/view/radio' 

include Glimmer

# instantiate the custom window component called `radio` from Rubio-Radio, and pass `backend: 'vlc -I rc'` required option.
radio_window = radio(backend: 'vlc -I rc')

window('Launcher') {
  margined true
  
  vertical_box {
    label(' Click on one of these buttons to launch an app. ') {
      stretchy false
    }
    
    button('Rubio Radio') {
      stretchy false
      
      on_clicked do
        radio_window.show
      end
    }
  }
}.show

Now, run:

ruby launcher.rb

You should get this screen:

Afterwards, you can click the button saying Rubio Radio, and you get this screen:

By the way, components are called "Custom Keywords" in Glimmer DSL for LibUI. I know I've mentioned them to you before in other issues:

https://github.com/AndyObtiva/glimmer-dsl-libui#custom-keywords

From the link above: "Custom keywords can be defined to represent custom controls (components) that provide new features or act as composites of existing controls"

In Glimmer DSL for LibUI, components that are represented by Custom Keywords are either Custom Controls (including Area-Based Custom Controls) or Custom Windows. All of that is mentioned in the last link shared above.

Every application written with an entry point class that has include Glimmer::LibUI::Application or include Glimmer::LibUI::CustomWindow will become a reusable custom window component that you can launch from another app as a separate window.

Also, if the application author exposes the main body of their custom window as a separate custom control mixing include Glimmer::LibUI::CustomControl (representing what you call the core component or meat of the window), then you can embed their main GUI directly in your application's window instead of launching as a separate window, by doing the same thing as in the code above, but embedding the custom control directly under a vertical_box or tab_item for example.

(In Glimmer DSL for SWT, components are either Custom Widgets, Custom Shells (custom windows), or Custom Shapes)

Sometimes I wonder if you've paid any attention to what you read in Glimmer DSL for LibUI documentation or what you learned from its examples. The support for components was mentioned many months ago. I am surprised you asked for it in a new issue instead of simply knowing it exists and just using it successfully as demonstrated in examples.

I think you have a memory problem. Every once in a while, I mention to you all sorts of supported features, but you forget them a month later as if I never mentioned anything. Or, you ask me a question in an issue, I tell you no, and then a month later, you ask me the same question again. You might need to lighten up the load of your work on you. If you are working too hard, then work is hurting you. Or, maybe spend more time refreshing your soul with Christian worship. That helps people refresh their mind and body, and maintain strong memory and thinking faculties. I can attest to it as I go to Church and pray to God regularly.

Anyways, I'm closing this issue because it is already supported.

[AndyObtiva]

About this part of your write-up:

The ideal thing would be where we could integrate all different
libui projects, no matter the "style" (DSL, or classic/original
verbose LibUI or monkey-patching fiddle).

I write this a lot about libui, but this could be extended to
the whole glimmer suite, where we can integrate glimmer with
other widgets, even if they don't use the glimmer DSL. I assume
you would prefer more applications in the glimmer DSL, but it
is not necessarily trivial to learn (well, not for everyone),
so this could be a baby step towards people becoming more
familiar with glimmer slowly, and gradually.

This is completely wrong!

Everyone must be using Glimmer DSL for LibUI because it is 100% simpler in ALL cases than writing C-style code in Ruby.

What you're proposing is like asking developers to write Assembly code in Ruby. That's what using the LibUI C binding directly feels like. That is a non-starter. Only an intentionally idiotic programmer would try to write Assembly code in Ruby instead of just writing Ruby style code via a friendly Ruby DSL. There is ZERO value in supporting idiotic actions like that.

The whole point of Glimmer is to enoucrage everyone to write 1/2 to 1/10 of the code that is automatically protected from memory garbage collection problems and pointer issues using Glimmer DSL for LibUI. We don't want to encourage stupidity. Otherwise, writing Ruby GUI applications will be just as bad as it always was without using Glimmer, which is the reason why not many people use Ruby for building GUI apps. We intentionally do NOT want to support such applications and want to discourage them completely. If people want to choose to be idiots, they are alone in their path. I do not support idiotic actions and do not want idiots using Glimmer. I only want smart people using Glimmer who either get Glimmer right away intuitively or are quick learners and will see why Glimmer DSLs provide the simplest way possible for building GUI.

This is exactly like how DHH didn't want Java and PHP idiots in the past polluting Rails with their awful ideas. Because they wanted to support idiotic things like dependency injection and embedded queries in the view. He just ignored them. And, the badness of their ideas shows up in their work. A website written in Java that is trying to do what Rails does will be least 4 times the amount of code if not more, and is much more complex. Thankfully, DHH was smart enough not to support idiots who want to build idiotic apps like that while claiming Rails was not good for everyone