best practices for multiple panels in p5?

fearless_fool

I'm creating a sketch that argues for three panels:

• a panel for graphic visualization with mouse responsive graphics,
• an inspector panel with styled HTML with clickable links,
• a status panel with readonly plain text.

I don't need to dynamically resize or reposition the panels. And though it may be short-sighted of me, I don't care if the layout of the panels is specified by p5 code or by the html / css container. Reading the documents, the github issues and the forums, it appears there are several possible approaches:

• create a single canvas and manually maintain the separate areas
• create a single canvas and carve it up with multiple divs (e.g. https://github.com/processing/p5.js/wiki/Beyond-the-canvas#creating-other-html-elements)
• create multiple canvases (e.g. http://p5js.org/reference/#/p5/createCanvas)
• create multiple p5 instances (e.g. https://github.com/processing/p5.js/issues/112)

So that I don't wander down a fruitless path, which approach is likely to minimize gnashing of teeth and maximize happiness? Even better, is there an example that does something like this?

GoToLoop

If those "panels" are independent sketches, best option is an <iframe> for each 1.

fearless_fool

Thanks for the suggestion.

The panels are not particularly independent: when I mouse over a node in the graphics window, I want to display some HTML about that node in the inspector panel.

Having said that, it might be useful if the inspector panel was in its own browser tab or window so I could use all the browser functionality to move / resize / hide the inspector. I expect that would require some form of IPC, perhaps using Redis or 0MQ. But maybe that's overkill.

blindfish

I'd opt for a canvas and two separate <div> tags for the inspector and static HTML. For the latter it's a no brainer and for the more dynamic HTML content it's still trivial to implement: JS was designed first and foremost to build DOM interaction and it's relatively trivial to pass events back and forth between HTML elements and the canvas. I suspect it would also prove more performant... And definitely no need for Redis or 0MQ!!!.