[PD] gui toolkits

[Jonathan Wilkes]

On 12/24/2014 01:35 AM, Dan Wilcox wrote:
>> On Dec 24, 2014, at 12:18 AM, pd-list-request at lists.iem.at 
>> <mailto:pd-list-request at lists.iem.at> wrote:
>>
>> 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.
>
> Actually 2 things come to mind:
>
> * Cairo <http://cairographics.org> 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.

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.)

>
> * Juce <http://www.juce.com>: 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.

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.

>
>> 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.
>
> 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.
>
> 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.

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.

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.

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".

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 
core (mouse motion, clicks, keyboard events), then you're back to what 
tcl/tk currently does.

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.

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).

-Jonathan

>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com <http://danomatika.com>
> robotcowboy.com <http://robotcowboy.com>
>
>
>
>
> _______________________________________________
> 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/20141224/5e08d93b/attachment.html>