On Feb 24, 2010, at 3:54 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arnout Engelen wrote:
On Tue, Feb 23, 2010 at 07:46:32PM -0500, Ivica Ico Bukvic wrote:
Hence, I personally feel going after JUCE or Qt still allows Pd to
be as
platform-agnostic as Pd currently is (with the exception that
these are
AFAIK using GPL as opposed to BSD license)
This could be an issue: unless the new GUI would be decoupled from
Pd (which
is a bit of a muddy discussion), using a GPL GUI library would only
be allowed
well, if the new gui follows the path of the old gui, then pd-gui and
pd-core are two entirely different applications, communicating over a
network socket.
i don't think the GPL can do anything here (e.g. make all internet
explorers grabbing pages from an apache2 server violate the GPL)
personally i think the way to go is:
#1 clean up the communication between pd-core and pd-gui; (i like to
see
the pdguirewrite as a preparation for this step)
once the interface between pd and pd-gui is sufficiently clean (e.g.
no
more tcl/tk commands are sent over the wire), then you can implement
the
gui in whatever toolkit you like (and see whether it really makes a
difference)
This is definitely the way to go. pd-gui --> pd is already in the
form of Pd messages, the next step is making pd --> pd-gui pd messages
as well. I think the best path to do that would be to make a 'pd-gui'
receive symbol that mirrors the 'pd' receive symbol. All messages
sent to 'pd-gui' would be sent to the 'pd-gui' process. This could
happen now as an external, then people could start writing GUI plugins
using Pd messages as the communication. From that we can then figure
out how the rest of the communication should look.
There has been some clean up along these lines of this in the pd-gui-
rewrite branch. We have tried to structure the code so that its more
modular and ready for a pd->pd-gui API, but it could definitely be
improved a lot. For example, a handful of things that were a set of
sys_vgui() calls have been replaced by a single sys_vgui() call which
calls a Tcl proc. That Tcl proc then does the various steps.
.hc
#2 provide a mechanism so an "external" can hook into the
gui-communication (replacing sys_vgui() and friends)
this would allow to replace the current networked communication by
e,g.
a multithread-based one, which would make using shared memory and the
like a lot simpler (with the malus of not being able to run pd-core
and
pd-gui on different machines any more (think peerdata))
gmsdf
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuFkhAACgkQkX2Xpv6ydvSYQQCdHGWOWFM+tNb6YtkZ4gh10Owr
teoAnAgFmC5sV+EOC9/JmJu+At6+MgZH
=fAUS
-----END PGP SIGNATURE-----
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
