[PD] libpd separating gui from core

[Jonathan Wilkes]

On 01/13/2014 09:32 AM, Dan Wilcox wrote:
> As Hans has proposed for years, IMO this is really the only way to 
> perhaps solve the "PD gui development doesn't move fast enough" 
> problem in the long term. In this case, Miller would have the core (in 
> libpd) & the pd-vanilla wrapper gui formally separated while everyone 
> else can then use the same libpd core within other flavors. The DSP 
> core is the heart and soul and I see no reason to try and change that 
> in any way.

Sorry, I don't know quite what you're referring to here.  The only two 
examples I gave-- $@ and [initbang] wouldn't change anything in the DSP 
core.

>
> On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <jancsika at yahoo.com 
> <mailto:jancsika at yahoo.com>> wrote:
>
>> #2 is hard.  Where would you start and how would you proceed?
>
> I think what makes sense is to list out the main interfaces to the DSP 
> core that are currently being used by TCL.

I think by DSP core you're referring to:
* DSP graph stuff
* message dispatching system
* various widgetbehaviors and data structures parentwidgetbehaviors
* all the gui logic in g_editor.c
* gui queuing stuff, array selection/manipulation logic, mouse motion 
callbacks, and probably other things I'm forgetting

Is this correct?

> In the simplest case, we could literally create wrapper functions 
> which emulate the tcl argument lists. libpd currently wraps the formal 
> message sending, midi, & processing areas. I think now we need to see 
> if it's possible to wrap the DSP graph editing/manipulation, canvas, 
> patch loading/saving, etc.

I'm not clear on what libpd actually includes.  For example, does all 
the logic from g_editor remain intact?

-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140113/c7df601f/attachment.htm>