[PD] Browser UIs for vanilla Pd patches

[Chris McCormick]

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.

-- 
http://mccormick.cx/