[Suggestion] Multiblock centralized GUI

[LAGIdiot]

Idea: Multiblocks will have only one GUI which will use tab system to show separate components.

Why: This should allow easier control over multiblocks without need to run around and checking every input/output separately.

Concept: Use tab system introduced in Crafting Station. Controller and every MultiblockAbility (with GUI) existing and new will have own tab. All MultiblockAbility will be grouped together. Which means that if multiblock is using more then one Input Bus all of them will be listed on one page. When any of blocks which currently open GUI on multiblock is requested to show GUI it will show full tabbed GUI on its ability page scrolled and highlighted to itself.

[serenibyss]

I've started working on this suggestion, but I've run into some problems aside from just design decisions.

In order to properly create these tabs, I have a few options that I can see at the moment:

• I create them in RecipeMapMultiblockController and FueledMultiblockController, which definitely makes the most sense since that is where the input and output data is stored for the combined inventory, and they are extended by all multiblocks, save for the PBF and Coke Oven (which I think are ok to not have this feature, as they are very "primitive"). However, this has some problems, since common code has to be called, and those files are both in api. The reason it needs common code is because it needs access to inventory methods, such as IItemList and IItemInfo which are both common.
• I create them individually in each multiblock controller, breaking out of api, meaning lots of work for us and for addons that want to use this feature. This would be the "simplest," but also the worst solution, since there is no reason for this generic code to be copied all over the place.
• I create methods in a new file in common, that all multiblock controllers can use. This could either be done as public methods accessible from anywhere, which would save compatibility, but would not be very good design. Another way is to have controllers extend the class in addition to the api classes, which would allow for good compatibility as well, since controllers that want to use this would just extend it and call the methods from there. There may be design problems with this though, as it would require some additional code in each controller that is otherwise unnecessary.
• We refactor sections of code to allow for some of these classes in common to be moved to api, as I don't see why some of them cannot be there. However, there may be a reason for it, so this option may not work.
• We create some sort of parent class in common between the api classes and the controller common classes that can handle the GUI changes. This is potentially bad for compatibility, but since it wouldn't remove the ability to extend the api classes directly still and would instead be an optional in-between class, it might be okay.

Ultimately, I do believe this is possible. However, I may need some help addressing this api/common issue. There are certainly solutions other than the above, these are just what I was able to come up with so far. I am personally leaning to the third solution, specifically extending a class that implements these methods. I also think the last option may be viable, but may introduce some issues I haven't thought of. I don't believe these are amazing solutions, but I do think they're the best of what I've come up with so far.

I really like this idea, and I would love to implement it. I've already converted the controller GUI to a tab successfully, so I would hate to see this idea disappear because of these issues.

[serenibyss]

Upon giving this some thought overnight and today, I think this code definitely needs to be in api. But, that may mean adjusting the Crafting Station tab code a bit, or creating all new Widgets to allow for this distinction. The only issue is we may need to add some code to handle items/fluids in api in addition to this, so it may end up being a lot of code added.