AndyObtiva / glimmer

DSL Framework consisting of a DSL Engine and a Data-Binding Library used in Glimmer DSL for SWT (JRuby Desktop Development GUI Framework), Glimmer DSL for Opal (Pure Ruby Web GUI), Glimmer DSL for LibUI (Prerequisite-Free Ruby Desktop Development GUI Library), Glimmer DSL for Tk (Ruby Tk Desktop Development GUI Library), Glimmer DSL for GTK (Ruby-GNOME Desktop Development GUI Library), Glimmer DSL for XML (& HTML), and Glimmer DSL for CSS
MIT License
556 stars 17 forks source link

[Idea] "Standardized" glimmer components #37

Closed rubyFeedback closed 1 year ago

rubyFeedback commented 1 year ago

Hey there Andy,

This is just an idea again, please feel free to ignore/close at any moment in time.

Recently I have been playing again with libui-ng a bit, just to polish a few things.

I also saw kojix2 simple notepad example - somehow I missed that in my own gem.

When I was testing the notepad a bit, I wondered ... this could be made more fancy and useful. For instance, a widget on the left side that keeps track of the numbers, so if there are 100 lines in the notepad, separated via newlines, the widget on the left side could count from 1 to 100. And thus indicate on which line one is. This is probably already possible via libui-ng, or, at the least would not be as difficult. On windows this could even be useful, like a notepad replacement but in ruby. Or a whole IDE via ruby + libui-ng on windows! :)

This then made me wondered ... what if glimmer would offer that, or perhaps it already offers it?

So it brought me towards ... "what if we could have ready-made glimmer components", like this small enhanced notepad. Or ideally different notepad styles to allow people to customize it.

Now I know you are using the glimmer-swt editor (I think) or at the least there is one. But I believe that one requires java. I am more wondering minimalistic, if possible, like, just ruby (and libui, but the kojix2 libui bindings should be enough via gem installation).

Something a bit of a "glimmer ecosystem" that can be adjusted to different users and needs. Perhaps based on some config format or so or a yaml file and/or commandline flags. Just a made-up example:

glimmer --start-simple-editor
glimmer --start-slightly-enhanced-editor # not a good word but I think you get the idea

And so on.

So, for instance, I could have that widget on windows, and interconnect it somehow with features or functionality. Like save-file functionality - that one is probably available in every editor. And a few more things.

Something people could re-use via glimmer and it would work on as many platforms and use cases (including in use via a browser, if possible), if you kind of understand what I mean. It ties a bit into the app-store for glimmer (the glimmerstore!) a bit, so I am not saying you should maintain and create all of that, mind you. Plus, you already provide many examples here (tetris and so forth). I am more thinking of functionality and components people could "browse through" like in a catalog and cherry-pick when possible; and in the cases where they integrate it into their own code base, they could use ruby code, e. g. like:

widget1 = "glimmer, return here a simple clock"
widget2 = "glimmer, return here an editor of medium complexity with feature set a, b, c, d"
window.add(widget1, widget2)

Or something like that if you understand what I mean. It is probably already possible, to some extent, or perhaps it is not, in which case it may perhaps be useful to offer something like that.

The reason I used the word "standardized" is more like pointing to one place where this could all be collected. So, for instance, it could also be all made available in a glimmerstore, or it could just be in some kind of meta-DSL that describes things. The above is just an example, can be another functionality or API of course. Kind of like LEGO building bricks.

(And, perhaps one day if glimmer becomes meta-mega-cross-language, like say in +10 years, then we could refer to a "standardized" set of widgets that are flexible and customizable.)

Anyway. This is just a rough idea. I hope it is not too confusing - it's a lot easier to have a mental picture rather than try to describe it for others to understand the idea as well. :)

AndyObtiva commented 1 year ago

Before reading the full writeup (I just read a few sentences), I’d like to note that you could already build such a thing yourself, using Glimmer DSL for LibUI, so I’m not sure what you’re really asking here.

Did you try to build it with Glimmer DSL for LibUI? You’d just have to build a custom control (read about custom controls on the project page: https://github.com/AndyObtiva/glimmer-dsl-libui#custom-keywords), and then expose it via a Ruby gem. That’s all there is to it. It’s already been done in that video custom widget you saw recently for Glimmer DSL for SWT (glimmer-cw-video). If you need help with building this notepad using Glimmer DSL for LibUI, feel free to ask me specific questions (not general questions) regarding where you need help.

Otherwise, please don’t go back to topics that I’ve answered already in previous issues. I’d hate to repeat myself. I’m not sure why you like to repeat yourself. If you like the ideas you like to repeat so much, you could just build them. That’s how open source software works.

AndyObtiva commented 1 year ago

By the way, I forgot to mention that the same notepad is already implemented in Glimmer DSL for LibUI.

https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/docs/examples/GLIMMER-DSL-LIBUI-BASIC-EXAMPLES.md#simple-notepad

Code:

https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/examples/simple_notepad.rb

That’s in addition to a GPT notepad.

https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/docs/examples/GLIMMER-DSL-LIBUI-ADVANCED-EXAMPLES.md#gpt2-notepad

code: https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/examples/gpt2_notepad.rb

You could enhance either sample easily with what you need, extract into a custom control (read more about custom controls on the project page to do so), and finally gemify if you’d like to make reusable for everyone. There is no need for any bureaucracy around “standardized” stuff. Just make it available, and that solves the problem like I did with the Glimmer DSL for SWT video custom widget.

AndyObtiva commented 1 year ago

My answer doesn't change after reading the full write-up.

Glimmer DSL for LibUI already supports building components as Custom Keywords (aka Custom Controls): https://github.com/AndyObtiva/glimmer-dsl-libui#custom-keywords

Here is an example of how to build one:

https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/docs/examples/GLIMMER-DSL-LIBUI-ADVANCED-EXAMPLES.md#class-based-custom-controls

Code:

https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/examples/class_based_custom_controls.rb

class AddressView
  include Glimmer::LibUI::CustomControl

  options :address

  body {
    vertical_box {
      address.each_pair do |attribute, value|
        label_pair(model: address, attribute: attribute, value: value)
      end
    }
  }
end

That generates the address_view component, which can now be inserted anywhere. It can be wrapped as a gem if needed and then a Ruby software engineer could reuse anywhere.

There is no need to make a big deal out of this. Just build a component and make it a gem. There is no need to come up with standardized stuff. Standardization only happens usually after there are 1000s of custom controls. Come up with 100 controls for Glimmer DSL for LibUI at least, and then maybe I could consider standardization.

This issue is already handled given that Glimmer DSL for LibUI includes a notepad example, and includes a way to convert it to a custom component.

Also, as for making my own code editor in Glimmer DSL for LibUI that's an evolution of the notepad, I do plan on it, but haven't gotten around to it yet. When it happens, you'll hear of it in the project page or on my blog: https://andymaleh.blogspot.com/

I am closing this issue.

p.s. In the future, please contribute by building stuff using Glimmer DSL for LibUI. It would be better if you ask questions after you wrote some code with it. Otherwise, your questions are not grounded in reality and thus waste my time and yours as a result because you didn't put in the effort to find things out for yourself. Please put in some effort first, and only ask a question if you run into a road block afterwards.