[Related to the RubyConf 2022 Talk in about 3 months] If you have time during the talk, could you also mention future ideas and goals for glimmer? about glimmer HOT 1 CLOSED

IF however had you may have some time, could you also mention some future ideas for glimmer? Obviously
within just a few minutes you can't cover everything but perhaps an idea or two related to the future ("the
future is hard to predict") could be ok? It would be interesting, evidently for me but perhaps also for other
folks who may wonder "what's coming up next for glimmer". There are only 24 hours a given day, so you
have to focus and prioritize - absolutely understandable.

This is a reasonable question and idea.

I think the answer is yes. I plan to mention what is coming in the future for Glimmer DSL for LibUI towards the end of the talk. But, keep in mind that the talk is only focused on Glimmer DSL for LibUI, not Glimmer in general.

As far as for what's coming to Glimmer DSL for LibUI, it will depend on the state of libui-ng around the time of giving the talk at RubyConf 2022. Just hang tight and you will find out after RubyConf 2022 when the talk is published online.

To make this question not solely "meta", leaving you too clueless, I give a few questions - don't worry
about them here, these are just some "idea givers" or "shaping glimmer" related. Not all are equally
important, they really are just to give some "what could be asked" context/questions.

How many videos do you plan on publishing in total? :D

For Glimmer DSL for SWT, the series is almost over. The number will be 35 videos (we're at 31 now). But, there is an uncertain possibility that there would be an additional 36th video in the future.

Will there be a glimmer DSL that can be automatically tested (a glimmer specification) by others to
re-implement or add support (a bit like rubocop, but testable, so some kind of "spec")?

It's funny you asked about this because at one point I built Glimmer DSL for Specification, which I actually released as an open-source project, but then I decided it was not really needed given the availability of the MiniTest Expectations DSL, so I archived it.

As for a Rubocop checker for Glimmer GUI DSL syntax, this is definitely a possibility. I just added it to the TODO file.

As for a general Glimmer spec, I do not plan to create one because as mentioned in the past, the design of Glimmer intentionally follows the API designs of the different GUI toolkits it supports, so there is not one general spec, and I do not see value in having one as it will limit the creativity and diversity of ideas that come from different GUI Toolkits.

Is glimmer really trying to take over the world?

No

How to get people to commit to a global glimmer "store" (or, simpler, applications written and
supported in glimmer, and also in regards to long term maintenance, e. g. if glimmer itself
changes over the years, whether it may still support legacy applications written years ago)

I am not sure why you asked this question again given your previous issue about it. I already answered your question fully there: #24

In summary, people could already contribute Glimmer widgets and apps to GitHub as open-source projects, so there is no burning need for an App Store, but it's a nice-to-have that could be developed one day.

With GraalVM we can have statically compiled native binaries at the least on linux, perhaps
on windows in the future as well. Would we then be able to pack up glimmer applications in
that way?

GraalVM is not as nice as it seems. The GraalVM Native Image makes a closed-world assumption that complicates building native executables significantly by requiring you to have the Java source code for SWT, so it is not as simple as 1-2-3 or as convenient as Glimmer DSL for SWT's current glimmer package command since it puts the onus on the developer to meet all of GraalVM Native Image's closed-world assumption requirements for their application.

Also, more recently, Glimmer DSL for SWT apps run relatively quickly as they start within 2.5 seconds only on the fastest Mac M1/M2 chips. I would expect their performance only to improve further with time, rendering GraalVM completely unnecessary.

Read my answer to this GraalVM GitHub issue for more details: #19

Will glimmer try to adapt to more GUIs such as SDL/Gosu or any other variants?

Only selectively. I do not see value in supporting gaming-like GUIs like SDL/Gosu, but I am planning to explore building Glimmer DSL for WX once the Ruby binding for wxWidgets is resurrected in the new rwx project.

But, Glimmer has enough GUI toolkit support today (7 GUI toolkits) to actually be more than ready for production use by software engineers, so they do not really need me to support any new GUI toolkits. Any new support that might come is just nice-to-have, not must have.

How would examples look about existing GUIs that want to make use of glimmer, but
without a full rewrite? E. g. only using individual glimmer components and widgets
without a full rewrite of the underlying base.

Actually, in Glimmer DSL for SWT, the answer is yes. That is because you can have parts of your GUI built in pure Java, and then import them into Glimmer DSL for SWT with JRuby and just reuse them with new GUI code developed in Glimmer GUI DSL.

As for other libraries (like Glimmer DSL for LibUI), the answer is no for today, but I might consider that possibility for Glimmer DSL for GTK given there is a lot of legacy GTK apps written in Ruby out there. I could probably provide similar support to what Glimmer DSL for SWT has, which can wrap any existing Java custom widget in Glimmer GUI DSL components.

from glimmer.