The absolute need for GUI system/plugin

Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

How would you access event parameters like the button or key that was clicked/pressed? I wouldn't want to have to try to cover every kind of possible event and event parameter that exists in JS, that's a lot of work just reimplementing what JavaScript already does.

> Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

How would you access event parameters like the button or key that was clicked/pressed? I wouldn't want to have to try to cover every kind of possible event and event parameter that exists in JS, that's a lot of work just reimplementing what JavaScript already does.

Isn't that the whole point of the event system though? To reimplement what you can do in conventional coding?

I think this idea in general is fairly close to something workable, but I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

Isn't that the whole point of the event system though? To reimplement what you can do in conventional coding?

This. Exactly. Ashley, every reason you've presented so far for NOT doing something is because it can be done in JS or HTML. Wasn't the original purpose of Construct to insulate the end user from the vast majority of that? If I'm going to have to write half my project in JS anyway, what's the purpose of buying Construct? Why not just download Unity, which is free for development and a lot more powerful and it works with both JS and C#. I've seen so many answers lately that say, 'oh, just do that in JS now.' Well, the whole purpose of me buying C2 AND C3 was so that I didn't HAVE to screw with JS (much).

I don't have any big gripes about copy, and pasting code, if they want to make a library type thing available as a solution, but I don't think that is feasible with how Construct is set up as Ashley already pointed out.

It seems to be the same issue as copy and pasting events.

Hey! I just made a suggestion in the C3 idea website for the 'grid object' that I proposed above.

https://construct3.ideas.aha.io/ideas/C3-I-1043

I don't know if is too vague. So if someone here have any new details or ideas to share, let me know, so I may edit the suggestion text with more info.

Please vote!

I think there will be tradeoffs. The more something is abstracted out and made more high level, the more you lose the ability to customize it at a granular level.

I remember products like Dreamweaver back in the day that was a wysiwyg web page creator. They had drag and drop html elements.

Even with something like that there is still this tradeoff that happens. And to fully customize what you were making you had to dig deeper. If you use the high level tools you lose some control. And i feel like that leads to cookie cutter solutions.

If you think moving to unity because you have to write a bit code in construct is going to speed up your development time you gonna be in for a surprise...

Hey! I just made a suggestion in the C3 idea website for the 'grid object' that I proposed above.

https://construct3.ideas.aha.io/ideas/C3-I-1043

I don't know if is too vague. So if someone here have any new details or ideas to share, let me know, so I may edit the suggestion text with more info.

Please vote!

That's similar to an element I'd like to see, which is a basic UI element in most other IDE's, call a panel. I mentioned this in another post a couple of months ago in yet another thread about the GUI.

https://www.construct.net/en/forum/construct-3/general-discussion-7/life-saving-suggestion-144108?kws=panel#forumPost975906

If you think moving to unity because you have to write a bit code in construct is going to speed up your development time you gonna be in for a surprise...

I spent years working with Unity and yea, it's a huge pain in the ass. Especially when the latest version comes out and breaks half the crap you created in the previous version. The reason I chose Construct for my latest project over Unity (and this was weeks of internal debate) is because of the plethora of code and finite details I'd have to wade through in Unity to accomplish the same task. That and the fact that the Scirra team actually communicates with it's customers, something Unity has yet to embrace without charging for it.

However, if I'm going to have to wade through code anyway finding workarounds to a limited set of UI elements...

Fengist - I think you missed the bit where I wrote this:

...I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

My experience with RPG maker is that everyone spends all their time writing their own GUI because they don't like the GUI the engine comes with. Most of the addins (like Yanfly) start by undoing the GUI. If you look at what is requested on their boards it is about the same here--they want a user interface--just not the one they get with the game engine.

Fengist - I think you missed the bit where I wrote this:

> ...I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

No... I was writing the reply, got distracted with a customer, came back, finished and posted it and then saw your reply. I decided to leave it so you'd know at least what's in my head.

It's good to know though that you haven't strayed from your original concept.

My experience with RPG maker is that everyone spends all their time writing their own GUI because they don't like the GUI the engine comes with. Most of the addins (like Yanfly) start by undoing the GUI. If you look at what is requested on their boards it is about the same here--they want a user interface--just not the one they get with the game engine.

UI's should be unique across games and apps. The UI is the first thing the user sees and therefore makes the first impression. No plugin or hard-coded UI element is going to satisfy everyone. However, there are basic elements to any UI that are severely lacking in Construct. These elements, like panels and scroll boxes form the basis of UI's. As it stands, we only have the simplest of controls, buttons, text boxes, etc., controls that are related mostly to user input. Nothing exists to help manage the placement of these controls and, in my case, I have to run through every single control each time a layout is shown or the browser gets resized and manually move and resize them to what I want.