I am at a point where i have to copy paste events from one scene to another, just to be able to see what i do.
A scrollbar on the bottom to navigate left & right would be VERY appreciated.
Thank you for your Time Gentlemen.
2 Likes
omg
This eventsheet look like a beautiful spaghetti code.
Anyway you must start to structuring your codebase.
Maybe you can use external events for solve your issue.
And instead write complex and looooong expressions you can write your own via the extension!
thanks bouh, but my events are actually structured pretty well. It has to be, or it would be impossible to work on it. Its just a complex game.
In fact, because of my effort to structure it neatly, to be more efficient and easier to find the right codes, i do have these issues now, because my subevent counts.
Its true, that i could have my main events more tidy if i use extensions.
But the problem would still occur when i need to change/update/bugfix the extensions, and then its even harder to oversee the code.
All i need is an event sheet that can scroll left and right 
1 Like
You are right, there must be a scrollbar at the bottom on events sheet if things get messy/overflow.
@Bouh are you going to open a issue on github regarding this ?
This issue can be solved with some css tweaks though.
1 Like
Think to open a issue before the pull request, let’s start to discuss this problem first. I’ve not open a issue because these events should be use function and external events.
If the scrollbars is accepted on GitHub make it invisible by default on a normal eventsheet.
No offence but I think devs should listen to the people what they need instead of trying to force a certain workflow on them just because they think it is more practical.
The only reason I chosen GDevelop over Construct, 8 years ago was the fact GDevelop did allow me to do anything I want even if it not practical while Construct 2 (at the very beginning) did force a certain workflow on me by limiting what conditions and actions and expressions I can use in what order and combination. When I complained the devs explained to me why it was more practical the way it was and now that’s why I’m here because I did not care why, I just did not like it especially since GD allowed me to do it the way I want.
When I made certain suggestions to 4ian how event based behaviours should be working, he explained to me why the behaviors are practical the way they are and why my workflow is not practical if I need those certain features. Now I am not using the event based behaviors because I don’t care why is it practical the way it is, I just don’t like it and I prefer to do things my own way. It is that simple.
So if all it takes to satisfy the needs of Slash is to add some CSS then why not? Telling him it is not practical what he is doing not going to solve his frustration and forcing the “practical” way on him may not going to help either and he end up going with something else that has a scroll bar at the bottom.
Just saying but whatever… 
3 Likes
I am not against the idea of a CSS correction.
I explain why I didn’t report this directly myself.
I agree that there is a need, and the visual rendering is not pleasant.
To report a bug directly I try to find out if it is critical.
And when there is a workaround I don’t report it the first times.
I got this habit because bridging the gap between the forum and Github is not possible, there is two places for suggestions and bug reports it’s clearly not practical to report everything.
1 Like
I understand your point of view but it is not really a bug is it? It is one of those “quality of life” improvements that I also often mention and constantly lose the argument against 4ian because it is always turns out to be not that important to schedule it for the next releases. 
Anyway what Slash is asking for doesn’t sounds that much of a big deal to me to be afraid of opening an issue on GitHub or at least mention it on Trello at least 
Is 4ian reading Trello at all now days or is he focusing only on critical bugs and contributions on GitHub?
I don’t know, to be honest the fact we have multiple place for report/suggest something bothers me.
I wouldn’t be surprised to know that others have chosen to view only through specific website.
Well my first screenshot shows what happens when a single line of code exceeds the screen.
It scrolls right with no option to turn back to the left, other then closing the scene and reopen it.
That part of the problem can be considered a bug.
It should jump back to the left after confirming the event line
considering the bug, its not critical, but annoying.
But to be able to read your event sheet when you try to make more advanced games, i consider this critical. TBH this could be a reason there are so little advanced games made with GD, it just gives the impression to be there to make mario clones only. Which is sad, because GD has so much more potential.
Anyone who ever worked on more advanced games in other engines must be shocked by the lack of readability on complex code structures.
Eh, well it could be argued you are using it wrong if we follow the book you should indeed break up that very long expression in to smaller chunks to be more simple to read. Instead of putting so many instructions in one line, you should run only one at the time one after the other to be more easy to read.
So one could argue that you are using it and doing it wrong. The editor is not designed to be used this way and so it is not a bug just a limitation of the editor 
But I agree either we consider this a bug or “quality of life improvement” yes it should give you the option to scroll left and right.
But then one could argue that such feature would motivate people to doing it wrong and using it wrong. I’ve been there, sometime it is a real pain depends who you have an argument with. 
I have posted this on Trello, not sure if 4ian going to see it but I think it would deserve at least a ticket among the ideas maybe.
The initial post shows 2 issues:
- Expressions that are overflowing because they are long and not wrapping to the next line. This is a bug.
- When there are too much subevents, we’re reaching a visual limit depending on the size of the screen because conditions column get very small.
Let’s at least fix the issue of the text overflowing outside of the border of the event, it’s definitely a bug (in the sense that something is visually broken and you can’t scroll back to the left). A bug report can be opened.
The second issue is more complex. It’s not just about “just add a scrollbar”. Should we:
- Mandate a minimum size for the condition column? In this case what about the actions?
- Add a horizontal scrollbar… But when to show it? When do we decide it’s time to allow scrolling to the right?
- We don’t add a horizontal scrollbar, but a horizontal scroll per event? Or per event group?
- Or at some point do we stop indenting more?
Finally, we can benchmark how other similar software handle this, maybe they found already a good solution.
We can now discuss this or open a GitHub report, but it should be framed around the problem rather than the solution (because we’ve seen there are more than one, and none is obvious)
if there would be a minimum size for conditions & a scrollbar, then the actions can be full length.
Assume point 1 is true. It show up, as soon as your events exceed the Screen. So if you do have those events, it should be always shown.
Some additional suggestions to make handling easier: When an event is selected, that goes over the screen width, jump the scroll so that the selected event is aligned to the left.
I think just 1 scrollbar on the bottom would do the job just fine. it can be hidden, if a selected Eventgroup does not exceed the screen, but it would be unnecessary.
Im not sure if i understand this point correctly.
If you ask to stop expanding the Eventsheet to the left via Subevents at some point, then no. It should always be expandable.
Conclusion. yes, i think a minimum width of conditions would be a way to go.
But in Theory they could be full length too, if we are able to scroll horizontally.
Just Think of it like normal code/text editors, that are limitless, both vertically and horizontally.
Construct (and most software I can think of) uses a good old scroll bar at the bottom:
It is shown when you hover the mouse over or start scrolling, swiping but in case having a nice, slim, elegant bar like the one in Construct I think it would be fine to show immediately if any element exceed the view. it would be also a nice indication somewhere your content do exceed the view and you can scroll.
Ideally both condition and action can be resized to always fit into the screen when selected.
I’ve at least fixed the overflowing. Long object name/variables will now properly break to the next line as it was supposed to do:
The horizontal scrollbar is more tricky. The list is virtualized to show and have in memory only the events shown on the screen (which is why your may have events “appearing” if you scroll very fast). A horizontal scrollbar would disappear when there is no event on the screen that needs a scroll - might be good or bad depending on how you consider it, but surely surprising.
I wonder if an alternative solution would be too put a minimum width on the condition column, so that at least when you have a lot of indentations, it keeps a minimum size:
It won’t solve entirely the problem, but gives a bit more space before hitting the problem.
4 Likes
I think we can set a width of 100% to condition+action box , so it can take the remaining space on the screen as it moves horizontally towards right.
For the condition and action columns we can distribute this width in ratios like (for 12 col) 4:8 or 5:7.
Now if the indentation goes out of the screen a horizontal scroll bar will show up.
In our personal project same problem occurred few weeks ago and we found the solution as I mentioned above. We used the material-ui in our project.
Link : “https://streamable.com/02ilba”
You can see the result in this video :
1 Like
For next version, I’ve enforced a minimum size for the conditions column. This means that even with a lot of sub events, the column will be never super small (this means that the separation between conditions and actions will progressively move toward the right too).
This should help alleviate the second problem reported.
I did quick tests with a scrollbar, but it has more issues making it a non trivial solution (scrollbar only appearing at some point when events outside of the area are shown, borders not propagating outside of the usual area).
I think the first fix will already go a long way and could make the problem almost invisible - while still keeping the promise of no horizontal scrollbars
Another solution could also be a way to right click an event and “focus this event”, meaning only this event and subevents would be shown (so we can entirely remove the indentation, and offer a “fresh start” while you’re working on an event, or a group of events).
2 Likes
that sounds good, but how to get back to full view?
what happens if i strl + x the “focused” event?
I am a little bit disappointed, that there wont be a scrollbar yet, but i do appreciate your time and effort ian and i am glad for any improvement.
I just have to wait and see for the next update, if i will be able to properly work on my project.
You can already test the next version via the nightly build: https://gdevelop-releases.s3.amazonaws.com/master/commit/8cd5593182f8d5aa3209494659cfcc0eb8b69ecd/GDevelop%205%20Setup%205.0.0-beta103.exe
Make sure to back up your project before using it
1 Like