GSoC 2024 with Sugar Labs | Week 3 & 4 | Music Blocks (v4) project updates


Hi everyone, welcome to the GSoC’24 Blogs.

I am documenting my complete journey as a contributor for Google Summer of Code 2024 under Sugar Labs for the Music Blocks (v4) project – Masonry Framework.
To get more information about the project, you can read all my blogs here.

My last blog mentioned the PRD, DFD and the Tech spec , #408.

In this blog, I would like to share what I have done in the last 2 weeks and project updates.

Implementing a Dummy stack and workspace

The first issue I tackled was:

  1. When connecting two bricks (SVGs), there’s an unwanted space appearing between them.
  2. This space isn’t noticeable with just a couple of bricks, but becomes visible and problematic when stacking 10-15 bricks.
  3. The cause seems to be related to how SVG elements are positioned and how their boundaries are defined.

After discussion with the mentors, we figured that the problem might be due to:

  1. The docking point in the SVG being at a 1/2 pixel or 1/4 pixel boundary, while whole pixels are used to refer to positions.
  2. As more blocks are added, this small discrepancy accumulates, resulting in a noticeable gap.
  3. The shapes in MB3 (Music Blocks 3) having a 1/2 pixel stroke that isn’t properly accounted for in every situation.

So, I created a prototype to address that issue:

Suggested that we could have a state that stored how the brick would be connected. Whenever the bricks were ‘X’ pixels away from each other, we would get a shadow brick. When the user leaves the brick, they would snap together, just like in Blockly.

    This week, my mentor and I had an in-depth discussion about the best way to implement the bricks for our Masonry framework in Music Blocks. The core debate was whether to use SVGs or plain divs. Each approach has its own merits and challenges, and we wanted to explore these thoroughly before making a decision. The code for the prototypes is here, #409.

    1. SVG Bricks

    Pros:

    • Scalability: SVGs are vector-based and scale without losing quality, which is excellent for maintaining visual clarity.
    • Design Flexibility: SVGs can handle complex shapes and intricate designs easily.
    • Consistent Styling: SVGs ensure consistent appearance across different browsers and devices.

    Cons:

    • Complexity: Adding interactivity and handling events can be more complex compared to HTML elements.
    • Performance: SVGs with many elements can be resource-intensive.
    • Accessibility: Requires more effort to ensure accessibility.

    2. SVG Bricks with <foreignObject>

    I recommended using SVGs with <foreignObject> property as it allows us to use HTML properties in SVG.

    <div className="workspace">
          <svg
            id="workspace-svg"
            ref={svgRef}
            width="800"
            height="600"
            className="workspace-svg"
            style={{ border: '1px solid black' }}
          >
            {bricks.map(brick => (
              <g
                key={brick.id}
                className="brick"
                transform={`translate(${brick.x}, ${brick.y})`}
                onMouseDown={e => handleMouseDown(e, brick.id)}
              >
                <path d={renderBrickPath(brick.type)} fill={brick.color}></path>
                <foreignObject x="10" y="10" width="80" height="30">
                  {brick.type === 'top' && <button>Top Button</button>}
                  {brick.type === 'middle' && <input type="text" placeholder="Middle Input" />}
                  {brick.type === 'bottom' && <label>Bottom Label</label>}
                </foreignObject>
              </g>
            ))}
          </svg>
        </div>

    Pros:

    • Combining Strengths: Allows embedding HTML content inside an SVG, leveraging the interactivity of HTML and the scalability of SVG.
    • Ease of Interaction: HTML elements within <foreignObject> can be styled and scripted like normal HTML.

    Cons:

    • Browser Support: Not all browsers fully support <foreignObject>.
    • Complexity: Mixing SVG and HTML increases code complexity.
    • Performance: Potential performance issues with complex layouts.

    3. Div Bricks

    Pros:

    • Ease of Implementation: HTML elements like divs are straightforward to implement and manipulate.
    • Rich Ecosystem: HTML/CSS has a vast array of libraries and frameworks for building interactive components.
    • Accessibility: HTML elements are generally more accessible.

    Cons:

    • Scalability Issues: HTML elements are raster-based and may not scale as well as SVGs.
    • Styling Limitations: More complex designs can be harder to achieve with HTML/CSS alone.
    • Inconsistent Rendering: Different browsers may render HTML/CSS slightly differently.

        Conclusion

        After evaluating the pros and cons and considering the feedback, I’m leaning towards using SVGs with <foreignObject>. This approach seems to offer a balanced solution, combining the best features of both SVG and HTML. However, I will continue to test and refine our implementation to ensure it meets our needs.

        Next Steps

        In the coming weeks, I will be working on creating the ‘Stack tree’ for the Stack of bricks and rendering it.

        Also, don’t forget to drop a star on the project GitHub repo! ⭐
        Link: https://github.com/sugarlabs/musicblocks-v4

        You can connect with me on LinkedIn. Additionally, you can follow me on GitHub and Twitter, it will be appreciated.