On 20/03/18 05:29, Dan Wilcox wrote:
The "GUI faking" works at the moment and it's fast. I'm less inclined to believe adding a webbrowser layer and in-app socket communication is going to be performant on mobile devices.
There's no need to add in-app socket communication. The "server" runs inside Pd itself.
The change to the app would look like this in psuedo-code:
if "index.html" in patch folder: instantiate WKWebView with index.html loaded else: instantiate existing pd[droid]party GUI view
The existing Pd[Droid]Party apps would function exactly as they do now, except for the additional option of using a webkit window in place of the existing patch viewer.
Even if we have 100 Ghz, native (iOS CoreGraphics, etc) will still be faster.
That's true.
A Pd person might be willing to make the trade-off, taking a performance hit for the superpower of rich web based user interfaces. I like the idea of people having that option and I don't think it detracts from anything in the existing Pd ecosystem.
What I *really* want is to simply ditch the GUI implementations and receive drawing commands directly from Pd. It could be "line here, rectangle there, text here" as it is now or it could be higher level as in "toggle here, object there" etc. If there was an abstraction layer replacing the TCL (maybe it looks/works like TCL in the end) wrapping the GUI, it would simply be easier to let Pd itself handle the logic and we just feed it input events.
This would indeed be great. I remember people discussing this at PdCon16.
It's orthogonal to what I'm suggesting though. I'm not suggesting to render patches in a browser view. I'm suggesting to give the user the option to have a browser view in which to build their own rich UIs, which might look completely different to the Pd patch view.
No matter how fancy you make the boxes look there are always going to be things you can't do with only boxes and lines. Building completely new types of interface widgets becomes much simpler if you have the full expressive power of a web browser window at your disposal.
I know the Purr Data team have worked this out, so maybe we can look at there model or think of something at a different level. I have some ideas and, after having dug into the GUI code to fix zooming/sizing, I know there isn't really that much raw drawing TCL in the core. And most of what's there is pretty simple and repetitive.
They have done amazing work and so have you.
At this point, it would be great to solve this problem that preserves vanilla stability *and* provides for expanding GUI possibilities.
The patch I posted is only using [netreceive] - so far I haven't run into any stability issues and the GUI possibilities are already vastly expanded. :)
It's totally possible and would lead to interesting stuff using libpd ... at the very least I would consider adding patch creation in PdParty.
Sounds fun! I can imagine Blockly working well for patching on mobile devices:
https://developers.google.com/blockly/
Chris.