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 Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.