[PD-dev] seeking advice on Pd gui overhaul

[András Murányi]

On Wed, Mar 3, 2010 at 12:30 AM, Jeff Mann <jeff at jeffmann.com> wrote:

> [...]
>
> 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.
>
> 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.
>
> Thanks!
>

Just the minimum 2 cents as i am not a 'stakeholder' or power user or
anything.
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)
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.
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).
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.

Andras
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20100303/14cb38e4/attachment.htm>