[Idea] Consider adding a "generic, componentized editor" to the whole glimmer suite (in addition to gladiator, or, perhaps extending gladiator's use cases to also include simple editor variants) [update: focus on Glimmer DSL for LibUI only]

[rubyFeedback]

So this suggestion is a tiny bit more "serious", but, as always the disclaimer is to please feel free to ignore/close/modify in any way shape or form.

Before I describe it in more details, let me also preface that evidently your time is limited and you have been doing tons of stuff lately in regards to glimmer - your comparison to shoes (I think we can call why's original shoes more like as a basic first step towards DSL-syntax), glimmer + video stuff (widget) and glimmer + wxruby3. On gladiator you also point out that your goal is NOT to write a mega-super-feature-rich editor with a billion features.

This suggestion here is a bit more on a per-app specific suggestion, a bit like kojix2 libui-radio widget focusing on playing audio files, but I will focus on ... an editor.

I'll explain that in a moment, but I would also like to point out that you have that editor widget via SWT called "gladiator":

https://github.com/AndyObtiva/glimmer-cs-gladiator

You also provide a screenshot on windows, so I assume that it works very well on windows - this already covers one "use case necessity" I have with my suggestion here, which I will explain in a moment:

https://github.com/AndyObtiva/glimmer-cs-gladiator/raw/master/images/glimmer-gladiator-windows.png

I do not know how easy it is to customize your editor. The more customizable the better, I think.

I believe that one small issue may be that users may need java and swt on windows too, right? It is probably not a big deal, but I mention it just in case, since this can provide a small obstacle to some folks (even though you tend to provide excellent documentation, which I think is always good, even if it may sometimes appear "too much" - personally I ALWAYS prefer projects that rather have too much documentation than projects that lack documentation. In my experience the latter tend to be abandoned more easily too, but I digress, so back onto the topic.)

For instance, in the past I did not even know how to install java - it took me a while how to figure that out, and lateron I was using just Graalvm's java variant, which works fine on windows too.

I was not doing much libui-related stuff in the last 6 or 8 weeks or so, but lately my interest has increased again, in part due to the video-widget thing you showed.

I still want some kind of mega-IDE or platform via libui-ng+ruby on windows - like all apps would have something that can relate to libui too! And we could use these on windows without necessarily needing windows. (Or on all platforms, actually - the glimmer desktop!) :D

Anyway.

Yesterday I looked at kojix2' libui bindings again, and in the examples I noticed the simple editor:

https://github.com/kojix2/LibUI/blob/main/examples/simple_notepad.rb

Well, it does not really have any features, but actually I think this is also not bad, IF we can think of this as a "componentized editor".

With that I kind of mean to allow the user to declare/define how feature-rich an editor is.

Now let's for a moment assume it were possible to have an editor like gladiator via libui-ng one day, just for the sake of the idea here.

People could kind of declare how feature-rich that editor would be.

In pseudo-syntax from glimmer commandline, say this:

glimmer --simple-editor
glimmer --medium-editor
glimmer --gladiator # as means to just start the gladiator editor,
                    # through bin/glimmer or whatever the name of
                    # the executable would be; as an example how to
                    # start any glimmer-app actually, so if we'd
                    # have a "glimmestore" like an "appstore",
                    # we could still use the glimmer executable
                    # to start any of these, and integrate the
                    # installed stuff into the --help display for
                    # bin/glimmer as well as include that 
                    # functionality, like "glimmer --tetris" and
                    # so forth. I hope you understand my idea,
                    # where we can start any glimmer-app from the
                     # commandline too, 
                    # but this is the smaller idea, so let's
                    # continue with the main editor

The basic idea here is to be able to offer a "componentized editor" as much as possible via glimmer, in as many different GUIs as possible, including the www stack. Again, this is just an idea - please don't assume it is my attempt to say "I'm gonna use Andy's spare time because I myself am too lazy to do it". :)

So, what could be a slightly more feature-rich editor?

Three small examples:

• Offer a save-buffer functionality (per tab)
• Offer tabs on the editor to allow user to modify multiple files
• Offer a second widget keeping track of the line numbers

And so on and so forth, increasing the feature set, until it eventually reaches the complex feature set that gladiator allows.

So the idea here is that the user could ideally have as many or as few components possible, while still having an editor. Like a really adjustable editor.

The primary focus here I'd see is on windows. On Linux I tend to use an ancient editor, but on windows I sometimes just need notepad, and notepad is mega-simple really. I think libui-ng could be used as a notepad replacement too, but even as a more extended editor. (Obviously you already cover that use case via gladiator on windows, but I am thinking more in terms of libui-ng or any other feature set here, including the www stack, perhaps via opal too. Having it work on the browser would be kind of cool too, like we could have an editor that we could use in the browser. In practice this may be a bit difficult since browsers tend to be in a sandbox environment, but, if it were possible to save files via a browser easily that would be great. Perhaps node/npm allows for that already; I know too little about that to be able to tell. I am more thinking about this in terms of "as many platforms and areas as possible")

So why do I think that an editor would be important and useful? Why should it go and become part of a "glimmer apps spec"?

You already offer several applications, including games - like snake game, tetris game and so forth. So you kind of have an "appstore" already, if we look at these as apps - the "glimmerstore". :D (I can already envision a logo for that ... anything that sparkles with glimmer and like a candybox hehehe... or like a loot box or a treasure box or something. Anyway.)

I believe that an editor could be useful to have for the glimmer suite in the long run. And, starting with a SIMPLE one, like a "clone" of notepad.exe to keep it simple too. But, if a user wants more features, to also offer that.

Now writing a complicated, feature-rich editor can be a lot of work - we see that via vim and emacs. I am not proposing that this goes over-board really, so my idea is also to CONFINE it to specific "components" that are used in many different editors.

Technically this can all use the same code base - well, glimmer kind of does that, yes? We can shuffle and exchange code and it may work for many things, like, again a contrived example:

glimmer --gtk --editor
glimmer --wxruby --editor
glimmer --tk --editor
glimmer --libui --editor
glimmer --libui-ng --editor

Or, say, with an existing code base like tetris:

glimmer --gtk --tetris
glimmer --wxruby --tetris
glimmer --tk --tetris
glimmer --libui --tetris
glimmer --libui-ng --tetris

I hope you can kind of see a bit what I mean here.

Having an editor available then means that people could write code in ruby, even on windows (again, it's already possible via gladiator I assume, but I am thinking like of a SIMPLE editor with a FEW features, say, 5 ones at max to keep it simple, and then have THAT editor work on as many different ways as possible).

If we abstract away things then we could also say that glimmer could be a general specification irrespective of the language. So right now glimmer focuses on ruby and java I assume, but in theory we could say all languages could use it and adjust to the DSL (and the DSL then eventually being a specification; I see that you are improving it as you go anyway, e. g. your recent entry in the todo file handling events via "on_event_NAME" or something like that). And then eventually call it, one day, the glimmer DSL or glimmer specification (and perhaps version it, to allow users to refer to it for stable applications).

Anyway. I'll finish that idea here. I hope it makes some sense. I kind of envision a mega-meta-glimmer one day, like where different people may use different languages but even just describe what they want, without necessarily needing to be ABLE to write code, and still have useful features. Of course we could say that EVERY application may be useful, and I do not disagree, but I think an editor may be a little more important from a usability point of view than a game (even though, of course, we can argue that more people may enjoy playing a game than using an editor, so I don't disagree with that; I just consider an editor to be rather important because I tend to write a lot of code, and I assume you in general also tend to write a lot considering the wealth of documentation and code. So I assume an editor is also important for your own use case.)

[rubyFeedback]

Of course we can also extend this idea onto gladiator, but I do not know how customizable it is, and gladiator is a bit different to e. g. what we can do via libui-ng. I assume you simply have more options available thanks to SWT. But, being able to have a simpler variant for gladiator and a more customizable variant of gladiator would be nice too - I am more focused on an editor for the WHOLE glimmer suite, whereas I believe gladiator requires java/swt even if I may be mistaken. It just feels a tiny bit different to my idea here, which is why I filed that here rather than on the gladiator issue tracker.

[AndyObtiva]

I moved this issue to the Gladiator (Glimmer Editor) project.

This issue’s scope is too large. It’s discouraged in software engineering to work on too large a thing at a time. It’s better to break this down or limit its scope, and then open another issue later. Let’s address it at the scope of Glimmer DSL for LibUI first. You can write requirements at a high level and store somewhere in a word doc or some GitHub repo, but please don’t create issues that are too large. They kill motivation with their overwhelming size. As per software engineering incremental development recommendations, it’s better to keep issue reports short and sweet, then open other ones as needed in the future.

Otherwise, you’re an expert software engineer, and Glimmer offers the simplest way to write apps, so I’m not sure why you ask me for something like this instead of respectfully putting in your own effort to show you care to support me, and then only asking me questions if you did your best and failed. You even said ‘please don't assume it is my attempt to say "I'm gonna use Andy's spare time because I myself am too lazy to do it"‘, but your actions speak otherwise. Actions speak louder than words! If you had created a GitHub project for a Glimmer LibUI editor and then asked me a question after putting in a best effort, your words would have matched your actions.

Anyways, you’re fortunate regarding this issue though because it’s already on my radar for Gladiator and Glimmer DSL for LibUI. I’ve been planning to finish support for custom shapes first to use that in building a code editor on top of the area control. That would extend the work I already did on code_area : https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/docs/examples/GLIMMER-DSL-LIBUI-BASIC-EXAMPLES.md#basic-code-area

[zw963]

BTW, there are another editor being development/maintained actively which use Crystal.

https://github.com/hugopl/tijolo

It can be built into a static binary, and much better performance.

[AndyObtiva]

Thanks for sharing. The Crystal version has awful XML UI code though. The point of this editor was just doing an experiment to demonstrate a Ruby DSL for building GUI that is a lot more readable than XML.

That said, I’ll keep the Crystal editor in mind.