>> “ds-slider.pd” is cool, also it can easly be shaped to a circle instead of square, and so on, the new [draw] is cool, but:
>> how do you send values to [ds-slider]?
>Where are the values coming from?
>> I never been into “pointers” & “data structures”.
>> Don't forget that we are trying to connect web-things to Pd, cuz Purr-Data uses>> NW.js
>> Let me know your thoughts on some [htmlcanvas] or those <iframes> that I mentioned.
>It's certainly possible to add a web page using an iframe. It could be added as html-- either about or below the svg that holds all of the patch. It could also be added as a "foreignObject" inside the svg itself, in which case it could (theoretically) have a z-order among the inner svg elements that represent the patch objects.
> However, I don't think there is browser consensus on how the latter should actually behave. I've tried to steer clear of behavior that isn'twell-documented and broadly implemented by all the important browser vendors (as in the latter case).
>Personally, I think it'd be more useful to have a patch contained/displayedwithin an html file. That's actually how patches are rendered in Purr Dataanyway. (There just doesn't happen to be much content in the html other than the svg itself.) So adding the ability to specify a different html "template" than the generic one I'm using would be a way to do that.
>Still, keep in mind I didn't design the GUI to be able to do any of this. It's been an incremental port using the tcl/tk code as a stand-in for a spec. So even adding the ability to display arbitrary html content in a patch window would probably require some careful consideration and refactoring.
>Also-- to the extent possible I'd like to keep the "Pd-land" syntax distinct from "Web-land". For example, I use a small subset of the svg specification to extend data structure drawing in Purr Data. But I do it with simple Pd atoms/messages, not with XML.