[PD] Re: PD-list digest, Vol 1 #789 - 3 msgs
tzahm at punkass.com
tzahm at punkass.com
Sun Nov 23 11:50:40 CET 2003
I also think that segmented patch cords and a way to know what each
inlet/outlet stands for should have a higher priority than moving to
another gui toolkit. Adding the option to group-assign color to
message/object/number boxes should not be too difficult and probably
would help readability.
::: sam :::
> Date: Sat, 22 Nov 2003 23:52:36 -0500
> From: Michal Seta <mis at creazone.32k.org>
> Subject: Re: [PD] about pd's gui
> To: pd-list at iem.at
>
> On Sat, 2003-11-22 at 19:46, Jerome Etienne wrote:
>
>> pd is a graphical language, so a nice gui isn't a luxury.
>
> Isn't adding 'niceties' to existing, working products a luxury?
>
>> it provide good readability, which improve the developpement
>> time and even more the maintenance time.
>
> I don't think that 'nice' will accomplish the above. But I would opt
> for more functional. Segmented patch cords would be welcome (although
> I
> have learnt to live with the way they are now) and inlet/outlet hints
> would be a nice aid. I don't see the need to put a lot effort into
> porting the gui into some fashionable graphical toolkit. Adding some
> resources should probably be easier and more intelligent.
>
> As per GUI frontends to patches, the possibilities are already there:
> GriPD, python extern (and through python you can use wxWindows, QT,
> GTK,
> SDL, tk, etc), and, of course, writing a separate frontend in _any_
> language and communicating via tcp/ip or OSC, or MIDI.
More information about the Pd-list
mailing list