Fix glitches for SlotWidgets inside ScrollableListWidgets #1558
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What:
Trying to use a slot widget inside a scrollable list widget leads to a number of glitchy behaviours.
The main cause of this is that the slots are NOT drawn inside the normal drawInBackground() handling where the ScrollableListWidget applies a scissor. Instead they are drawn "out of band" in ModularUIGui.
How solved:
When a ScrollableListWidget determines the positions of its components and its size, it now visits each of its widgets and gives them the option to remember its area that is actually visible.
The SlotWidget does this. It exposes this area through a new interace "gregtech.api.gui.IScissored" on its slot delegate.
When the ModularUIGui displays the slots, it checks for this new interface and uses it as a scissor to determine how much (if any) of the slot should be drawn.
The end result is that ModularUIGui can now do the same scissor handling for slots that would normally be done in drawInBackground if the slots behaved like other widgets.
The ScrollableListWidget now checks if a widget is within its visible area when it checks if a widget can be clicked.
Previously it just used the AbstractWidgetGroup handling which assumes all sub widgets were visible if the group is.
A number of places use Slot.isEnabled() to check for behaviours, like showing tooltips and some behaviours internal to SlotWidget itself. SlotWidget.isEnabled was not taking into account whether it was actually visible inside a ScrollableListWidget.
SlotWidget.isEnabled() has been changed to use the scissor from (1) when determining if it is enabled.
Outcome:
Putting a slot widget inside a ScrollableListWidget is not as glitchy as it was.
I can't guarantee I have spotted all bugs in this area.
Additional info:
The workbench (crafting station) has a ScrollableListWidget that contains slots, but notably it doesn't use the SlotWidget.
It has its own implementation. I wonder if that is because of the issues I have fixed here?
Possible compatibility issue:
All of these changes except one only affect SlotWidgets inside ScrollableListWidgets. I don't think anybody else has done this, otherwise they would have seen these issues.
The one exception is the change to ScrollableListWidget.isWidgetClickable(Widget) which affects all subwidgets.
The fix seems correct even for non slot widgets, in that you shouldn't be able to click widgets outside the bounds of the
visible scroll area.