I truly appreciate you taking a deep dive into this and pointing out some issues that I haven't considered! Just want to come out and say that I do not claim to be an efficiency expert, but I have grown to appreciate more and more organization of code to save development time, with the least amount of overhead as possible. I'm surprised you haven't created an interface framework yourself! ;)

I agree with your points, but made decisions against others. I'll go through them:

-Is it extendable?

Basically, you can use your own object to choose to do the drawing or not and use the core functionality of the control (grouping, selection, input, etc) to design your own display if you'd like. The goal is to have the least amount of need for that as possible through customization, but I figured there would be cases where you would still need to.

As for the actions, I completely agree with your analysis here. Thanks for pointing it out! Personally, I am completely against running plaintext gml for the reason that you have mentioned, having to deal with the security for it, but I understand your perspective on letting someone do that if they choose to.

I was actually unaware of the script_exists check as I never had to use it. I will look into this and see if I can change that part around (it looks like it should work). The reason I initially used switch statements was because the lack of extendable code that I am familiar with in most OOP languages. That change will go into the next release.

The internal scripts are there as organized shortcuts to adjust related settings of the control. You could just change certain values of the actual control, but then I am asking for sanitation and knowing the system more like you mention. My plan on this is to add comments for all of the options on the top of the script with another reference to the readme that show what all of the parameters are (in the group position for instance, it is layer, group, x, y, adjusted x, adjusted y (for slightly adjusted regions that still work with the grid system).

- How am I going to use the system?

It is true that I am going to be using this for a few of my own projects. Hopefully this will make it easier to design apps that help designing in GM. I considered using a different language entirely, but some things like the particle system is easier to design in GM and the cross platform ability is nice for prototyping apps, so why not

In regards to the intpicker, yeah that one could use some better organization. I am planning on having different orientations to choose from as well as you may have noticed. The point is to make general controls that cover most use cases. Extensibility is nice, but also takes work to accomplish as well which is why it takes so long to develop (and is why I believe open-source helps to collaborate on areas that need improvement).

I wanted to avoid the downfall of using GM for organized code: It doesn't have good implementation support of object-oriented approaches with inheritance (unless you use the built-in objects inheritance which introduces new required objects - more of a problem with GM8), and I don't want to use literal naming of objects that rely on string representation of the resources.

But with the case you bring up, it seems as though I have no choice but to create many more scripts to handle the separated concerns (the correct approach, yes), which is fine and is probably the direction of the project.

Nesting of groups sounds like a "Like to Have" feature. Not saying its impossible, just seems like something I'm not sure most people making games would need. But I can see a use for it. I'll consider it.

Event driven approach is a good idea, but it took me a while to figure out how I could get it to work with GM. I think the part where I built a grid of control boundaries is a good approach, but I get how I can make an "event" that triggers when leaving the control. Now that I know about the custom script calls, I can check to see when I can work that in. Good idea, I like it.

I also like how you mentioned the dependencies. I'll make a note to do that so I don't forget.

Now that last point you've made I have given some thought before choosing the direction I did. Reading up the documentation on surfaces and how they work with GM:Studio, I got the impression that it would take a bit of effort to be able to manage surfaces, especially as it is cross-platform. I do plan on using surfaces in my future projects, but I chose to not use them with the framework because there could be potential issues and I want to have a solid framework that is dependable.

However, maybe I could work in a way to make it optional to use surfaces or not. I'll have to think about that.

Seriously, thanks for your analysis and let me know if there is anything I took incorrectly from it. It helps a lot and I'm glad someone took a critical look at it :)

I wanted to post a long comment that would, possibly, crash Jani's Chrome again. So I found a random short story generator and threw some random words into it. It came out very… strange.

—

Jani Nykanen looked at the stanky 64digits in his hands and felt salty.

He walked over to the window and reflected on his confusing surroundings. He had always loved irrelevant 64Digits with its confused, crazy comment section. It was a place that encouraged his tendency to feel salty.

Then he saw something in the distance, or rather someone. It was the figure of Steven O'Brien. Steven was a weird songwriter with hello arms and what does this do eyes.

Jani gulped. He glanced at his own reflection. He was a weird, weird, goat milk drinker with i dunno arms and what eyes. His friends saw him as a joyous, jittery Jani-like. Once, he had even rescued an unusual Jani's Chrome from a burning building.

But not even a weird person who had once rescued an unusual Jani's Chrome from a burning building, was prepared for what Steven had in store today.

The sun shone like thrusting cats, making Jani nope.

As Jani stepped outside and Steven came closer, he could see the broad glint in his eye.

"I am here because I want hug," Steven bellowed, in a weird tone. He slammed his fist against Jani's chest, with the force of 9867 cats. "I frigging hate you, Jani Nykanen."

Jani looked back, even more nope and still smelling the stanky 64digits. "Steven, dank memes," he replied.

They looked at each other with enchilada feelings, like two mutated, mute more cats commenting at a very weird commenting, which had accordion music playing in the background and two weird uncles browsing to the beat.

Jani studied Steven's hello arms and what does this do eyes. Eventually, he took a deep breath. "I'm sorry, but I can't give you hug," he explained, in pitying tones.

Steven looked happy, his body raw like a joyous, jolly Jani's tablet.

Jani could actually hear Steven's body shatter into 94 pieces. Then the weird songwriter hurried away into the distance.

Not even a drink of goat milk would calm Jani's nerves tonight.

THE END

Thanks SN for your answers haha.

- code_execute

If the game is decompiled you could simply put your own code in there and execute it, but that isn't too bad as long as its not distributed. The main issue though is that if the code is dependent on any other resources, it could break because you are "hard-coding" the reference. For some reason I choose to always avoid that situation in different languages unless the compiler resolves the name properly (even if it is a small hit in performance).

-script_exists

I'll have to look into those commands. I haven't used GM:Studio that much to be honest, but I like how it has a lot of cross-platform support. Hopefully there is a command I can use in GM8 as well.

Why am I using GM8? Mostly because of particle designer. My main influence for developing this is because of Particle Designer, because GM8 has integrated filesystem abilities and a full particle system support. I also have built prototypes of self-installing updates, particle systems using surfaces, cloud login and saving support (and eventually a community hopefully for inde games that use multiplayer/highscores/self-installing updates/login/chat systems. Also ported to Unity.) - That is the long game. My plan is to do these things right and reliably so that I can charge money to keep up a system for people that works and is fun :)

I also can see the benefits of using GM:Studio for prototyping games, apps, etc. One idea I have is adding smooth animations and transitions so that you can apply it to multiple platform exports. Another is to provide some general controls that you can optionally use so that everyone doesn't Have to re-invent the wheel every time if they don't want to, with some basic customization options.

Also, I'd like to at one point build a Menu designer and a level editor with features that I wish I had when trying to make games. All of this would tie into a centralized account system for the games, only these tools are software so its more tied in for sharing creations and paying for the software. Everything I want to build would tie in to skills that I'd like to learn and use as proof of my ability to make decent software (i hope).

But yeah I really like your input on event-driven approach. It makes it very flexible, and the more flexible it is, the more people will want to use it. And the more people that use it, the better it gets.

Personally, I also want to use it to prototype apps, as I have some app ideas that I'd like to make PoC's of. And others that I'd like to prototype so that my team members can critique it and build it in a similar way.

As for surfaces you may be right. I think surfaces would probably more efficient and even easier to use in some circumstances, but I also think that it is probably more prone to problems than not using them, so if anything I would make it an optional feature. I do like that idea, but its not top priority for now.

And I think that GM lacks some good GUI functionality as well. Someone asked me if they could use it for their level editor, and I'm planning to design it in a way that will accommodate for that. I know how it feels when you end up having to design your whole UI for your game and spend hours on hours doing it. It sucks!

Hopefully this framework helps make it easier for everyone, and the feedback will make it better as I use it in my own projects as well.