[Tab list idea] Allow custom slots in DYNAMIC_SIZE tab list

[Andre601]

This issue aims at suggesting a new behaviour for the DYNAMIC_SIZE tab list which would essentially allow the usage of custom slots within the tab while keeping a dynamic size feel to it.

How it works

The system could work like this: Whenever you put the components part into the config file for the tab would the dynamic tab enter a sort of hybrid stage, where it allows you to define custom slots to display before and after !players components.

I'm not entirely sure if the tab should fill out the column completely or only add all custom slots alongside any players matching the player sets defined.
In either case should the tab "expand" the columns when the amount of used slots goes beyond what the current column count can support, until all 4 columns are filled.

Similar to the above am I unsure how certain components like !table or !players_by_server should work or if they even should work at all.
Perhaps the !table component could be used as a way to keep a certain amount of columns open while still having the dynamic aspect available, but that's up for discussion I would say.

New placeholders

With this new type would of course come new challenges in terms of tab list designs, as a design made for 2 columns could break when the tab increases to 3 or reduces to 1.
For that do I suggest some new placeholders and components to utilize here.

!row

The !row component would fill slots vertically with the provided components and then move on to the next column, continuing on the same height as before (See examples at the bottom).
This would be extremely useful to have dynamically changing dividers to keep spaces or similar in between custom slots and player slots.

A random option could be used where the order of components is randomized.
I also feel like that an option to fill slots only horizontally, which would result in a single row being made, should be made available too.

If you want to have a single row of empty slots could !row{} be utilized to achieve this.

Here is the possible syntax to use:

- !row
  component: # Would fill each column with an empty and filled slot vertically.
  - {}
  - {center: "&7==============="}

${tablist}

The ${tablist} placeholder would be useful in places like !conditional or !switch components, to return different results based on it.
The placeholder on its own would return how many slots are currently displayed/set in the tab list. Appending a columns option would instead return the number of columns currently used.

Assuming we want to display "Welcome ${viewer name}" centered on the top two slots of the tab could it be used in the following switch component (Assuming !switch can be used within the component section):

- !switch
  expression: "${tablist columns}"
  replacements:
    "3":
    - {}
    - {center: "&7Welcome"}
    - {}
    - {}
    - {center: "&a${viewer name}"}
    - {}
    "4":
    - {}
    - {center: "&7Welcome"}
    - {center: "&a${viewer name}"}
    - {}
  defaultReplacement: # Just 1 or 2 column(s) in this case
  - {center: "&7Welcome"}
  - {center: "&a${viewer name}"}

Example

Here's an example I once created showcasing how this could look when utilized.

Config:

type: DYNAMIC_SIZE

components:
- !switch
  expression: "${tablist columns}"
  replacements:
    "3":
    - {}
    - {center: "&7Welcome"}
    - {}
    - {}
    - {center: "&a${viewer name}"}
    - {}
    "4":
    - {}
    - {center: "&7Welcome"}
    - {center: "&a${viewer name}"}
    - {}
  defaultReplacement:
  - {center: "&7Welcome"}
  - {center: "&a${viewer name}"}
- !row
  components: # Would fill a row of 2 slots
  - {}
  - {center: "&7==============="}
  fillSlotsVertical: true
- !players
  playerSet: all_players
  playerComponent: "${player name}"
- !row{} # Defaults to a single row of empty slots
- !switch
  expression: "${tablist columns}"
  replacements:
    "2":
    - {text: "&7Website"}
    - {text: "https://example.com"}
    "3":
    - {text: "&7Website"}
    - {}
    - {text: "https://example.com"}
    "4":
    - {}
    - {text: "&7Website"}
    - {text: "https://example.com"}
    - {}
  defaultReplacement:
  - {center: "&7Website"}
  - {center: "https://example.com"}

Results:

• 1 column
  
• 2 columns
  
• 3 columns
  

But why?

There is currently no way of using custom slots in a dynamic tab list. There is a columns option for the FIXED_SIZE tab, which I and probably some other people assumed is a way to get this behaviour, which isn't the case unfortunately.

The real use of the columns option is pointless as the only difference to a normal FIXED_SIZE tab list is the fact, that the amount of rows can expand slightly if the column count set is 2 (15 rows that expand to 20).

This option would be a true hybrid of the two existing types that brings benefits from both sides: Not having a gigantic tab list while still having custom slots available.

Credits

This idea was originally a Suggestion by me from the Discord server, but I decided to make an issue out of it, to properly track it, as I fear that the suggestion might get lost otherwise.

[CodeCrafter47]

Opening an issue is a good call.

I'm thinking, that instead of adding a new tab list type, I'd like to extend the dynamic size type, so that components can be used.

Can you do an example of the !row component with fillSlotsVertical: false? I can't really think of a situation where this would be useful.

[Andre601]

Can you do an example of the !row component with fillSlotsVertical: false? I can't really think of a situation where this would be useful.

When the option is disabled would it only make a single row, but each slot has another entry from the list. If there are more list entries than available columns would it disregard any remaining ones.

For example:

- !row
  component:
  - {}
  - {center: "=========="}

The above would create the following rows:

<!-- 1 column -->
| column 1 |
| -------- |
| {}       |

<!-- 2 columns -->
| column 1 | column 2               |
| -------- | ---------------------- |
| {}       | {center: "=========="} |

<!-- 3 columns -->
| column 1 | column 2               | column 3 |
| -------- | ---------------------- | -------- |
| {}       | {center: "=========="} | {}       |

<!-- 4 columns -->
| column 1 | column 2               | column 3 | column 4               |
| -------- | ---------------------- | -------- | ---------------------- |
| {}       | {center: "=========="} | {}       | {center: "=========="} |

I also agree that this option might be useless to have and that the row option should fill slots vertically by default, but I thought maybe there are people that want this?
But if you think it really isn't useful can you disregard this idea.

[Andre601]

Also, if this would become a thing for dynamic size, is the columns option of fixed size still needed?
Because let's be honest, that feature is basically useless. What does it do that fixed-size doesn't offer already? The only thing I see here is that it allows some minor flexibility by increasing the tab when slot count is between 30 and 40 as those are the only sizes with the same column count.
Everything else seems useless.

[CodeCrafter47]

I don't think the columns option of the fixed size tab list is useful. It allows you to create a tab list whose size adapts to the content without having to deal with a changing number of columns. Especially when using a low number of columns, e.g. 1 or two, you are unlikely to notice that the flexibility is limited.

[Andre601]

So I think this behaviour would be a possible idea for Dynamic Size tab list, while keeping it functional for existing setups:

Whenever you add the components: part to the tab list would that take priority over the different player* settings (playerComponent, playerOrder, etc), so displaying players and such would need to be done in the components part using the !players or !players_by_server option.

Thinking of this, would it even be a good idea to have that second option? I feel like this would only add extra difficulties and weird looking tab lists to the plugins and wouldn't be a beneficial implementation to have. Unless it would act differently in dynamic size (i.e. fills vertically by default instead of horizontally)

[Andre601]

I updated the original comment with the new info we got here through our conversation, as the original idea was quite different compared to what we figured out so far.