Modernizing ScrollContainer with new Scroll Modes for mobile devices and add fading to ScrollBars to further enhance use

[Knight-XAura]

Describe the project you are working on

I'm working on a mobile project, but I noticed Godot doesn't really have any kind of common implementation of ScrollContainers you see on mobile devices. A project I'm working on in particular though is similar to Habitica where you have lists of tasks.

Describe the problem or limitation you are having in your project

I don't personally enjoy some of the limitations of the ScrollContainer that's meant to help make scrolling through data a breeze. Seeing what the rest of the world seems to be doing and how it can be very helpful drew me in on this. I want to be able to show the scrollbar, but not have it take up space in the container, but I also don't want it to be overlapping content consistently.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

This helps by not having to have you work around making your own scroll container or the content on the scrollbar side being pushed. If you disabled them in the ways you even can they would adjust the content and I personally find this annoying on small screens. This would fix that by allowing the scrollbars to overlay and then also fade to disappear when not in use.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

ScrollContainer Core Features: Two new scroll modes: Auto Touch and Auto Hover Auto Touch: Meant mostly for touch enabled devices. Needed scrollbars overlay content. Auto Hover: Meant mostly for mouse enabled devices. Needed scrollbars overlay content. Mouse entered and mouse exited signals trigger the scrollbar to appear and disappear

ScrollBar Core Features: Fade Boolean: For enabling/disabling fade Fade Threshold: Time until fade happens Fade Time: Time it takes to fade Timer Node: Handles fade threshold and assists with fade time.

ScrollBar features would be exposed to the ScrollContainer in the inspector

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't believe this can be worked around in a script with a few lines and with how common this feels in the real world, it feels like something that should be implemented as a core feature

Is there a reason why this should be core and not an add-on in the asset library?

Because this is often times used in the real world for mobile devices (like Habitica and probably your messages app (at least for iMessage)

[Knight-XAura]

I should also note I have setup a fair amount of eveything needed and and have the overlay working, but other then that the rest is a work in progress still, but I'm happy to implement this, I think the biggest thing is finding changes people want and some guidance, especially at times when not everything about implementation is clear. For example my testing in the editor tells me that implementing fade may not be as easy as it sounds.

[Knight-XAura]

I also feel it's worth mentioning, I don't like the idea of having a timer node on each scrollbar, I hate having one on each ScrollContainer, but I'd be happier with that. I've looked at some other code where other nodes are used to make up what is needed, but not in depth enough.

Is it within how we do things here or possible (I'm sure it is) to have the timer node only spawn if needed? For example the ScrollContainer (I'm sorry I've looked at this the most) has the scrollbars anyway whether being used or not. But in this case maybe there's a reason for that?

I'm still learning a lot as I go through this, but I'm really curious what the feedback is about how to go about doing certain things. But I am prepared to do this implementation, just may need a little help along the way :) Of course being community driven I want to do this in a way that works for most everyone and follows, things are preferred to be done, and I'm trying not to create any unique scenarios you don't see anywhere else in the engine.

[Calinou]

We probably don't need an internal Timer node and can do our own counting in NOTIFICATION_PROCESS internally.

[Knight-XAura]

Would that be similar or the same as the _process function and we use the delta or something? Either way I'll take a look into it as I love that idea more!

[Calinou]

Would that be similar or the same as the _process function and we use the delta or something?

You increment/decrement a counter float variable with delta in _process, and run a certain block of code if counter exceeds a certain value (or is below zero).

[Knight-XAura]

Thank you. I will definitely shoot for that over the timer which definitely again feels cleaner this way. I'll let you know if I have any further questions about that

[Knight-XAura]

Hey so I been slowly moving forward with this of course and I'm starting to realize some stuff.

Here's how I see things working:

Scrollbar: Fade enabled, fade delay, and fade time. Show on hover enabled (uses fade delay and fade time for fade out)

ScrollContainer: Fade enabled, fade delay, and fade time Show on hover enabled Auto Overlay scroll mode (Needed for enabled new features to take affect)

Now back to what used to be touch and hover in my original thoughts which now I'm calling auto overlay. I could keep this touch and hover, but there's a needed advantage to a single scroll mode, cross platform usage. Next I want to say auto overlay could become a boolean for auto called overlay enabled, but I think it's better to stick to a new scroll mode. I also think a single scroll mode maybe better as it requires 1 less gross looking addition of options, especially a boolean dependent on a specific scroll mode.

I do find the addition of all these options to be gross when it comes to the fact they only apply to a certain scroll mode, but I'm not sure how else to handle that mess.

I'd appreciate thoughts and feedback on this more simplified idea of this project as I feel in my head it streamlines things a bit more.