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 <[email protected]> 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:
> 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
> 
>> 
>>> ---------- Forwarded message ----------
>>> From: Jonathan Wilkes <[email protected]>
>>> To: [email protected]
>>> 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
> 
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to