[PD] gui toolkits

[Antoine Villeret]

my 2 cent : accessing Pd from remote computer is already possible thanks to
SSH X-forwarding and I do think this feature should be preserved in any new
GUI which intends to replace the actual one.
Also there are some other ways to do what we could call MVC
(model-view-control [1]) with Pd. And the most serious pretender is
certainly Jamoma[2], which will be available in Pd in 2015 (at least, this
is one of my new year's resolution :-) )

best

antoine

[1] : http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[2] : http://jamoma.org/

--
do it yourself
http://antoine.villeret.free.fr

2015-01-05 22:19 GMT+01:00 Brian Fay <ovaltinevortex at gmail.com>:

> One thing I really like about a web technology-based interface is the idea
> that maybe the computer running Pd and the computer accessing the interface
> wouldn't necessarily have to be the same computer.
>
> I'm imagining running Pd on a small single-board computer, and
> patching/interacting with it on a tablet or a phone or a laptop, connecting
> over an ad-hoc wireless network.
>
> Node-webkit from my understanding is really only intended to run locally,
> as if it were a native application. It includes an implementation of a web
> browser so that it can run, and that is where the ~100MB bloat comes from.
>
> Maybe instead of relying on node-webkit we could write our own tiny node
> server, and have users jump into their favorite web browsers to access the
> interface?
>
> This would lose the convenience of starting Pd like a native program, but
> it could be really cool to access it from outside devices.
>
> Does anybody with more knowledge of Pd's internals have thoughts on the
> feasibility of this?
>
> -Brian
>
> On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner <billy.stiltner at gmail.com>
> wrote:
>
>>
>>
>>
>> If GUI manipulation happens only in the GUI thread (i.e., we completely
>>> separate Pd into GUI thread and audio/message thread), a patch currently
>>> using [cnv] "get_pos" method for a crude control surface will break.  This
>>> is because the coordinate data is only being updated on the GUI side, and
>>> not reported back to the "core".  (Even if the core updates the GUI with
>>> programmatic coordinate changes.)
>>>
>>> If, on the other hand, the "core" is changed so that it queries the GUI
>>> to get coordinate data (for example), you either must block until the GUI
>>> returns-- which is bad-- or query ansynchrously which breaks determinism--
>>> which is worse.
>>>
>>> Finally, if you continually send the relevant GUI event data to the Pd
>>>
>>
>> does webkit provide a submilisecond setInterval()?
>>
>> is there anyway to change how tcl/tk responds to input?
>>
>> maybe like how in javascript instead of each cell of a table having an
>> onClick() ,
>> a single loadEventHandler is used foor.
>> the entire table, each tcl/tk canvas is kinda like each document element
>> in concept.
>> anytime user input occurs only controls that respond to that input need
>> redrawn. how about 2 different response modes? or 3even.
>> 1 for patch editing, 1 for performance, and another for dynamic patching?
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150105/a2532da5/attachment-0001.html>