Maybe would be wise to wait for project Interface lift to develop this issue.

The pattern can be distributed through sequences coloured cells with the size of the next number on the fibonacci sequence, or the other way around - coloured cells are separated by sequences of quiescent cells in the sizes of the fibonacci sequence.

When exporting the simulation as an image, support the following options:

1. Cell scale: square root of the amount of pixels representing 1 cell (Type: Integer)
2. Show grid lines: configuration for inclusion or exclusion of the lines of the grid of cells (Type: Boolean)
3. Grid lines thickness: the amount of pixels to be used as grid line thickness (Type: Integer)
4. Grid lines colour: the colour of the lines of the grid of cells (Type: String)

Review all classes from module cas-ui-desktop to ensure it follows best practices in terms of coding, logic and format.

CAS is currently mixing SWING/AWT with 2 Processing applets, which doesn't seems really good.

SWING/AWT was used to avoid the time required to draw GUI control components using Processing, but the idea of having the entire GUI using Processing only is great! There are Processing GUI libraries out there like ControlP5 that require some investigation to conclude if their components support all CAS needs (window resizing, fullscreen, scrolls, buttons, fields, etc..).

The use of 2 Processing applets (one for the rule configuration and the other for the simulation view) seems to cause an excessive resource consumption that could be avoided by using a single Processing instance (with or without SWING/AWT). Also, it is important to use latest Processing. If the entire GUI could not be migrated to a single Processing instance somehow, then different technologies should be considered.

If no technology could be found to handle the job, maybe it should be considered to keep using SWING/AWT but along with JOGL.

Create field validations and behaviour for each one of the visual components of #50.

This issue should consider conclusions reached on issues #5 and #6.
The simulation view area should always handle the resizing, other components like configuration can stay at a static size.

Create a set of *.png files, each dedicated to the configuration of one elementary rule, covering all the 256 elementary rules.

(related to #23 )

Full description at #50 (comment)

Review all classes from module cas-unidimensional to ensure it follows best practices in terms of coding, logic and format.

Allow the result of a simulation to be exported as TXT (also keep PNG).
Create format capable to handle multiple cell states, and multiple iterations of multiple dimentions.

The resources from #50 should not be visible from the original GUI, but even though accessible through it, as this resource is still a prototype.

This issue should consider conclusions reached on issues #5 and #6.
The simulation view area should always handle the resizing, other components like configuration can stay at a static size.

Maybe would be wise to wait for project Interface lift to develop this issue.

The initial condition should randomize the colors and the sequences.

Time is used in the constructors of both Space and Universe.
Space uses Time in its constructor to validate the amount of dimensions across them, but don't keep Time as attribute.
Universe, however, only keeps Time as attribute.
The instance of Time informed in the constructors of both Space and Universe must be the exact same, therefore, a validation must take place to match them somehow.

The neighborhood configuration should allow to choose a specific set of neighbors for a given amount of dimensions.

e.g one-dimensional cellular automata can set the range of neighbors used at the sides of the reference cell, while two-dimensional cellular automata should decide between Moore neighborhood and von Neuman neighborhood.

Review all classes from module cas-core to ensure it follows best practices in terms of coding, logic and format.

Full description at #50 (comment)

Allow the configuration of the states to be used in the cellular automaton, also their respective values/colors.

Create the visual components that will allow for input the configuration used by the logic of #50.

Full description at #50 (comment)

Create a set of *.cas files, each dedicated to the configuration of one rule, covering all the 256 elementary rules.

Full description at #50 (comment)

This issue should consider the conclusions achieved on #5.
Here is a proposal for a new GUI:

The three components on top of the window should act as tabs, switching everything that is displayed in other components. This way, each tab acts independent from the others, so the user can simulate three cellular automata (one per tab) and see each one of them by navigating through the tabs.

Left corner keeps all configurations grouped by domain (similar to how it is today). Each option shows a panel on the right side that provides a good amount of space to interact with components. This panel can have a scrollbar if the amount of components is too big. The user can show/hide this panel at any time by clicking in the configuration options. The visualization of each configuration option is mutually excludent.

Right corner holds the tools to analyze the result of a simulation, same as it is today.

Bottom of the window contains the flow controls of the simulation (play complete, by step, discard/new, etc.)

All the white area of the window can be used to render the result of the simulation. This way, the window can be resized or enter fullscreen mode and all components can still be oriented to the window corners.

Review all classes from module cas-control to ensure it follows best practices in terms of coding, logic and format.

Maybe would be wise to wait for project Interface lift to develop this issue.

Initial conditions based on sequences of colors are already supported by internal mechanisms. It is required to expose such configuration to the user through the GUI.

Integrate the new resources related to #50 to the existing structure of activity state.

Great project, specially for beginners such as me, it helps a lot!

I was wondering if async updates would be a wanted feature. Such as is described here

Thanks!

Related to #10