Scroll Bars

[onpon4]

This is something that's been a problem for a long time, but I'd like to bring up the fact that we could really use a scroll bar widget that can hold a larger amount of stuff (typically text) than can fit into a space. Preferably the scroll bar widget should only actually show a scroll bar when necessary because of the size it needs to use.

This would be especially useful for making changing text size as a menu option feasible. Right now, increasing text size can just lead to text overlapping other elements or becoming impossible to see. Having scroll bars like this would allow us to have more flexibility with positioning and size of text.

🕵️

[UncombedCoconut]

Exists: toolkit_drawScrollbar() and (*mwheelevent)() usable by other widgets. Probably doable:

• bolting those onto individual text widgets
• implementing window_addScrollWindow, similar in spirit to window_addTabbedWindow -- you get a child widget which is window-like in the sense of being a container for more widgets. There's just extra anxiety about precisely how we clip content that's out of view and get events to propagate correctly.

Anything much fancier than this would tend to challenge the idea that a game should be in the GUI toolkit business. :) https://github.com/Immediate-Mode-UI/Nuklear looked potentially interesting, though it's a large beast and replacing a working tk would guarantee a near-endless supply of bugs.

[bobbens]

I think the main thing would be to just create a more robust text widget. Easiest solution would be to compute the height of the text when creating the widget and adding a scrollbar as necessary. That said, relying on scrollbars all over will probably decrease the GUI ease of use all over.

Other thoughts:

• Scrollbar could be hidden, and fade in/out when being used (like cellphone interfaces)
• Indicators should show that text is scrollable
• I really don't think that allowing increasing the text size all over the game would be solvable with just adding scrollbars, some sort of fluid interface (like HTML/CSS-based) would be necessary to not end up having everything blow up randomly all over the place.
• Using a library would have been a good idea, but back in the day, there were no good candidates. Moving over is probably a monumental task that I can't recommend much unless it is tied with moving most of the interface stuff to Lua ;)

[onpon4]

I think the main thing would be to just create a more robust text widget.

That wouldn't work. We have some cases where multiple separate text areas need to be scrolled together. See the headers and text of e.g. the Equipment screen for instance.

Of course, there's a question about whether it's even a good idea to design it like this, but it's what we've currently got.

Scrollbar could be hidden, and fade in/out when being used (like cellphone interfaces)

I don't think that's a good idea. It could make it not very obvious that there's scrolling to do especially if it turns out that the text gets cut off in a place that just so happens to not partially obscure anything. The only reason that's a good design for cell phone interfaces is because you don't actually use it as a scroll bar and because phone screens need to make as efficient use of their space as possible.

I really don't think that allowing increasing the text size all over the game would be solvable with just adding scrollbars, some sort of fluid interface (like HTML/CSS-based) would be necessary to not end up having everything blow up randomly all over the place.

There's more to consider, but I think scroll bars are an essential component especially for long descriptions. I think the addition of the feature can allow bumping up the text size quite a lot without either sacrificing screen real estate or making some text impossible to read.

I think even if scroll bars were just used on descriptions, that could bump the maximum feasible text size at 720p up substantially. Really, outfit and ship descriptions are the most important choke points.

🕵️

[bobbens]

I think the main thing would be to just create a more robust text widget.

That wouldn't work. We have some cases where multiple separate text areas need to be scrolled together. See the headers and text of e.g. the Equipment screen for instance.

That should be changed, especially if the font size can increase, because the moment one of the text areas gets an extra line break inserted, it's all broken. This could also be seen as part of a more robust text widget. Although it might also be possible to rethink this without the explicit alignment we have now, avoiding the issue to do a fancier solution.

Scrollbar could be hidden, and fade in/out when being used (like cellphone interfaces)

I don't think that's a good idea. It could make it not very obvious that there's scrolling to do especially if it turns out that the text gets cut off in a place that just so happens to not partially obscure anything. The only reason that's a good design for cell phone interfaces is because you don't actually use it as a scroll bar and because phone screens need to make as efficient use of their space as possible.

I'm mainly thinking about how ugly it can look if we have the current scrollbars all over. I don' think hiding scrollbars should be a problem as long as it is clear what area is scrollable and such, but just making the scrollbar prettier would probably be fine.

There's more to consider, but I think scroll bars are an essential component especially for long descriptions. I think the addition of the feature can allow bumping up the text size quite a lot without either sacrificing screen real estate or making some text impossible to read.

Limiting it to descriptions would probably be best at first, but if the player is allowed to arbitrarily change the font size, we are likely to run into issues with things like buttons overlapping or going off screen, and lots of other issues all over, even with relatively small size increases. My impression is that the current system is fairly fragile, and I'm not sure how well we can make it work with just tweaking small things here and there.

[onpon4]

Well we don't have to go with the most extreme version of font size change. I figured we could just end up having a "text size" slider that maxes out at the largest we can feasibly allow text to be.

🕵️