On 03/05/2015 01:50 PM, Dan Wilcox
wrote:
I use an abstracted API called gui_vmess that uses the same format
as pd_vmess. It sends parameters to the gui which I am currently
eval'ing in Javascript. It's not FUDI because I'm pre-formatting
the message specifically for JS's 'eval' function. But that
pre-formatting happens in a single c function that's trivial to
change later. The gui_vmess API itself should be usable by any
front-end that can understand strings, floats, and arrays.
This is incremental, so at the moment I'm massive search/replacing
all sys_vgui calls with gui_vmess. That might sound difficult-- and
it is-- but it's the only sane approach given how Pd's editing
environment works. To do otherwise would mean to understand _every_
idiosyncracy of garrays, subpatches, graph-on-parent, fonts, etc.,
meaning you'd either end up burned out or with a GUI that doesn't
support all the features Pd users have gotten comfortable with.
Thus, I don't have to have a spec for Pd in my head and can
pleasantly hit milestones. It took me about two weeks to realize I
hadn't done any work to implement the concept of subpatches, but
nonetheless they were already fully implemented and working in the
GUI. :)
The only problem I've hit is that modifying the HTML5 DOM is slow as
molasses. When you change the value for a scalar field, Pd just
erases and redraws the entire scalar. It's not very noticeable for
normal patch edition, but for a ds animation this can mean hundreds
of calls to modify the document every second. Anyway, that prompted
me to reconfigure ds drawing so that it just changes the attributes
of existing DOM elements. Now I can get GPU-acclerated ds animation
that looks as fast as any of the svg javascript frameworks I've
tried.
Anyway, here are the increments I see:
1) Change sys_vgui to gui_vmess. (In progress)
2) Refactor some functions on C side to do text edition on GUI side
in HTML5 (that's what it's good at, after all), do box hit detection
in the GUI, and simplify array/plot redrawing/resizing.
3) Think about ways to make Pd a single-window application. For a
simple example-- one could draw iemgui properties dialogs inside a
div, instead of in its own window like it I'm currently doing. I'm
not sure you could ever do _everything_ inside a single page, but
the point is that doing so makes porting to any other toolkit or
form-factor much easier.
Of course you can port Pd to IOS or Android without doing #3, but
I'd imagine it would either have much reduced functionality or be
very difficult to use.
-Jonathan