docs(masonry): fix lint errors

modules/masonry/docs/PRD/Masonry_Design_Document.md

@@ -1,18 +1,20 @@
-
----
-
 # Music Blocks v4 : Masonry Design Document
 
 ## Overview
 
 1. **Short Description of the Product**
-   - The Masonry (previously called Project Builder) in Music Blocks v4 facilitates graphical brick-based music composition, offering various Brick types such as Start, Rhythm, Note, Pitch, and Instrument Bricks. Each brick represents a specific functionality, enabling users, especially children, to visually create music programs. The Masonry module simplifies the process of selecting and arranging bricks to generate music sequences.
+   - The Masonry (previously called Project Builder) in Music Blocks v4 facilitates graphical brick
+   -based music composition, offering various Brick types such as Start, Rhythm, Note, Pitch, and
+   Instrument Bricks. Each brick represents a specific functionality, enabling users, especially
+   children, to visually create music programs. The Masonry module simplifies the process of
+   selecting and arranging bricks to generate music sequences.
 
 2. **Key Features**
    - Enhance the brick library with comprehensive functionalities and render the stack of bricks.
    - Implement collision detection and enhance the user interface for a seamless user experience.
    - Add text to bricks (SVGs) for customization and personalization.
-   - Introduce a palette feature, allowing for effortless music composition through intuitive drag-and-drop functionality.
+   - Introduce a palette feature, allowing for effortless music composition through intuitive
+    drag-and-drop functionality.
    - Integrate Music Blocks v4 with Masonry to streamline music program creation.
    - Address bugs and make overall improvements to enhance the tool's performance and usability.
 
@@ -22,30 +24,42 @@
    - Editing music sequences dynamically.
 
 4. **Subsystems**
-   - Palette Subsystem: Manages the palette interface within Music Blocks, providing a selection of bricks for users to drag and drop into the workspace.
-   - Workspace Subsystem: Controls the workspace area where users can arrange bricks and create music compositions.
-   - Brick Stack Subsystem: Handles the creation and management of stacks of bricks within the workspace, allowing users to combine bricks to form musical sequences.
-   - Collision Detection Subsystem: Implements collision detection functionality within the workspace, ensuring that bricks interact appropriately to prevent overlapping or conflicting arrangements.
+   - Palette Subsystem: Manages the palette interface within Music Blocks, providing a selection of
+    bricks for users to drag and drop into the workspace.
+   - Workspace Subsystem: Controls the workspace area where users can arrange bricks and create
+   music compositions.
+   - Brick Stack Subsystem: Handles the creation and management of stacks of bricks within the
+   workspace, allowing users to combine bricks to form musical sequences.
+   - Collision Detection Subsystem: Implements collision detection functionality within the
+   workspace, ensuring that bricks interact appropriately to prevent overlapping or conflicting arrangements.
 
 5. **Additional Functionality and Design**
    - Implementation of a MusicBlocks guide button at the top of the interface for user convenience.
-   - Integration of a collision detection UI inspired by the Brickly game by Google, enhancing user experience and interaction feedback.
-   - Optimization of the palette by combining similar types of bricks, reducing clutter and improving usability.
-   - Enhancement of the search functionality to facilitate easier navigation and selection of bricks within the palette.
+   - Integration of a collision detection UI inspired by the Brickly game by Google, enhancing user
+    experience and interaction feedback.
+   - Optimization of the palette by combining similar types of bricks, reducing clutter and
+   improving usability.
+   - Enhancement of the search functionality to facilitate easier navigation and selection of bricks
+    within the palette.
 
 6. **Purpose**
-   - The purpose of this document is to outline the design and architecture of Masonry framework for Music Blocks v4
+   - The purpose of this document is to outline the design and architecture of Masonry framework for
+    Music Blocks v4
 
 7. **Scope**
-   - This document covers the technical details and design considerations of Music Blocks v4, including its features and subsystems.
+   - This document covers the technical details and design considerations of Music Blocks v4,
+   including its features and subsystems.
 
 8. **Audience**
-   - The intended audience includes developers, contributors, and members involved in the development and maintenance of Music Blocks v4.
+   - The intended audience includes developers, contributors, and members involved in the development
+   and maintenance of Music Blocks v4.
 
 9. **Definitions and Abbreviations**
-   - **Masonry:** The term used to describe the replication and enhancement of the functionality related to bricks from the palette, stack of bricks, and other related components of the project, aimed at improving their functionality and effectiveness.
+   - **Masonry:** The term used to describe the replication and enhancement of the functionality
+    related to bricks from the palette, stack of bricks, and other related components of the
+    project, aimed at improving their functionality and effectiveness.
 
-[Screencast from 13-05-24 12:15:30 PM IST.webm](https://github.com/Karan-Palan/musicblocks-v4/assets/143683619/ae9df412-8b3a-4930-8635-ad89da828ba9)
+    [Screencast from 13-05-24 12:15:30 PM IST.webm](https://github.com/Karan-Palan/musicblocks-v4/assets/143683619/ae9df412-8b3a-4930-8635-ad89da828ba9)
 
 10. **References**
 
@@ -55,26 +69,28 @@
 ## Requirements, Wiki Storages and Docs
 
 1. **Requirements**
-   - Functional requirements: Dynamic editing, text addition, UI enhancements, palette feature, integration with Music Blocks v4 project.
+   - Functional requirements: Dynamic editing, text addition, UI enhancements, palette feature,
+   integration with Music Blocks v4 project.
    - Non-functional requirements: Performance, scalability, maintainability.
 
 2. **Wiki Storages**
    - [Link to project documentation](https://github.com/sugarlabs/musicblocks/blob/master/guide/README.md)
 
-4. **Docs and Responsible Entities**
+3. **Docs and Responsible Entities**
    - Documentation maintained by project contributors.
    - Responsible entities: Project maintainers, contributors.
 
-5. **Roles, Responsibilities, and Assumptions**
+4. **Roles, Responsibilities, and Assumptions**
    - Roles: Developers, contributors, project maintainers.
    - Responsibilities: Implementing features, reviewing code, documenting changes.
-   - Assumptions: Basic understanding of React, JavaScript/TypeScript, and information about Music Blocks software.
+   - Assumptions: Basic understanding of React, JavaScript/TypeScript, and information about Music
+   Blocks software.
 
 ## Architecture and Requirements Diagram
 
 To be added
 
-## Design Specification
+### Design Specification
 
 #### 1. Workspace
 

modules/masonry/docs/PRD/PRD.md

@@ -5,12 +5,16 @@
 
 ### a. Brick Types
 
-#### 1. Data Bricks: These serve as inputs for other bricks and come in two types: hardcoded and editable
+#### 1.Data Bricks: These serve as inputs for other bricks and come in two types
 
-- Hardcoded Data Brick: Fixed values that cannot be changed by the user. Examples include predefined note values, counts, etc.
+#### hardcoded and editable
+
+- Hardcoded Data Brick: Fixed values that cannot be changed by the user. Examples include predefined
+ note values, counts, etc.
 
      ![alt text](../images/image.png)
-- Editable Data Brick: Values that can be modified by the user. When clicked, these bricks open a text editor or a dropdown menu for user input, allowing customization of note names, pitches, etc.
+- Editable Data Brick: Values that can be modified by the user. When clicked, these bricks open a
+text editor or a dropdown menu for user input, allowing customization of note names, pitches, etc.
 
      ![editable bricks](../images/image-1.png)
 
@@ -22,7 +26,9 @@
 
    ![example](../images/image-3.png)
 
-#### 4. Block Bricks: Contain nesting, also execute something like the statement bricks. Takes 0 or more arguments
+#### 4. Block Bricks: Contain nesting, also execute something like the statement
+
+#### bricks. Takes 0 or more arguments
 
    ![alt text](../images/image-14.png)
 
@@ -31,19 +37,28 @@
 - **Distinct Shapes**: Each brick type has a unique shape to differentiate its function visually.
 - **Colors**:
      1. **Original Color**: Each brick has a unique color that represents its type.
-     2. **Hover Color**: When a user hovers over a brick, it changes to a distinct color to indicate it is selectable.
-     3. **Disconnected Color**: If a brick is not connected to the stack, it turns gray to indicate it is inactive.
-     4. **Execution Color**: When a brick is executed, it changes to a darker shade of its original color to show that it has been activated.
-- **Sprites**: Visual symbols that indicate specific functions or properties of the brick. Some bricks may have sprites (like the start brick), while others may not.
+     2. **Hover Color**: When a user hovers over a brick, it changes to a distinct color to indicate
+      it is selectable.
+     3. **Disconnected Color**: If a brick is not connected to the stack, it turns gray to indicate
+      it is inactive.
+     4. **Execution Color**: When a brick is executed, it changes to a darker shade of its original
+      color to show that it has been activated.
+- **Sprites**: Visual symbols that indicate specific functions or properties of the brick. Some
+bricks may have sprites (like the start brick), while others may not.
 - **Labels**:
      1. **Functionality Labels**: Text labels that indicate the function of the brick.
-     2. **Argument Labels**: Text labels that indicate the arguments or parameters that need to be provided for the brick's function.
+     2. **Argument Labels**: Text labels that indicate the arguments or parameters that need to be
+     provided for the brick's function.
 - **Input/Output Ports**: Connectors that visually represent where bricks can attach to each other.
-- **Editable Text Labels/Fields**: Users can input data directly into the bricks, such as note names, durations, and numerical values.
+- **Editable Text Labels/Fields**: Users can input data directly into the bricks, such as note names,
+ durations, and numerical values.
 
-   **Side Note:** If we want to implement a design similar to Scratch in the future, we can consider the following approach for connecting blocks:
+   **Side Note:** If we want to implement a design similar to Scratch in the future, we can consider
+the following approach for connecting blocks:
 
-- In Scratch, blocks are connected horizontally in a row for sequential execution. Each block has a tab at the bottom and a notch at the top, allowing them to snap together in a linear sequence. This design makes it clear which blocks will execute in order.
+- In Scratch, blocks are connected horizontally in a row for sequential execution. Each block has a
+tab at the bottom and a notch at the top, allowing them to snap together in a linear sequence. This
+design makes it clear which blocks will execute in order.
 
 ### c. Brick Interactions
 
@@ -59,8 +74,11 @@
 
      ![dedicated editors](../images/image-5.png)
 - **Connection Types**:
-     1. **Argument Connections**: Bricks can be connected to input arguments of other bricks. This allows for passing data or parameters into the brick’s function.
-     2. **Brick-to-Brick or Stack Connections**: Bricks can be connected directly to other bricks or to a stack of bricks. This enables building complex sequences and structures by chaining bricks together.
+     1. **Argument Connections**: Bricks can be connected to input arguments of other bricks. This
+     allows for passing data or parameters into the brick’s function.
+     2. **Brick-to-Brick or Stack Connections**: Bricks can be connected directly to other bricks or
+      to a stack of bricks. This enables building complex sequences and structures by chainingbricks
+       together.
 
         ![alt text](../images/image-8.png)
 
@@ -120,7 +138,8 @@
   - Searchbar design to be implemented:
 
       ![alt text](../images/image-17.png)
-          The idea here is to have a fixed searchbar on the left side of the workspace through which users can search for bricks, group them etc.
+          The idea here is to have a fixed searchbar on the left side of the workspace through which
+           users can search for bricks, group them etc.
           Note - It is just a one big list and categories on the left are positions on the list.
 
 ### d. **Drag and Drop**
@@ -130,7 +149,8 @@
 
      ![drag and drop](../images/image-12.png)
 
-  - While dragging a brick from the palette, the brick should temporarily disappear from the palette until it is placed in the workspace.
+  - While dragging a brick from the palette, the brick should temporarily disappear from the palette
+   until it is placed in the workspace.
 
 ## 4. Workspace
 

modules/masonry/docs/architecture/Processes.md

@@ -39,7 +39,8 @@
 2. **Select Brick**:
    - Input: Brick Selection
    - Output: Selected Brick Properties to Workspace
-   (How this works is, The palette will have a loaded list of SVGs. When you drag one from palette onto the workspace, the brick will be created on the workspace whos id matches to the one in brick)
+   (How this works is, The palette will have a loaded list of SVGs. When you drag one from palette on
+   to the workspace, the brick will be created on the workspace whos id matches to the one in brick)
 
 ### Workspace
 

modules/masonry/docs/tech-spec/TechSpec.md

@@ -1,10 +1,11 @@
 # Masonry Framework Tech Spec
 
-This tech spec outlines the implementation details for the Masonry Framework, a core component of the MusicBlocks V4 project built with React and TypeScript.
+This tech spec outlines the implementation details for the Masonry Framework, a core component of
+the MusicBlocks V4 project built with React and TypeScript.
 
 ## Project Structure
 
-```
+```md
 ├── src
 │   ├── utils
 │   │   ├── dragAndDropUtils.ts
@@ -64,7 +65,7 @@ This tech spec outlines the implementation details for the Masonry Framework, a
 
 ### Components
 
-#### a) Brick
+#### a Brick
 
 - **Brick.tsx:**
   - Properties:
@@ -122,7 +123,8 @@ This tech spec outlines the implementation details for the Masonry Framework, a
     - `onInputChange`: Callback for input change event.
     - `onOutputChange`: Callback for output change event.
   - Functions:
-    - `render()`: Renders the expression brick component with its visual appearance and input/output ports.
+    - `render()`: Renders the expression brick component with its visual appearance and input/output
+     ports.
     - `handleInputChange()`: Handles the input change event for the expression brick.
     - `handleOutputChange()`: Handles the output change event for the expression brick.
 - **StatementBrick.tsx:**
@@ -147,7 +149,7 @@ This tech spec outlines the implementation details for the Masonry Framework, a
     - `handleNesting()`: Handles the nesting logic for nested bricks.
     - `handleArguments()`: Manages the arguments for block bricks.
 
-#### b) Palette
+#### b Palette
 
 - **Palette.tsx:**
   - Properties:
@@ -177,7 +179,7 @@ This tech spec outlines the implementation details for the Masonry Framework, a
     - `render()`: Renders the search component with its visual appearance and input field.
     - `handleSearch()`: Handles the search event for the search component.
 
-#### c) Workspace
+#### c Workspace
 
 - **Workspace.tsx:**
   - Properties:
@@ -300,10 +302,6 @@ This tech spec outlines the implementation details for the Masonry Framework, a
 
 ### Models
 
-Certainly! Below, I'll expand on the properties and functionalities of the `Brick` model to include bounding boxes (b-boxes) and related methods:
-
-### Models
-
 - **Brick.ts:**
   - Properties:
     - `id`: Unique identifier for the brick.

modules/masonry/docs/tech-spec/Techspec.md

@@ -2,7 +2,7 @@
 
 ## Palette
 
-#### Config (Inputs)
+### Config (Inputs)
 
 - **Categories**:
   - **Attributes**: names, icons
@@ -11,14 +11,14 @@
     - **Bricks**:
       - **Attributes**: id, name, description, thumbnail, BBox
 
-#### Search
+### Search
 
 - **Search text**:
   - Substring match on name
   - Substring match on description
   - Minimum 3 characters
 
-#### Drag & Drop
+### Drag & Drop
 
 - **For a brick**:
   1. Start drag operation
@@ -35,7 +35,7 @@
 
 ## Brick
 
-#### Brick Types
+### Brick Types
 
 - **Data Bricks**
   - Returns values
@@ -54,7 +54,7 @@
   - Connects with other statement/block types
   - Can take 0 or more arguments
 
-#### Brick Appearance
+### Brick Appearance
 
 - **Attributes**:
   - Color
@@ -63,13 +63,13 @@
   - Any labels (copied)
   - Any connectors
 
-#### Brick Interactions
+### Brick Interactions
 
 - **Inline Edit**:
   - Only applicable to Data bricks
   - Example: input text
 
-#### Brick Structure Overview
+### Brick Structure Overview
 
 - **Brick**:
   - Color
@@ -92,7 +92,8 @@
 
 - **Visual Feedback**:
   - Indicators show whether brick combinations are valid.
-  - Example: A green outline appears for a valid connection, while a red outline indicates an invalid connection.
+  - Example: A green outline appears for a valid connection, while a red outline indicates an
+   invalid connection.
 - **Error Indicators**:
   - Provide explanations for incompatible connections to help users troubleshoot.
   - Example: A reddish boundary and error message explain why the connection is invalid.