Partial DSL support / hybrid applications

Hey there Andy,

This takes a bit to explain, and I may have misunderstood things, but either way I may also have an idea to a potential improvement. Perhaps this is already possible as-is, but in that event I lack knowledge how to apply it.

Right now the glimmer-suite heavily focuses on the DSL build style, that is, we use a DSL to describe an application - typically a GUI, but with opal and rails we should have web-support too, I think. And perhaps commandline GUIs like ncurses :D (but, as I said before, I don't quite suggest it because I hate ncurses ... it would be kind of cool to build fancy, emoji-driven commandline "GUIs" though, just to tear down that old barrier of legacy ...)

In libui we may have code like this:

main_window = LibUI.new_window('Text-Drawing Example', 640, 480, 1)

I found that combining this with a DSL-centric style is a bit difficult. You show various examples how to do so, e. g. mixing some module and what not. So I assume it is possible to mix a DSL-style as well as the traditional ruby object.method_name() variant.

But what if we could combine both?

For instance, in pseudocode:

main_window = LibUI.new_window('Text-Drawing Example', 640, 480, 1)
# add a hbox there
hbox = LibUI.new_horizontal_box
LibUI.box_set_padded(hbox, 1)
LibUI.window_set_child(main_window, hbox)

# and now comes the interesting part in pseudo code
spinner = Glimmer {
  spinner
}
# add a button and activate / deactivate the spinner on button
# click event
# and add more code to add the spinner into the hbox

What I am trying to say is that we could combine BOTH approaches, that is have glimmer deal with the implementation detail, where this could be a DSL, but then embed that widget right into the main_window variable or hbox.

So, in other words, where we could combine both the DSL approach as well as the "classical" OOP style. The above are just syntax examples, please evaluate them accordingly with code that would work.

My idea here is to keep on, for instance, using the main_window, just via LibUI.new_window, but then, based on which module to include, to add widgets created via the glimmer DSL. But not ALL of it, kind of only the "widget content", so I could fine-tune and choose which part to use.

So when you have glimmer DSL code like this:

window('Basic Image', 96, 96) {
  area {
    image {

I would omit the window() part, but I would use the area {} part and then embed this into the main_window variable.

I am not sure if I managed to explain my idea. The idea would be to be able to freely mix both approaches and styles.

There may be one concern in that this is too much of a niche case, and not used by many people, which may be a valid concern. So this may not be worth to implement. But I still wanted to mention it, perhaps there are already ways to combine both as it is, so it seemed better to mention it. As always feel free to close this issue at any moment in time and interprete accordingly to your vision of Glimmer.

I don’t get the use case you are proposing.

DSLs are already object-oriented, and the whole point of coming up with a domain specific language is to make it much simpler and quicker to build components within the DSL domain, which is GUI in the case of Glimmer DSL for LibUI. I do not see any point whatsoever of writing non-DSL code given that the DSL API is complete, giving full access to the LibUI API, but more intuitively and with better readability.

Of course, as with everything in software engineering, everything is possible to support, but that doesn’t mean everything is a good idea.

I don’t see any value in what you’re asking about whatsoever. It’s quicker, cleaner, and better to reimplement code not written with the DSL using the DSL than to support embedding the DSL into non-DSL code in my opinion. So, that renders this request moot.

As a last note, remember that you can get access to any wrapped Glimmer DSL component using the .libui method, and then you can do whatever you want with it as a LibUI object.

For example:

@mw = window
puts @mw.libui.inspect # prints => #<Fiddle::Pointer:0x00007f9ae36b4520 ptr=0x00007f9ae3458cc0 size=0 free=0x0000000000000000>

But, it is not really considered beneficial at all. It is much better to keep operating within the friendly DSL. The whole point of it is to make the life of software engineers much more productive and the code more maintainable and understandable.

AndyObtiva / glimmer-dsl-libui

Partial DSL support / hybrid applications #24