> Ok,

> “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't

well-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/displayed

within an html file. That's actually how patches are rendered in Purr Data

anyway. (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.

-Jonathan