Sounds like a simple enough abstraction. Maybe this is something we can add to libpd.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Mar 5, 2015, at 6:18 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
On 03/05/2015 01:50 PM, Dan Wilcox wrote:
Sounds good. How are you handling getting the object graph info into and out of the pd core? I might be able to add patch display/editing on iOS ...
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:
- Change sys_vgui to gui_vmess. (In progress)
- 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.
- 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
---------- Forwarded message ---------- From: Jonathan Wilkes jancsika@yahoo.com To: pd-list@lists.iem.at Cc: Date: Tue, 03 Mar 2015 17:15:10 -0500 Subject: Re: [PD] Updating Pd-Extended On 03/03/2015 10:42 AM, João Pais wrote:
I can't do anything active (i.e. edit scripts, etc), but I could follow instructions - in case they're clear, and correct.
I'm making progress on the port of the GUI from Tk to Node-Webkit (or nw.js as its now called). I've got the iemgui properties dialogs finished, plus some basic internationalization.
There is still a lot of development left to do, but already I can run patches, open/close subpatches, display data structures and interact with iemguis. Once it has feature parity with Tk it will essentially be a replacement for Pd-Extended for Linux, OSX, and Windows (7 and beyond).
What version of Windows are you using these days? It looks like going forward nw.js will only compile on 64-bit versions of Windows, but it currently has 32-bit binaries.
-Jonathan
-- Dan Wilcox @danomatika danomatika.com robotcowboy.com