[L2Ork-dev] GSoC: video chat follow-up

[Jonathan Wilkes]

Hi all,

Thanks to Ico for setting up the video chat this morning!

Here are some post-discussion thoughts:

For Hugo's frontend:

* The UI mockup in the current proposal looks like the best default
starting point IMO. That tab-based interface can be used to build a
maximally sophisticated Purr Data patch with all kinds of GOP
sub-patches nested in it. I can't imagine a scenario where a webapp
user building a new patch would pine for the ability to drag around
subwindows in an idiosyncratic pattern.

* For all the extant patches that depend on positioning subwindows in
an idiosyncratic pattern, we can have an option to display all the
loaded patches at once. The backend already sends information to the
GUI about window size and position. That data can be used to display
the patch svgs at the correct dimensions and positions relative to
each other in the viewport.

* It might be useful to look through the extant code in purr-data/nw
to get a sense of how many places I currently rely on nw.js methods.
At least in pdgui.js I tried to be pretty vigilant in the callbacks to
use the parameter name "nw_win" to refer to the nw.js Window object
(which in addition to other things contains the HTML5 window object).
There may be other nw.js methods in that and other files. But that
should give a good initial idea of what it would take to turn the
current codebase into a pure HTML5 webapp.

For Guillem's Encapsulation Ergonomics

* Matt mentioned the need to gain familiarity with [clone] code to get
a sense of where Miller is going with Pd Vanilla in terms of
abstractions.

* I mentioned the abstraction-related code in s_loader.c--
specifically, do_create_abstraction-- to get an idea of how
abstractions currently get loaded from file.

* Something I forgot to mention-- hoisting! If users are going to be
creating abstraction instances without reference to a pd file in the
filesystem, then whatever object they create in order to create the
"guts" of abstraction instances must get hoisted to the top of the pd
file. Currently, [declare] does hoisting so I'd suggest looking at its
code or perhaps even leveraging the declare class itself for this
feature. ([struct] and scalar-related code do hoisting, too, but those
are more experimental and less tested parts Purr Data/Pd.)

Zack's backend

* what's the current story on statically linking externals into the
Purr Data webassembly binary? (Ignoring video/3d externals like Gem
and pdp for the moment.) Keeping in mind our monstrously inhumane
build system, what would it take to wrap up all currently shipped
externals in that binary? Barring that, what about the handful of
externals in purr-data/pd/extra?

Those are my notes for now. Feedback/additions/disagreements welcome. :)

Best,
Jonathan