Add a button to Storage Terminal to configure search bar autofocus.

[nskobelevs]

Why?

Often when using a Storage Terminal - even more often with the portable one - a player once to open the inventory to quick get a specific item (e.g. while building a project).

With a large about of items this is slow and having to click the search bar with every opening of the inventory takes precious time.

What?

This PR introduces a new button that will enable/disable the auto-focusing of the search bar upon opening the inventory allowing the player to instantly start searching

More Info

Demonstration:

https://user-images.githubusercontent.com/34107736/195216553-0b6787f2-7336-4fe6-9898-c1bcf3a0768a.mov

Icons

Enabled	Disabled

Comments

1. I added the .idea folder to .gitignore since the repo doesn't currently contain one. Let me know if you don't want this.
2. The Integrated Tunnels dependency will be removed when ready to merge.
3. The autofocus is hindered by the search bar storing it's contents. Maybe the option can also enable/disable whether or not to do so? Maybe toggling between the 4 options of autofocus/remember search similar to AE2? Or maybe autofocus should auto-select the whole text?

[CLAassistant]

All committers have signed the CLA.

[nskobelevs]

When JEI compat is enabled, you'll notice that buttons start overlapping with inventory slots, which is a bit problematic.

Yes this is something I also noticed but forgot to bring up!

I like the idea of using the right side. It's currently completely empty and it's better to put extra buttons there than increase base height of the screen.

The question with that is do we want to have separate lists for left and right buttons or should we only render buttons on the right if they're likely to overlap something? The latter might mean less refactoring to implement but would unfortuantely introduce inconsistent button locations between GUI sizes.

[rubensworks]

The question with that is do we want to have separate lists for left and right buttons or should we only render buttons on the right if they're likely to overlap something? The latter might mean less refactoring to implement but would unfortuantely introduce inconsistent button locations between GUI sizes.

I would suggest filling first from left, until there's no more space (based on grid height), and continuing right in that case. That would indeed mean that different gui sizes would lead to different button locations, but I don't think that's a problem.

[nskobelevs]

I would suggest filling first from left, until there's no more space (based on grid height), and continuing right in that case. That would indeed mean that different gui sizes would lead to different button locations, but I don't think that's a problem.

Sounds good, I'll get on that!

[nskobelevs]

Apologies for the delay, have been busy with my studies.

iirc last time I worked on this the main issue I had was calculating the position of the button on the right side of the menu.

Would appreciate a point in the right direction given you know the codebase better than anyone.

[rubensworks]

No worries :-)

The button positions are currently calculated from the hardcoded static fields BUTTONS_OFFSET_X, BUTTONS_OFFSET_Y, and BUTTONS_OFFSET in ContainerScreenTerminalStorage. So we'll probably need a more elaborate mechanism that can handle the two columns.

One idea: an iterator or stream that can provide button positions, and thereby automatically provides positions for the second column once the number of buttons (or button Y position) exceeds the grid height. But I'm definitely open to other solutions.

I'm pretty sure these changes will be restricted to only ContainerScreenTerminalStorage.

[nskobelevs]

BUTTONS_OFFSET_X, BUTTONS_OFFSET_Y, and BUTTONS_OFFSET

So yeah from the original code I understood that BUTTONS_OFFSET is the offset gap between the buttons themselves.

Do BUTTONS_OFFSET_X and BUTTONS_OFFSET_Y define the origin / top-left corner of where the buttons are based from?

So we'll probably need a more elaborate mechanism that can handle the two columns.

I also started to think about that given the button positions are calculated in 3 different places and duplicating the code so many times wouldn't be great.

I do like your iterator idea! Currently I have a method that just takes in a callback but that has been quirky when trying to return early so I'll play around with creating an iterator.

[rubensworks]

Do BUTTONS_OFFSET_X and BUTTONS_OFFSET_Y define the origin / top-left corner of where the buttons are based from?

Yes, I think so (if I remember correctly). So for the second column, the X will have to be offset by the grid width.

[rubensworks]

Closing this due to staleness, but happy to re-open in case of any further progress! :)