AndyObtiva
commented
1 day ago This might be your most uninformed request yet that shows you didn't do your homework in Glimmer. People who don't do their homework never get anywhere with or without Glimmer anyways. I told you before, I won't answer any further requests by you unless you build actual apps with Glimmer as proof that you are not just trolling and you need real help.
Glimmer libraries have supported Components for years now. They're called Custom Controls, Custom Widgets, Custom Windows, Custom Shapes, etc... Look them up in each project. Also, there are component projects like https://github.com/AndyObtiva/glimmer-libui-cc-graphs_and_charts & https://github.com/AndyObtiva/glimmer-cp-cube
The Glimmer DSL approach is way simpler and more productive than non-DSL approaches. People using DSLs can do 12 months worth of work (without DSLs) in 6 months or less (with DSLs). But, only intelligent Software Engineers get that. Non-intelligent and incompetent devs who don't get it are NOT the target audience of the Glimmer project anyways. They're the devs that usually lose their jobs due to incompetence and non-intelligence. I don't care to win them over with Glimmer.
I told you many times that it's the way of mediocre software engineers to go on about vague plans without addressing concrete projects while trying to solve the world in an overly idealistic way (I know many Software Projects that died due to doing things your way; it's not the way of any good Software Projects), and that competent Software Engineers address real problems in very incremental ways as small mini problems with divide and conquer. All the companies I worked for wouldn't hire people like you as they consider them incompetent developers due to not following Incremental Iterative Development in the way they solve problems. They don't hire them to avoid them influencing other developers because mixing bad developers with other devs produces bad habits and makes better developers worse. One bad apple spoils the bunch as they say.
I won't address or answer any of your requests in the future if they are NOT about a small concrete problem you are facing in a real application that you provide code for.
If you got no code (of a Glimmer app you're building) to share, you will get no answer!
If you keep posting such issue requests, I will consider banning you from seeing my projects in the future due to what comes across as trolling and non-compliance with high Software Engineering standards, like incremental iterative development that demands real problems to solve, not tackling grand visions all at once like mediocre developers do. Glimmer projects are all open-source community projects, so eventually, their users must give back by building projects/demos with them and building some of the features they want as value adding libraries. Otherwise, people who claim to be users but never build anything concrete are no different from trolls, and Glimmer's resources won't be wasted on them. Stop wasting my valuable time if you won't provide code of real apps you've attempted to build with Glimmer. Nobody appointed you the position of "grand advisor" of Glimmer, so cut the BS with all your "grand vision" requests if you don't have real projects you're building with code to show for. No code, no answer!
Hello Andy,
This fairly long issue request is about "glimmer components". Let me define what I mean with this term.
Glimmer components, at the least in the context of this issue request, refer to components (in the Glimmer module "namespace", that is the toplevel "Glimmer" module) that can return or yield a widget (or several widgets) to the "downstream user". With "downstream user" I mean primarily developers who would like to make use of glimmer, but may not necessarily want to use the glimmer DSL for this.
Let me explain the above description with a more specific example, so that it can be understood what I here refer to.
Take the tetris game variants that you make available within glimmer.
The repository, it seems, is here:
https://github.com/AndyObtiva/glimmer_tetris
I believe you also make specific examples for glimmer-tetris available via libui-ng, SWT, and perhaps the glimmer-web variant, although I am not entirely certain the web-variant has it; still, I think you make tetris also available for the world wide web.
Either way, the bottom line here is that the tetris-game variant works on several glimmer-subprojects right now, yes? For instance, for the libui-glimmer variant you also add more detailed instructions here:
https://github.com/AndyObtiva/glimmer-dsl-libui/blob/master/docs/examples/GLIMMER-DSL-LIBUI-ADVANCED-EXAMPLES.md#tetris
And the screenshots show that it works on Windows, Linux and Mac. (Would be awesome if we could get it to work on HaikuOS one day, but I feel that this may take longer, due to various reasons. Anyway, that's an aside.)
I used the word "yield" or "return" above, so what do I mean with this?
Basically, I refer here to an API that the downstream developer can use; and, after using this API, the specific widget would be returned, for use in other programs. This is in part why I call this "components", e. g. if we focus on re-usable widgets.
Now, a few words about the API that I am thinking about here - this is more of a suggestion, as an example. Of course the name can be different; I use the following names mostly for illustration purposes.
So let's assume we are writing a project, in libui-ng and the ruby bindings to libui-ng. Let's say we work on an editor, as this is an often recurring theme - such as the gladiator editor. :)
Ok ... say that I have this editor ready, with some changes, to make it less gladiator and more ... another editor. Again, this is just for illustration purposes.
Let's say this editor also has tabs, on top. On the last tab, called "games", I want to put in various small games, with tetris being one of those games. Say that I sometimes play games in the editor, while waiting for a C++ project to compile; that's a semi-contrived use case, but hey, if the downstream developer wants to embed games into the editor, why not? For instance, the geany editor has a terminal (vte, for gtk) which can be used for commands and instructions. And then even ncurses games, even though these tend to be crap.
Alright - so the use case here is "embed tetris game for glimmer-libui-ng".
Of course I, or any other downstream developer, could write my own (or his or her own) variant of tetris, but this contributes to fragmentation, and since you already wrote a variant of tetris that works, I think it is better to help improve on that part, so why not re-use the code?
Thus, my suggestion here for this issue request is mostly about re-using existing code components, as much as possible.
For this see also my older suggestion about a "glimmer store", where ideally we (all) could register projects, and then people can re-use these "apps" in the store - be it freely made available or donation based or whatever. The key idea is that distributing code should ideally work and be as simple as possible.
Ok. I hope so far it is understandable what I am trying to explain, so let me do a very short summary:
So, what options do we have available to embed, e. g. tetris?
If I recall correctly, some time ago you wrote a little bit about this, and had some examples. I don't recall where these are now (may be useful to also link to them via the FAQ), but even aside from this, I would like to propose a specific, dedicated, and easy-to-use API for that functionality.
Here I'll give a few examples - first one is just for the generic syntax-idea:
Or an API that would be similar to this.
It could also additionally (or only) make use of keywords; I have no preference for that.
I believe the two arguments should be:
1) The name of the component, as a Symbol. If that name does not exist then Glimmer will raise an error. If there are similarly named components, we could simply sort them (e. g. 1, 2, 3), or allow for a non-Symbol way to obtain them, such as additionally the path to the component, via a String such as 'foo/bar/app.rb' - or something like that. But right now I think there are not enough "components", to worry about this.
2) The second argument, in the case above :libui, would return the libui-widget where tetris would reside at.
Perhaps multiple APIs that are related could be used. Additionally we could also omit the second variant, if we use a specific glimmer component already.
For instance, if we have required libui-glimmer then we could simplify this to:
This would then work because glimmer-libui is already required. Though, even then, it may be useful to allow the downstream developer to override that functionality.
Anyway - this is basically the gist of this issue request.
What should such a toplevel method return?
In the examples shown above, e. g. Glimmer.component(:tetris, :libui), the expected outcome would be that this would yield a widget, that belongs to libui (on Linux then it is probably gtk, whereas on windows it may be the variant that works on Windows, whatever the name is), and can be simply re-used in other "downstream" projects.
One important thing to note is that this should ALSO work in non-glimmer projects.
In other words, this should work also for projects that do not make use of glimmer's DSL.
Of course these downstream developers COULD use the glimmer DSL, but my thought process here is that the more flexible we are in this regard, the better - plus, of course my own motivation in that I want to be able to embed glimmer-components in projects, without necessarily being tied to the glimmer DSL (or, any other DSL for that matter, actually; I have nothing against the DSL, but if I write in an OOP-centric style, with classic method-calls on ruby objects, then a DSL does not always fit 1:1).
Being flexible here would allow people to decide, on their own, what they want to use (and thus cherry-pick), without necessarily having to stay within the glimmer ecosystem in itself as far as the DSL is concerned; so, a distinction I make here is that, e. g. using something like a "glimmer store" is fine (even though it technically does not yet exist), using glimmer as a widget-collection set,via "components", should (hopefully) also be fine - but allowing users to not have to use the glimmer DSL necessarily, if they do not want to or can not use it, at the same time. This is what I mean with "flexibility" for downstream developers/users.
A slight problem I see with regard to DSLs in general is that they often require a cognitive load. For instance, using rails is only really, or mostly, possible if one is to adhere to the rails convention. And people must understands not only MVC, but kind of how the active-ecosystem works, its various idioms and so forth. This may all be fine, and simplify e. g. dealing with databases/SQL, but it still requires a cognitive load - a level of understanding. And also, to some extent, having to adhere to this convention. Thus, the design of e. g. rails forces one into having to write code that "makes logic sense" within these idioms. This can have advantages, but it may also have disadvantages. Sometimes people may want more freedom in how they design and write code, for instance; an old example are .cgi files. There can be considered less powerful and elegant as rails, but they are also super-simple.
So, in a nutshell, the usecase here for "glimmer components" would be to re-use all the widgets that are part of glimmer, without necessarily having to use glimmer's DSL.
Anyway - I'll stop it here, as it is already quite long. But perhaps I was able to make a few points you may concur with. The basic idea is to be able to integrate glimmer-widgets. There could be other ways, of course, so my suggestion here is just one possible way of many more that may be possible.
Thanks for reading this suggestion!