<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/24/2014 01:35 AM, Dan Wilcox
wrote:<br>
</div>
<blockquote
cite="mid:BA53BC1D-B46A-4821-945F-8909E8F1BCE9@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="">
<blockquote type="cite" class="">
<div class="">On Dec 24, 2014, at 12:18 AM, <a
moz-do-not-send="true"
href="mailto:pd-list-request@lists.iem.at" class="">pd-list-request@lists.iem.at</a>
wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span class="" style="font-family:
HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida
Grande', sans-serif; font-size: 16px; background-color:
rgb(255, 255, 255); float: none; display: inline
!important;">Of course if someone with the knowledge and
energy to do this the "right way" has any suggestions, I'm
all ears. I have the inkling that if I could employ a
full-time dev to do my bidding then Qt Quick would the
"right way" to go-- it's in Debian, is cross-platform,
well-documented, and it certainly has enough features for
Pd's canvas editing. </span></div>
</blockquote>
<br class="">
</div>
Actually 2 things come to mind:
<div class=""><br class="">
</div>
<div class="">* <a moz-do-not-send="true"
href="http://cairographics.org" class="">Cairo</a> for
rendering and something else like QT or a layer below tk for the
chrome. We use cairo for pdf rendering in OpenFrameworks, among
a few other things.</div>
</blockquote>
<br>
Last time I looked I didn't see any maintained bridges between tk
and Qt. tkpath uses Cairo to actually draw the vector graphics,
but... you're still using tk which turns out to be the bottleneck.
(And tkpath is abandon-ware, unfortunately.)<br>
<br>
<blockquote
cite="mid:BA53BC1D-B46A-4821-945F-8909E8F1BCE9@gmail.com"
type="cite">
<div class=""><br class="">
</div>
<div class="">* <a moz-do-not-send="true"
href="http://www.juce.com" class="">Juce</a>: It’s aimed at
audio, cross platform, and Max has used it since Max 5. I used
it at one place I worked and it can do quite alot actually.</div>
</blockquote>
<br>
Cross-platform is good. Unfortunately, it isn't a big benefit that
Max uses it because Max doesn't provide any documentation or code
for us to follow in a potential port. I think Qt has a larger
userbase and more docs so I prefer it, but I know Juce has a lot of
fans.<br>
<br>
<blockquote
cite="mid:BA53BC1D-B46A-4821-945F-8909E8F1BCE9@gmail.com"
type="cite">
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class=""><span style="font-family:
HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida
Grande', sans-serif; font-size: 16px; background-color:
rgb(255, 255, 255);" class="">But I don't know how to
retrofit a c program like Pd with Qt, nor how to replace
Pd's current string-based communication with whatever one is
supposed to use to do that.</span></blockquote>
</div>
<div class=""><br class="">
</div>
<div class="">I guess you don’t really retrofit the existing Pd,
but rebuild it. Chris and I have done this with DroidParty &
PdParty to some small degree using libpd. Sending messages and
samples to and from the dsp engine is working. If that could be
expanded to the requisite GUI calls, then bringing patch editing
could be next. libpd currently has “sendFloat”, “sendSymbol”
etc, off the top of my head we could add something like
“createCanvas” which returns a canvas pointer, etc. In the case
of libpd, you don’t communicate with the dsp engine over a
socket but by function calls. Obviously you could use a socket
and pass data along from a separate GUI which then calls the
functions.</div>
<div class=""><br class="">
</div>
<div class="">I’m just musing here that it’d be nice to abstract
the dsp graph, canvas, etc within libpd. That would at least
make it possible to support patch creation and editing in
PdParty, etc without rolling something myself. If did have to,
I’d rather do it in a generic way inside libpd so Chris could
use it DroidParty or I could add it to ofxPd, etc.</div>
</blockquote>
<br>
Well, let's take Qt. matju actually added some code to Pd-l2ork to
start a Qt gui in a separate thread. He did it by adding to Pd's
extant makefile and source. It successfully runs and creates a Qt
window with some menus. But any time I try to add a Qt lib I get a
segfault. All of Qt's docs assume either that I'm using QtCreator
or that I have c++ business logic, so I'm a bit stuck.<br>
<br>
Presumably I'd want to create a project in QtCreator for the GUI.
libpd has hooks for C++ so I suppose I can import that into the
project somehow. But then I also need to have a separate thread for
libpd than the GUI, and a new mechanism similar to sys_vgui or vmess
to move data back and forth between GUI thread and Pd "core" thread.<br>
<br>
However, this is where it gets tricky. There are cases where Pd
needs to use the getrect function or other coordinate data in the
course of calculating a depth-first object chain, a block, or
possibly both ([cnv] "get_pos", [inlet], data structures, some
externals). There are also cases where the user programmatically
change coordinate data for such objects, including iemguis with
"delta" and "pos".<br>
<br>
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 core (mouse motion, clicks, keyboard events), then you're back to
what tcl/tk currently does.<br>
<br>
I know Desiredata essentially made a copy of the patch structure on
the tcl/tk side and then attempted to keep both the "client" (GUI)
and "server" (Pd core) synchronized. That seems to me to be rather
complicated and prone to error.<br>
<br>
So what do you see as a workable solution to Qt + libpd with this in
mind? The only path I see is to incrementally move from tcl/tk to
the other toolkit, and then when it's working clean up the g_*.c
code so that the gui toolkit can take over more responsibilities
(like text editing).<br>
<br>
-Jonathan<br>
<br>
<blockquote
cite="mid:BA53BC1D-B46A-4821-945F-8909E8F1BCE9@gmail.com"
type="cite">
<div class=""><br class="">
<div class="">
--------<br class="">
Dan Wilcox<br class="">
@danomatika<br class="">
<a moz-do-not-send="true" href="http://danomatika.com"
class="">danomatika.com</a><br class="">
<div class=""><a moz-do-not-send="true"
href="http://robotcowboy.com" class="">robotcowboy.com</a></div>
</div>
<div><br class="">
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>