Blockly: Support for custom BlockSvg tabs/notches

[trodi]

I think there is value is allowing more easily defined custom tabs/notches for rendering a Block to further increase Blockly's extensibility. Here is even an Made with Code example that overwrote the rendering to great effect.

High level pros:

• Allows for custom look/feel to an instance of Blockly (e.g., user can globally change what the value tab looks like)
• Allow visual connections to render differently based on what types are allowed to connect (increasing intuitiveness)
• Allow for custom row size (allowing for example use of larger connection pieces for younger audiences)

I've been modifying my local copy to support an alternative svg path (that is also larger than the default). In this process, I'm running across a number of helpful refactors that could take place in the BlockSvg. Are you open to refactors that would clean up the code and allow for an easier path to custom tabs/notches? Eventually it would be great to genericize this, which would take some decently sized additional modifications.

Potential steps

• refactoring to reduce function line count/increase readability
  
  
  
  • e.g., renderDrawRight is 250 lins
  
  
• BlockSvg has path constants, but they aren't always used consistently
  
  
  
  • if they were, this could allow for an initial easy way to override default svg paths (e.g., TAB_PATH_DOWN for drawRight, but inlined for drawLeft and Blockly.Connection.prototype.highlight)
  
  

• potentially the end result below could be tackled as well

  End result

• Allow the user defining a block to provide a _renderer_ of sorts which defines the required svg paths (extending the concept of block type check with visual renderer)

  • path for generating: blocklyPath and blocklyPathDark (these are the same)
  • path for generating: blocklyPathLight
  • potentially/optionally: change in paths if needed for RTL support

If you are open to it, these changes could be made over multiple pull requests with multiple contributors. I would submit some of these as time permits if merging them is a possibility. Thanks.

[thornyd]

+1
This would be amazing.

[danmilward]

This would be cool. I can't commit to helping right now due to such a busy schedule but I can confirm our application would use this. Possibly if @trodi made a good start to get the ball rolling we could chip in a day or two's worth of work.

And even then I guess it also depends on whether or not @NeilFraser would consider adding this to core. Neil what are your thoughts?

[carlosperate]

@NeilFraser Any chance this could make it as one of the 2016 changes?

[rachel-fenichel]

Hey all,

Some of the 2016 changes should have made this a lot easier. In particular, rendering is now all in block_render_svg.js, and the use of constants should be more consistent. I'm open to more cleanup and refactors there, especially with respect to removing magic numbers or turning them into constants.

Scratch-blocks has both horizontal and vertical renderers: https://github.com/LLK/scratch-blocks/blob/develop/core/block_render_svg_horizontal.js and https://github.com/LLK/scratch-blocks/blob/develop/core/block_render_svg_vertical.js, which may be a good place to start for making your own.

[joshlory]

@rachel-fenichel this is solved with the latest renderer, yeah?

🎉

[rachel-fenichel]

Almost there! It's trivial now, but we don't yet have a published API for it.

[rachel-fenichel]

Solved, and here's a codelab that walks you through customizing the renderer, including custom connection shapes.