This PR has now changed course and been thoroughly simplified: the concept of rooms was developed to manage fixed tables.
I realized that the way I did that was pretty complicated, when a simpler solution was possible.
New solution
This PR introduces a way to add a screen to a "room" (defined by a family), allowing the fixed tables to be in a screen of their own, accessible from any screen of the family.
In order to ensure special menu = options are distinct from screens, a @ has been added to each of the view, update and family options.
The previous options are now deprecated and will be removed from version 2.6
TODO:
[x] Syntax and implementation
[x] Documentation
[ ] Testing to see if works as documented
This is a PR to define playing rooms when an event spans multiple of those.
Currently, only defines the feature's syntax.
~~With the current changes, I think the first syntax (room sections) is clearer but more verbose and cumbersome.
The second one (additional syntax) is easier to use, but slightly harder to parse for a computer, although the concepts are simpler to implement.~~
With a bit of thought, I think the second one is better
TODO:
[x] Choose one syntax over the other for multiple tournaments
[ ] Define the interaction of the feature with other configuration features
UPDATE
This PR has now changed course and been thoroughly simplified: the concept of rooms was developed to manage fixed tables. I realized that the way I did that was pretty complicated, when a simpler solution was possible.
New solution
This PR introduces a way to add a screen to a "room" (defined by a family), allowing the fixed tables to be in a screen of their own, accessible from any screen of the family. In order to ensure special
menu =options are distinct from screens, a@has been added to each of theview,updateandfamilyoptions. The previous options are now deprecated and will be removed from version 2.6TODO:
This is a PR to define playing rooms when an event spans multiple of those.Currently, only defines the feature's syntax.~~With the current changes, I think the first syntax (room sections) is clearer but more verbose and cumbersome. The second one (additional syntax) is easier to use, but slightly harder to parse for a computer, although the concepts are simpler to implement.~~
With a bit of thought, I think the second one is betterTODO:Choose one syntax over the other for multiple tournamentsDefine the interaction of the feature with other configuration featuresActually implement everything