<div class="gmail_quote">On Wed, Mar 3, 2010 at 12:30 AM, Jeff Mann <span dir="ltr"><<a href="mailto:jeff@jeffmann.com">jeff@jeffmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[...]<br>
<br>
Having said that, I understand that the first step would really need to be a cleaner interface between pd-core and pd-gui. From what I've read, there's a lot of drawing stuff going on inside pd-core that really expects to be working with tcl/tk. It doesn't seem to make sense to go ahead with a non-tcl/tk gui before this is sorted out. So, if people have programming energy to contribute, maybe that's a good starting point. Another advantage to that is to reduce the load and improve the ability to run pd-core on small "headless" processors, communicating with pd-gui over a network.<br>
<br>
I don't know if any of this is particularly relevant or useful to anyone else, since my use-case is perhaps not so common. But I thought I'd just throw it into the ring for consideration.<br>
<br>
Thanks!<br><font color="#888888">
</font></blockquote><div> <br>Just the minimum 2 cents as i am not a 'stakeholder' or power user or anything.<br>Making the separation between the server and the client seems to be a very good idea and one of the next steps for pd to take. It seems that no one is even arguing it, and if really not, we can soon take it agreed. (Rien ne va plus...? ;o)<br>
When we arrive to having an API, it will be easy to make up GUIs in different programming languages based on different GUI libraries. The question is, would the makers of the 'official' GUI be willing to make the switch or they'd rather continue with a Tcl/Tk one? I wouldn't be surprised by either choice, but i think the earlier we know about this, the better we can plan for the future.<br>
I don't know much about desktop application development, but i have a clue that using any of the beforementioned GUI kits we will have to write up our own canvas widget which will take much part of the overall process. (Even more that it seems the GUI will have to take over some of the tasks that are currently done by the C backend). I would also like to ask whether people who are familiar with these *fast* GUI kits are confident that the canvas widget that we make up will be *fast* enough too. (I am sort of familiar with the problems of the Xara X graphics program which is written with the fast WX kit but the tumbling block is that single canvas object which had been written *into* WX and which is very fast but copyrighted, and no one sees a way to write up a similarly *fast* one). <br>
It was also mentioned if the client and the server shall be linked (at compile time). I'd suggest not, but there may be need for API versioning - something like Jack has. So we don't have to work out *the* perfect API *before* we could start using it, but some evolution with time is allowed.<br>
<br>Andras<br>
</div></div>