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. Even if we have 100 Ghz, native (iOS CoreGraphics, etc) will still be faster.
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.
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.
At this point, it would be great to solve this problem that preserves vanilla stability *and* provides for expanding GUI possibilities. It's totally possible and would lead to interesting stuff using libpd ... at the very least I would consider adding patch creation in PdParty.
I would be good to fold this functionality into PdDroidParty / PdParty
such that if an index.html exists in a droidparty project folder then
that will be used as the primary interface in place of the
gui-patch-faking that goes on at the moment. This will allow for much
richer user interfaces for Pd patches on mobile devices. Interested to
hear what you think of that, Dan.