Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation.
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Moving towards deken definitely makes sense.
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
I think the future of my work on something like Pd-extended would be to make a new standard library that covers lots of stuff. That was really the original idea of Pd-extended, funny enough.
.hc
On Oct 2, 2015, at 8:47 PM, Dan Wilcox wrote:
Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
hi hans,
great to hear from you!
On 2015-11-09 14:49, Hans-Christoph Steiner wrote:
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
what i would find more interesting: how hard would it be to update the PdX-core to Pd-0.47? that is, the patcheset against Pd-vanilla.
i once had a look at the PdX repository (which is based on miller's vanilla Pd), but even for PdX-0.43 the two repositories had diverged by (iirc) a few hundred commits, which makes it highly impractical to rebase/reapply/cherry-pick.
is there any meta-description available of the diffs between PdX and Pd?
fgmadsr IOhannes
On 2015-11-09 02:56 PM, IOhannes m zmoelnig wrote:
hi hans,
great to hear from you!
On 2015-11-09 14:49, Hans-Christoph Steiner wrote:
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
what i would find more interesting: how hard would it be to update the PdX-core to Pd-0.47? that is, the patcheset against Pd-vanilla.
i once had a look at the PdX repository (which is based on miller's vanilla Pd), but even for PdX-0.43 the two repositories had diverged by (iirc) a few hundred commits, which makes it highly impractical to rebase/reapply/cherry-pick.
is there any meta-description available of the diffs between PdX and Pd?
Some time ago I found and isolated a patch for the three pixel inlets and outlets, but it would be nice to have similar patches for other PdX features.
fgmadsr IOhannes
Greetings,
Fred Jan
On Nov 9, 2015, at 2:56 PM, IOhannes m zmoelnig wrote:
hi hans,
great to hear from you!
On 2015-11-09 14:49, Hans-Christoph Steiner wrote:
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
what i would find more interesting: how hard would it be to update the PdX-core to Pd-0.47? that is, the patcheset against Pd-vanilla.
i once had a look at the PdX repository (which is based on miller's vanilla Pd), but even for PdX-0.43 the two repositories had diverged by (iirc) a few hundred commits, which makes it highly impractical to rebase/reapply/cherry-pick.
is there any meta-description available of the diffs between PdX and Pd?
For a long time, I used a git workflow that kept the Pd-extended changes as a set of patches on top of vanilla, you can see that in the 'patch_series' branch. You can see that in the history. I ultimately abandoned that because there were too many commits from vanilla that I had to remove in order to keep things working. So I switched to treating vanilla as a source of patches which I included into the pd-extended master. I regularly submitted patches that didn't rely on the Pd-extended stuff to the patch tracker. Many of those were ignored for years. I have no idea the current state of them.
That workflow is documented here under "Pd-extended": https://puredata.info/docs/developer/GitWorkflows
As for syncing up Pd-extended with the latest vanilla commits, that is a manual process of reviewing them and including them. If I remember correctly, basically anything that touches an object, e.g. src/x_list.c, src/d_soundfile.c is directly accepted. The objects in extra/ actually removed from pd-extended.git, so those changes can all be ignored. I generally automatically accepted changes to the DSP core too. Stuff related to the GUI definitely needs to be carefully reviewed.
.hc
On 11/09/2015 08:44 PM, Hans-Christoph Steiner wrote:
For a long time, I used a git workflow that kept the Pd-extended changes as a set of patches on top of vanilla, you can see that in the 'patch_series' branch. You can see that in the history. I ultimately abandoned that because there were too many commits from vanilla that I had to remove in order to keep things working. So I switched to treating vanilla as a source of patches which I included into the pd-extended master. I regularly submitted patches that didn't rely on the Pd-extended stuff to the patch tracker. Many of those were ignored for years. I have no idea the current state of them.
[...]
thanks for clarification.
gmadsr IOhannes
On Nov 9, 2015, at 8:55 PM, IOhannes m zmölnig wrote:
On 11/09/2015 08:44 PM, Hans-Christoph Steiner wrote:
For a long time, I used a git workflow that kept the Pd-extended changes as a set of patches on top of vanilla, you can see that in the 'patch_series' branch. You can see that in the history. I ultimately abandoned that because there were too many commits from vanilla that I had to remove in order to keep things working. So I switched to treating vanilla as a source of patches which I included into the pd-extended master. I regularly submitted patches that didn't rely on the Pd-extended stuff to the patch tracker. Many of those were ignored for years. I have no idea the current state of them.
[...]
thanks for clarification.
The big blocker for me on merging new code from vanilla is what to do with the portaudio stuff. Pd-extended has a bunch of changes, I believe mostly from you, IOhannes. If memory serves me, there were also issues with vanilla's support of OSX audio output. The audio I/O stuff I've never really followed so well.
.hc
Right. The gui rewrite was a huge part of extended that was incorporated into vanilla. Obviously the plugin mechanism makes deken possible!
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again? There is a lot of good work that shouldn’t be lost with the transition, if possible.
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 9, 2015, at 6:49 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Moving towards deken definitely makes sense.
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
I think the future of my work on something like Pd-extended would be to make a new standard library that covers lots of stuff. That was really the original idea of Pd-extended, funny enough.
.hc
On Oct 2, 2015, at 8:47 PM, Dan Wilcox wrote:
Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Also, I wonder if the “look and feel” aspects of extended could be applied via a plugin?
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 9, 2015, at 11:10 AM, Dan Wilcox danomatika@gmail.com wrote:
Right. The gui rewrite was a huge part of extended that was incorporated into vanilla. Obviously the plugin mechanism makes deken possible!
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again? There is a lot of good work that shouldn’t be lost with the transition, if possible.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Nov 9, 2015, at 6:49 AM, Hans-Christoph Steiner <hans@at.or.at mailto:hans@at.or.at> wrote:
Moving towards deken definitely makes sense.
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
I think the future of my work on something like Pd-extended would be to make a new standard library that covers lots of stuff. That was really the original idea of Pd-extended, funny enough.
.hc
On Oct 2, 2015, at 8:47 PM, Dan Wilcox wrote:
Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev http://lists.puredata.info/listinfo/pd-dev
You can't, because the relevant canvas item options are hard-coded in C (e.g., object box outline color, xlet outline and fill color, etc.). -Jonathan
On Monday, November 9, 2015 1:13 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, I wonder if the “look and feel” aspects of extended could be applied via a plugin? -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 9, 2015, at 11:10 AM, Dan Wilcox danomatika@gmail.com wrote:
Right. The gui rewrite was a huge part of extended that was incorporated into vanilla. Obviously the plugin mechanism makes deken possible! I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again? There is a lot of good work that shouldn’t be lost with the transition, if possible. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 9, 2015, at 6:49 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Moving towards deken definitely makes sense. FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries. I think the future of my work on something like Pd-extended would be to make a new standard library that covers lots of stuff. That was really the original idea of Pd-extended, funny enough. .hc On Oct 2, 2015, at 8:47 PM, Dan Wilcox wrote:
Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote: If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
There is lot more than just box color in the Pd-extended look-n-feel. There are mouse icons, fonts, consistent sizing, differentiation of inlet/outlet types, etc.
.hc
On Nov 9, 2015, at 8:09 PM, Jonathan Wilkes wrote:
You can't, because the relevant canvas item options are hard-coded in C (e.g., object box outline color, xlet outline and fill color, etc.).
-Jonathan
On Monday, November 9, 2015 1:13 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, I wonder if the “look and feel” aspects of extended could be applied via a plugin?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 9, 2015, at 11:10 AM, Dan Wilcox danomatika@gmail.com wrote:
Right. The gui rewrite was a huge part of extended that was incorporated into vanilla. Obviously the plugin mechanism makes deken possible!
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again? There is a lot of good work that shouldn’t be lost with the transition, if possible.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 9, 2015, at 6:49 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Moving towards deken definitely makes sense.
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
I think the future of my work on something like Pd-extended would be to make a new standard library that covers lots of stuff. That was really the original idea of Pd-extended, funny enough.
.hc
On Oct 2, 2015, at 8:47 PM, Dan Wilcox wrote:
Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Only some of them, a lot of them required substantial modification.
.hc
On Nov 9, 2015, at 7:13 PM, Dan Wilcox wrote:
Also, I wonder if the “look and feel” aspects of extended could be applied via a plugin?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 9, 2015, at 11:10 AM, Dan Wilcox danomatika@gmail.com wrote:
Right. The gui rewrite was a huge part of extended that was incorporated into vanilla. Obviously the plugin mechanism makes deken possible!
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again? There is a lot of good work that shouldn’t be lost with the transition, if possible.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Nov 9, 2015, at 6:49 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Moving towards deken definitely makes sense.
FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
I think the future of my work on something like Pd-extended would be to make a new standard library that covers lots of stuff. That was really the original idea of Pd-extended, funny enough.
.hc
On Oct 2, 2015, at 8:47 PM, Dan Wilcox wrote:
Yeah, that’s what I mean. Basically so people will stop downloading an out of date extended if there is an easy way to get the same/similar functionality from a much newer version of vanilla+externals. Judging from the continued extended bug reports of things which are generally fixed in vanilla, I’m thinking it would be a good idea to see what’s needed for a transition and start that more formal conversation.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 1, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:
If by 'relative parity' you mean availability of all the externals the last version of Pd-extended came with, this might have been reached already. Search for 'extended' in deken. It shows a lot of (all?) externals directly packaged from Pd-extended. Many thanks to IOhannes for uploading all those.
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Hey Hans
Good to hear from you. Hope you're doing well.
On Mon, 2015-11-09 at 11:10 -0700, Dan Wilcox wrote:
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again?
Yeah, keeping all the work for consistent fonts is a major goal. The topic seems rather complicated.
Maybe a few words on how this was achieved in Pd-extended would be helpful already?
Roman
Roman Haefeli:
Hey Hans
Good to hear from you. Hope you're doing well.
Yes, good to hear from you too!
On Mon, 2015-11-09 at 11:10 -0700, Dan Wilcox wrote:
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again?
Yeah, keeping all the work for consistent fonts is a major goal. The topic seems rather complicated.
Maybe a few words on how this was achieved in Pd-extended would be helpful already?
Roman
Its been too long for me to give much detail, I definitely wrote about this multiple times, so check the archives. This is not a great setup, but it is necessary because pd sends drawing commands with pixel values to pd-gui. But I remember it was something like this:
* set [tk scaling 1] on all platforms * measure the boxes a lot, on various platforms and versions * fix when the pixel values are different
The real way to fix this is to make pd know as little as possible about the GUI stuff, then things can be handled much better in pd-gui. If you are going to put work into this, the best approach is also a more incremental approach. This approach will also easily give Pd a scalable GUI.
* look for any sys_vgui() call in pd that sends raw Tcl * convert this to a pd message one at a time * push the logic to pd-gui as much as possible
For example, take src/g_vumeter.c. The drawing should all happen in Tcl/pd-gui. Pd should just send the values to be drawn. Same goes with g_array.c.
.hc
- convert this to a pd message one at a time
If anyone wants some advice on how to do this in practice, PM me. -Jonathan
On Tuesday, November 10, 2015 10:01 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Roman Haefeli:
Hey Hans
Good to hear from you. Hope you're doing well.
Yes, good to hear from you too!
On Mon, 2015-11-09 at 11:10 -0700, Dan Wilcox wrote:
I’d like to find a way to bring in the consistent font sizing in as well as the help patches Jonathan updated. Maybe worth bringing up again?
Yeah, keeping all the work for consistent fonts is a major goal. The topic seems rather complicated.
Maybe a few words on how this was achieved in Pd-extended would be helpful already?
Roman
Its been too long for me to give much detail, I definitely wrote about this multiple times, so check the archives. This is not a great setup, but it is necessary because pd sends drawing commands with pixel values to pd-gui. But I remember it was something like this:
* set [tk scaling 1] on all platforms * measure the boxes a lot, on various platforms and versions * fix when the pixel values are different
The real way to fix this is to make pd know as little as possible about the GUI stuff, then things can be handled much better in pd-gui. If you are going to put work into this, the best approach is also a more incremental approach. This approach will also easily give Pd a scalable GUI.
* look for any sys_vgui() call in pd that sends raw Tcl * convert this to a pd message one at a time * push the logic to pd-gui as much as possible
For example, take src/g_vumeter.c. The drawing should all happen in Tcl/pd-gui. Pd should just send the values to be drawn. Same goes with g_array.c.
.hc
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, Nov 10, 2015, at 07:53 PM, Jonathan Wilkes via Pd-dev wrote:
- convert this to a pd message one at a time
If anyone wants some advice on how to do this in practice, PM me. -Jonathan
On Tuesday, November 10, 2015 10:01 AM, Hans-Christoph Steiner <hans@at.or.at> wrote:Its been too long for me to give much detail, I definitely wrote about this multiple times, so check the archives. This is not a great setup, but it is necessary because pd sends drawing commands with pixel values to pd-gui. But I remember it was something like this:
- set [tk scaling 1] on all platforms
- measure the boxes a lot, on various platforms and versions
- fix when the pixel values are different
The real way to fix this is to make pd know as little as possible about the GUI stuff, then things can be handled much better in pd-gui. If you are going to put work into this, the best approach is also a more incremental approach. This approach will also easily give Pd a scalable GUI.
- look for any sys_vgui() call in pd that sends raw Tcl
- convert this to a pd message one at a time
- push the logic to pd-gui as much as possible
Hi Jonathan, and everyone else!
I would be interested in working on the gui stuff. I was just trying to do some theming and tried applying the color scheme part of pd-extended as a patch to vanilla. It kind of worked, but it was just a first attempt. Anyway, I would very much like to do more of this, so please give me some hints.
Scaling would be awesome.
/Kaj Ailomaa
On Sun, Jan 10, 2016, at 11:59 AM, Kaj Ailomaa wrote:
On Tue, Nov 10, 2015, at 07:53 PM, Jonathan Wilkes via Pd-dev wrote:
- convert this to a pd message one at a time
If anyone wants some advice on how to do this in practice, PM me. -Jonathan
On Tuesday, November 10, 2015 10:01 AM, Hans-Christoph Steiner <hans@at.or.at> wrote:Its been too long for me to give much detail, I definitely wrote about this multiple times, so check the archives. This is not a great setup, but it is necessary because pd sends drawing commands with pixel values to pd-gui. But I remember it was something like this:
- set [tk scaling 1] on all platforms
- measure the boxes a lot, on various platforms and versions
- fix when the pixel values are different
The real way to fix this is to make pd know as little as possible about the GUI stuff, then things can be handled much better in pd-gui. If you are going to put work into this, the best approach is also a more incremental approach. This approach will also easily give Pd a scalable GUI.
- look for any sys_vgui() call in pd that sends raw Tcl
- convert this to a pd message one at a time
- push the logic to pd-gui as much as possible
Hi Jonathan, and everyone else!
I would be interested in working on the gui stuff. I was just trying to do some theming and tried applying the color scheme part of pd-extended as a patch to vanilla. It kind of worked, but it was just a first attempt. Anyway, I would very much like to do more of this, so please give me some hints.
Scaling would be awesome.
/Kaj Ailomaa
I was looking for an example (using grep) where sys_vgui() sends pd messages instead of tcl commands to find an example, and this was pretty much it:
./s_print.c: sys_vgui("::pdwindow::post {%s}\n", strnescape(upbuf, s, MAXPDSTRING)); ./s_print.c: sys_vgui("::pdwindow::logpost {%s} 1 {%s}\n", ./s_print.c: sys_vgui("::pdwindow::logpost {%s} %d {%s}\n",
So, that looks easy enough. But, I still have very loose grasp on everything to do with pd programming. So, there's really a lot for me to understand. I will need to have a look at pd messages, which ones I should use, and if I need to create new ones. Also, how do I actually create an object in the correct patch window using tcl. An example of this would be nice, and would allow for me to do some work right away - at least for testing and getting better acquainted with the code.
/Kaj
Hi Kaj,In the GUI port of Pd-l2ork I have about 18 sys_vgui calls left to revise. At that point the tcl strings will be completely removed from the core of Pd-l2ork. In practice, it's not really a process of changing tcl calls to pd message calls. Tcl strings are more expressive than pd messages-- they allow you to specify arbitrary strings (e.g., the string may have spaces inside it) and (nested) lists of values. Since the current code relies on those two features to communicate with the GUI, porting everything to a less expressive message format is a really bad idea. You'll either end up jumping through hoops to deal with all the edge cases, or coming up with your own syntax for strings containing arbitrary characters and list/array boundaries (at which they are no longer Pd messages). I used pd_vmess as a model and just parameterized the messages to the GUI. That means I have only a handful of functions in one place where I can choose exactly how the commands look when they get sent over the wire. That way even if I chose the worst possible design, fixing it is just a matter of changing the guts of those few functions instead of having to refactor every single call to the gui throughout all of the core. -Jonathan
On Monday, January 11, 2016 6:08 AM, Kaj Ailomaa zequence@mousike.me wrote:
On Sun, Jan 10, 2016, at 11:59 AM, Kaj Ailomaa wrote:
On Tue, Nov 10, 2015, at 07:53 PM, Jonathan Wilkes via Pd-dev wrote:
- convert this to a pd message one at a time
If anyone wants some advice on how to do this in practice, PM me. -Jonathan
On Tuesday, November 10, 2015 10:01 AM, Hans-Christoph Steiner hans@at.or.at wrote: Its been too long for me to give much detail, I definitely wrote about this multiple times, so check the archives. This is not a great setup, but it is necessary because pd sends drawing commands with pixel values to pd-gui. But I remember it was something like this:
- set [tk scaling 1] on all platforms
- measure the boxes a lot, on various platforms and versions
- fix when the pixel values are different
The real way to fix this is to make pd know as little as possible about the GUI stuff, then things can be handled much better in pd-gui. If you are going to put work into this, the best approach is also a more incremental approach. This approach will also easily give Pd a scalable GUI.
- look for any sys_vgui() call in pd that sends raw Tcl
- convert this to a pd message one at a time
- push the logic to pd-gui as much as possible
Hi Jonathan, and everyone else!
I would be interested in working on the gui stuff. I was just trying to do some theming and tried applying the color scheme part of pd-extended as a patch to vanilla. It kind of worked, but it was just a first attempt. Anyway, I would very much like to do more of this, so please give me some hints.
Scaling would be awesome.
/Kaj Ailomaa
I was looking for an example (using grep) where sys_vgui() sends pd messages instead of tcl commands to find an example, and this was pretty much it:
./s_print.c: sys_vgui("::pdwindow::post {%s}\n", strnescape(upbuf, s, MAXPDSTRING)); ./s_print.c: sys_vgui("::pdwindow::logpost {%s} 1 {%s}\n", ./s_print.c: sys_vgui("::pdwindow::logpost {%s} %d {%s}\n",
So, that looks easy enough. But, I still have very loose grasp on everything to do with pd programming. So, there's really a lot for me to understand. I will need to have a look at pd messages, which ones I should use, and if I need to create new ones. Also, how do I actually create an object in the correct patch window using tcl. An example of this would be nice, and would allow for me to do some work right away - at least for testing and getting better acquainted with the code.
/Kaj
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
On Mon, Jan 11, 2016, at 08:30 PM, Jonathan Wilkes wrote:
Hi Kaj,In the GUI port of Pd-l2ork I have about 18 sys_vgui calls left to revise. At that point the tcl strings will be completely removed from the core of Pd-l2ork. In practice, it's not really a process of changing tcl calls to pd message calls. Tcl strings are more expressive than pd messages-- they allow you to specify arbitrary strings (e.g., the string may have spaces inside it) and (nested) lists of values. Since the current code relies on those two features to communicate with the GUI, porting everything to a less expressive message format is a really bad idea. You'll either end up jumping through hoops to deal with all the edge cases, or coming up with your own syntax for strings containing arbitrary characters and list/array boundaries (at which they are no longer Pd messages). I used pd_vmess as a model and just parameterized the messages to the GUI. That means I have only a handful of functions in one place where I can choose exactly how the commands look when they get sent over the wire. That way even if I chose the worst possible design, fixing it is just a matter of changing the guts of those few functions instead of having to refactor every single call to the gui throughout all of the core. -Jonathan
Wow. Been a while since I tried pd-l2ork. A little tough to install on anything except Ubuntu. The deb installer has build dependencies as regular dependencies, and on Debian I was unable to install all of them, so I had to force it.
The gui is really quick and responsive. And, I noticed the gui coloring is all configurable. Pretty scrollbars, a html like help browser, etc. The whole thing seems to be based on -extended, which is what I used for many years - mostly because of the look, and initbang(while I hadn't worked out other solutions yet).
I'll put some time in studying the code, as there seems to be some clues to the problems there (both in how they are solved, and why they are not solved that way in vanilla - I'm assuming). I'll resurface once I have something new to add :).
Thanks Jonathan!
-
Dan Wilcox -
Fred Jan Kraan -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Kaj Ailomaa -
Roman Haefeli