<div dir="ltr"><div>I hadn't even thought of window management, which is obviously pretty important to the way we currently patch Pd. Thanks for calling that out. And then of course it would be another matter designing an interface that would make patching easy on a touchscreen.<br><br></div><div>It would be great if we could see multiple implementations arise and use them interchangeably, but I understand there aren't enough man-hours and expertise available for everything.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 5:23 PM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div>I now have a Pd console window running on Node-Webkit, plus some menus.</div><div><br></div><div dir="ltr">The reason I chose Node-Webkit is because all of the bloat includes within it what I need to change from tcl/tk, yet still retain the same basic GUI interface (and be cross-platform). Things like creating/destroying new windows, adding and disabling menus/menuitems, etc.</div><div dir="ltr"><br></div><div dir="ltr">To have even a tiny web server one would have to change the basic design to some kind of single-window IDE where you roll your own patch windows. That could be very interesting, but it is too much work at this moment. However, I am using a sys_vgui wrapper that looks more like pd_vmess. That at least helps to get rid of explicit tcl in the c code, which could help going forward with the kind of interface you're talking about.</div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div></font></span><div><div class="h5"><div><span></span></div> <div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <font face="Arial"> On Monday, January 5, 2015 4:22 PM, Brian Fay <<a href="mailto:ovaltinevortex@gmail.com" target="_blank">ovaltinevortex@gmail.com</a>> wrote:<br> </font> </div> <br><br> <div><div><div dir="ltr"><div><div><div><div><div>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.<br><br></div>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.<br><br></div>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.<br><br></div>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?<br><br></div>This would lose the convenience of starting Pd like a native program, but it could be really cool to access it from outside devices. <br><br>Does anybody with more knowledge of Pd's internals have thoughts on the feasibility of this?<br><br></div>-Brian<br></div><div><br><div>On Thu, Jan 1, 2015 at 10:51 PM, Billy Stiltner <span dir="ltr"><<a rel="nofollow">billy.stiltner@gmail.com</a>></span> wrote:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div><br></div><div><br></div><br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
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.)<br>
<br>
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.<br>
<br>
Finally, if you continually send the relevant GUI event data to the
Pd</div></blockquote><div><br></div></span><div>does webkit provide a submilisecond setInterval()?</div><div><br></div><div>is there anyway to change how tcl/tk responds to input?</div><div><br></div><div>maybe like how in javascript instead of each cell of a table having an onClick() ,</div><div>a single loadEventHandler is used foor. </div><div>the entire table, each tcl/tk canvas is kinda like each document element in concept.</div><div>anytime user input occurs only controls that respond to that input need redrawn. how about 2 different response modes? or 3even.</div><div>1 for patch editing, 1 for performance, and another for dynamic patching?</div>
<br>_______________________________________________<br>
<a rel="nofollow">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a rel="nofollow">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div></div><br>_______________________________________________<br><a>Pd-list@lists.iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a>http://lists.puredata.info/listinfo/pd-list</a><br><br><br></div> </div> </div> </div> </div></div></div></div></blockquote></div><br></div>