Sorry, I missed this one.
try adding this lines to “pd_canvas.html” overwriting the </head>:
</head> <body class="patch_body"><div style="position: fixed; top: 0; left: 0; z-index: -1;"><iframe src="http://lucarda.com.ar/pd-tutorial" width="600" height="400"></iframe></div> > As the <div> is below and fixed position, mouse coordinates remain there and [objects] are above. But the iframe is not going down. There might be > different cases, but surely no one will want a scrollable iframe with objects above it. Sorry, I don't think I was clear here. I meant HTML that flows above/below/around the patch SVG. Putting HTML directly on top of or behind the SVG creates a complex relationship where it's difficult to predict the relationship among all the various event handlers. It is also difficult to get pixel-accurate rendering across OSes. You may be able to get that with a lot of work/care, but pixel-accurate rendering certainly isn't the strongsuit of HTML.
z-index on <div> is the ready-made [htmlcanvas] I don't know if links are operational in z-index:-1, nor what would happen if the SVG thing is done on grater z-index.
I don't, either. And that's the kind of complexity I'd like to avoid in general. Anyway, there is already [pddplink] which can open links (albeit in an external browser).
2 & 3)> default pd_canvas.html is OK, there must be an arbitrary html Open dialog. BUT/AND here is the future? Mixing html&pd? That will be cool? There's no need to save html to Pd files. An html file can instead specify the patch to be opened, in a variety of ways: (<code> tag as you mentioned, javascript API, etc.)
Of course this breaks vanilla comp. But anyone can still copy the .pd & save it to a new patch in standard .pd format.
That is one of the reasons to keep a strict separation. Just thinking about it a little, one might have something like this in their directory:fancy_view.html guts.pd
So the user would open fancy_view.html which renders a fancy web app that loads (and possibly displays) guts.pd. But you'd still be able to open guts.pd in Pd Vanilla, no problem. 4)> Why refactor? That is OK, I`m missing something? Mouse event handling, for one. And probably many other things I haven't considered for a usable, maintainable interface for something like this.
More:> I can browse local files like any browser, but I cant browse online, it just crash the window whenever I request other page than which I loaded via:
window.open("http://www.lucarda.com.ar/pd-tutorial%22,%22_self") on a new patch of course.
Try using devtools and the existing interface....
devtools seems impossible for me, crashes when saving.
Did you remove the chromium args line in package.json? -Jonathan
Salutti,> Lucarda
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, January 30, 2017 10:53 PM To: Lucas Cordiviola; Alexandre Torres Porres; pd-list@lists.iem.at Subject: Re: [PD] Purr Data rc4 > Or describe what has to be done.
May be someone reading may want to participate.
One related area is Ivica's K12 module in Pd-l2ork. That is something I haven't ported yet. It could probably be implemented using data structures, but I'd bet it would be a lot easier to just use an HTML template to display a column with a menu next to the patch. So a solution to that probably looks a lot like the solution to your feature request:1) How to add HTML above/below the Pd canvas SVG in a Pd patch. This probably requires changing some code in the mouse event handlers which currently deal with pageX and pageY coordinates. If arbitrary HTML is surrounding the SVG then we'll have to use a different way to figure out the mouse coords relative to the SVG instead of the document.2) How to use that template instead of the default pd_canvas.html template in pd/nw.3) How to create and open an arbitrary html template using the Open dialog4) How to refactor anything that currently depends on the Pd canvas SVG being the only visible element inside a patch window.
That's probably a good start.
-Jonathan