Hey all,
Now with Pd-0.39.3-extended finally out, I'd like to talk about setting the timetable for the next Pd-extended release. I think it's a good idea to set a code freeze/branch date at the end of the year. Then spend one month on release candidates, and aim to have a final release in the beginning of February.
Hopefully, we can work together to get things more integrated and polished, and make the next version much better than this one. :D
.hc
------------------------------------------------------------------------ ----
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/mtx_*~ and so on (though I believe IOhannes may have fixed that recently?). Oh, it would also be cool to get the OS X sysex-enabling patches and IOhannes' $@/$# patches in by then... I did some work on that last week - the sysex patch worked mostly without issue but I couldn't get the $@ patch to apply.
On 10/22/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey all,
Now with Pd-0.39.3-extended finally out, I'd like to talk about setting the timetable for the next Pd-extended release. I think it's a good idea to set a code freeze/branch date at the end of the year. Then spend one month on release candidates, and aim to have a final release in the beginning of February.
Hopefully, we can work together to get things more integrated and polished, and make the next version much better than this one. :D
.hc
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Oct 22, 2007, at 4:45 PM, Luke Iannini (pd) wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
Oh, it would also be cool to get the OS X sysex-enabling patches and IOhannes' $@/$# patches in by then... I did some work on that last week - the sysex patch worked mostly without issue but I couldn't get the $@ patch to apply.
Patches to pd/src can be added to packages/patches, then they'll be automatically included. But they have to get along with the rest of the patches that are in that folder.
.hc
On 10/22/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey all,
Now with Pd-0.39.3-extended finally out, I'd like to talk about setting the timetable for the next Pd-extended release. I think it's a good idea to set a code freeze/branch date at the end of the year. Then spend one month on release candidates, and aim to have a final release in the beginning of February.
Hopefully, we can work together to get things more integrated and polished, and make the next version much better than this one. :D
.hc
--
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is
exactly the same: http://sourceforge.net/tracker/index.php?func=detail&aid=1650752&gro... Can this be reopened or should I submit a new one?
Cheers Luke
On Oct 23, 2007, at 7:05 PM, Luke Iannini (pd) wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker/index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
Can you post a screenshot? That is most likely caused by trouble with the fonts. A number of GNU/Linux users have had font troubles. Which platform are you on? If GNU/Linux, do you have Bitstream Vera Sans Mono installed?
.hc
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the
extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is
exactly the same: http://sourceforge.net/tracker /index.php?func=detail&aid =1650752&group_id=55736&atid=478070 http://sourceforge.net/tracker/index.php?func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
------------------------------------------------------------------------ ----
kill your television
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3, argc, argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You're right. It looks like it's using regular Bitstream Vera Sans rather than Mono?I have this line in my .pdrc -font-face "Bitstream Vera Sans Mono" Is that correct?
Also, Pd-Extended defaults to Monaco on OS X, which is included, but I don't like it since it is not anti-aliased (I posted about that elsewhere).
On 10/23/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3, argc,argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info
/listinfo/pd-list
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I guess that is not correct, since it changes to the same font no matter what I put there. I do have Bitstream Vera Sans Mono installed.
On 10/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
You're right. It looks like it's using regular Bitstream Vera Sans rather than Mono?I have this line in my .pdrc -font-face "Bitstream Vera Sans Mono" Is that correct?
Also, Pd-Extended defaults to Monaco on OS X, which is included, but I don't like it since it is not anti-aliased (I posted about that elsewhere).
On 10/23/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3, argc,argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info
/listinfo/pd-list
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Drat, we need some way to list the available fonts by the appropriate names so that Tk will find them. I don't know a simple way to do that at the moment!
M
On Tue, Oct 23, 2007 at 06:10:24PM -0700, Luke Iannini (pd) wrote:
I guess that is not correct, since it changes to the same font no matter what I put there. I do have Bitstream Vera Sans Mono installed.
On 10/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote:
You're right. It looks like it's using regular Bitstream Vera Sans rather than Mono?I have this line in my .pdrc -font-face "Bitstream Vera Sans Mono" Is that correct?
Also, Pd-Extended defaults to Monaco on OS X, which is included, but I don't like it since it is not anti-aliased (I posted about that elsewhere).
On 10/23/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3, argc,argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info
/listinfo/pd-list
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 23 Oct 2007, Miller Puckette wrote:
Drat, we need some way to list the available fonts by the appropriate names so that Tk will find them. I don't know a simple way to do that at the moment!
Dude.
You'd find it in "def FontDialog init", if you bothered to look there.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wed, 24 Oct 2007, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Miller Puckette wrote:
Drat, we need some way to list the available fonts by the appropriate names so that Tk will find them. I don't know a simple way to do that at the moment!
Dude. You'd find it in "def FontDialog init", if you bothered to look there.
I didn't want to look that pissed, but I sure did anyway.
What I want to say is that a lot of problems of PureData have already been solved in DesireData, and for something of the order of one line of code, you can't possibly have copyright/licensing problems if you just copy it.
I don't really need to do anything to keep any potential competitive advantage of DesireData. The main protection I have is some people's unwillingness to grep the source code.
I'm saying that in the interest of everybody. Now if I only had a consistent work schedule for DesireData instead of orbiting around the rest of the work that is left to be done... this issue could be moot.
My 2.07 cents.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Ben Bogart had this problem as well, basically the font wasn't recognized by the system. Can you use that font in anything?
I think he solved it by reinstalling x-ttcidfont-conf. On a Debian- esque machine, you do this:
apt-get install --reinstall x-ttcidfont-conf
.hc
On Oct 23, 2007, at 9:10 PM, Luke Iannini (pd) wrote:
I guess that is not correct, since it changes to the same font no matter what I put there. I do have Bitstream Vera Sans Mono installed.
On 10/23/07, Luke Iannini (pd) lukexipd@gmail.com wrote: You're right. It looks like it's using regular Bitstream Vera Sans rather than Mono? I have this line in my .pdrc -font-face "Bitstream Vera Sans Mono" Is that correct?
Also, Pd-Extended defaults to Monaco on OS X, which is included, but I don't like it since it is not anti-aliased (I posted about that elsewhere).
On 10/23/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote: The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3,argc, argv); sys_fontlist[i].fi _height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) < lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group _id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Monaco is anti-aliased on bigger sizes, at least on the machines I've tested on. I attached an example.
 .hc
On Oct 23, 2007, at 8:51 PM, Luke Iannini (pd) wrote:
You're right. It looks like it's using regular Bitstream Vera Sans rather than Mono? I have this line in my .pdrc -font-face "Bitstream Vera Sans Mono" Is that correct?
Also, Pd-Extended defaults to Monaco on OS X, which is included, but I don't like it since it is not anti-aliased (I posted about that elsewhere).
On 10/23/07, Miller Puckette mpuckett@imusic1.ucsd.edu wrote: The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3,argc, argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
Here's my analysis of this:
We want to have patches be laid out the exact same on all platforms, pixel-by-pixel. This is necessary to have decent GUI layouts that work. Part of this is having the box sizes be the same. If you can get the code to use the automatic sizing, and produce boxes with the same exact size on all platforms, that's fine by me.
I personally think that having the sizes the exact same was worth installing the font, and dealing with making sure the fonts are working.
When a font doesn't work properly in an OS, like with Luke's problem, that's not a problem we should try to deal with in Pd. We should help people fix that problem on their OS.
It might be a better solution to have the box sizes fixed, then use the text measuring so that the cursor goes into the right place, no matter what the font situation is.
An even nicer solution would be to have the font face, font size, and box sizes saved in the patch. Then each OS could draw it the same. But then people with missing or broken fonts will still have troubles.
.hc
On Oct 23, 2007, at 8:25 PM, Miller Puckette wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3,argc, argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
------------------------------------------------------------------------ ----
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
cheers Miller
On Tue, Oct 23, 2007 at 10:27:21PM -0400, Hans-Christoph Steiner wrote:
Here's my analysis of this:
We want to have patches be laid out the exact same on all platforms, pixel-by-pixel. This is necessary to have decent GUI layouts that work. Part of this is having the box sizes be the same. If you can get the code to use the automatic sizing, and produce boxes with the same exact size on all platforms, that's fine by me.
I personally think that having the sizes the exact same was worth installing the font, and dealing with making sure the fonts are working.
When a font doesn't work properly in an OS, like with Luke's problem, that's not a problem we should try to deal with in Pd. We should help people fix that problem on their OS.
It might be a better solution to have the box sizes fixed, then use the text measuring so that the cursor goes into the right place, no matter what the font situation is.
An even nicer solution would be to have the font face, font size, and box sizes saved in the patch. Then each OS could draw it the same. But then people with missing or broken fonts will still have troubles.
.hc
On Oct 23, 2007, at 8:25 PM, Miller Puckette wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3,argc, argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
I am fine with that as long as the box sizes for the default font face and standard font sizes are the same to the pixel on all platforms.
.hc
On Oct 23, 2007, at 10:52 PM, Miller Puckette wrote:
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
cheers Miller
On Tue, Oct 23, 2007 at 10:27:21PM -0400, Hans-Christoph Steiner wrote:
Here's my analysis of this:
We want to have patches be laid out the exact same on all platforms, pixel-by-pixel. This is necessary to have decent GUI layouts that work. Part of this is having the box sizes be the same. If you can get the code to use the automatic sizing, and produce boxes with the same exact size on all platforms, that's fine by me.
I personally think that having the sizes the exact same was worth installing the font, and dealing with making sure the fonts are working.
When a font doesn't work properly in an OS, like with Luke's problem, that's not a problem we should try to deal with in Pd. We should help people fix that problem on their OS.
It might be a better solution to have the box sizes fixed, then use the text measuring so that the cursor goes into the right place, no matter what the font situation is.
An even nicer solution would be to have the font face, font size, and box sizes saved in the patch. Then each OS could draw it the same. But then people with missing or broken fonts will still have troubles.
.hc
On Oct 23, 2007, at 8:25 PM, Miller Puckette wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3,argc, argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
--
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
------------------------------------------------------------------------ ----
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
On Tue, 23 Oct 2007, Miller Puckette wrote:
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
I'm beginning to think that it would be better to have box sizes fit to the size of font that one would like to have, rather than the box size that one gets. This way, patchcords lie exactly where they were meant to go.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Oct 25, 2007, at 3:18 PM, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Miller Puckette wrote:
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
I'm beginning to think that it would be better to have box sizes fit to the size of font that one would like to have, rather than the box size that one gets. This way, patchcords lie exactly where they were meant to go.
Yes, if the font info was saved to the patch, and everything was rendered the same on all platforms, that would definitely be the best option. My key point is that consistent rendering is more important than some flexibility in box sizes, IMHO.
.hc
------------------------------------------------------------------------ ----
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now with Pd-0.39.3-extended finally out, I'd like to talk about setting the timetable for the next Pd-extended release.
Would this also be a time to talk about possible structural changes to address some problems of Pd-extended? One problem I see is that the releases are too old. pd-0.39 is from 2005. Of course one can try shorter release cycles, but people are only so fast, and we're facing a two-year delay here, not just a couble of weeks, so I believe, some "mechanisms" may need to change as well, not just policies.
One thing that seems to hold back releases for years is the sheer size of Pd-extended. I brought this up in the past, but I believe, Pd-extended should be split into two packages, one including MSP-Pd, patched, and another for the actual extensions (externals, abstractions, docs, ...). I think, the build system already can do this, it's just the packaging that doesn't do that.
Ciao
Hallo!
Would this also be a time to talk about possible structural changes to address some problems of Pd-extended? One problem I see is that the releases are too old. pd-0.39 is from 2005. Of course one can try shorter release cycles, but people are only so fast, and we're facing a two-year delay here, not just a couble of weeks, so I believe, some "mechanisms" may need to change as well, not just policies.
Hm ... does it make sense to skip 0.40 and go directly to 0.41 ? But there are of course also the nightly builds with the latest stuff ...
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Hm ... does it make sense to skip 0.40 and go directly to 0.41 ?
IMO yes, although 0.41 is a moving target. But looking at how long a pd-extended release can take, it's likely that Miller's 0.41 will be released earlier.
But there are of course also the nightly builds with the latest stuff ...
But there are no autobuilds of just the externals. Making these could be a first step towards a two-fold pd-extended release.
Ciao
On Sat, October 27, 2007 11:52 am, Frank Barknecht wrote:
(...) there are no autobuilds of just the externals. Making these could be a first step towards a two-fold pd-extended release.
I support that idea, especially for it modular perspective: One could use the "extensions" module either with (the) Pd-extended ("module") or with vanilla Pd. I even suggest to make parts of extension module (ie. abstractions, externals, docs) as sub-modules.
On Oct 27, 2007, at 6:15 AM, Steffen Juul wrote:
On Sat, October 27, 2007 11:52 am, Frank Barknecht wrote:
(...) there are no autobuilds of just the externals. Making these could be a first step towards a two-fold pd-extended release.
I support that idea, especially for it modular perspective: One could use the "extensions" module either with (the) Pd-extended ("module") or with vanilla Pd. I even suggest to make parts of extension module (ie. abstractions, externals, docs) as sub-modules.
I am personally not interested in splitting it up, it defeats one of the main purposes of Pd-extended. The key idea is that Pd-extended is a common platform with a known set of libraries, etc. that is the same anywhere it's installed. I know that if I use a library on my computer, anyone else can use my patch regardless of their computer. I never use Pd without libraries. People have written lots of useful code, we should use it, and it should be easy to use.
But anyone wants to make an externals package, don't let me stop you.
Lastly, building Pd objects is not a complicated thing. People have just made it complicated by adding intricate customized build systems.
.hc
------------------------------------------------------------------------ ----
Mistrust authority - promote decentralization. - the hacker ethic
On Oct 27, 2007, at 3:28 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Now with Pd-0.39.3-extended finally out, I'd like to talk about setting the timetable for the next Pd-extended release.
Would this also be a time to talk about possible structural changes to address some problems of Pd-extended? One problem I see is that the releases are too old. pd-0.39 is from 2005. Of course one can try shorter release cycles, but people are only so fast, and we're facing a two-year delay here, not just a couble of weeks, so I believe, some "mechanisms" may need to change as well, not just policies.
One thing that seems to hold back releases for years is the sheer size of Pd-extended. I brought this up in the past, but I believe, Pd-extended should be split into two packages, one including MSP-Pd, patched, and another for the actual extensions (externals, abstractions, docs, ...). I think, the build system already can do this, it's just the packaging that doesn't do that.
I should say that splitting things into packages could make sense for debian packages, but I'd set the pd-extended package to install the rest anyhow. The debian packages are waiting to be improved, so if anyone has a grand plan, then can do it their way.
The thing that holds back Pd-extended is that very few people help to work on a proper release cycle, meaning make a release branch, do lots of testing, and fix the bugs. With more help, this would go faster. I just didn't want to release with showstopper bugs. Sadly I had to, Gem on GNU/Linux new ATI cards is almost unusable, as Roman can attest.
Also, I don't switch to Miller's next version till he's done with the bugfix releases. It's a lot of work to switch to new sources from Miller, and even more to try to track his changes. Things like Miller's windows and macosx build systems being unpublished contribute to that, as well as other things.
.hc
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The thing that holds back Pd-extended is that very few people help to work on a proper release cycle, meaning make a release branch, do lots of testing, and fix the bugs. With more help, this would go faster. I just didn't want to release with showstopper bugs. Sadly I had to, Gem on GNU/Linux new ATI cards is almost unusable, as Roman can attest.
Well, that's what I'm talking about: bugs in one part like Gem will hold up everything else. It's like pd-extended-huge is trying to grab that magical moment in time, when everything works. And even that is not consistent: IIR the Gem in pd-extended is much newer than the Pd in pd-extended. So on one hand everthing may fall apart again when starting to work on whatever is considered version number 0.40, on the other hand it seems an arbitrary decision which versions of certain components get chosen.
And then, assuming somebody can fix Gem on Ati cards, it's not easily possible to upgrade just Gem in Pd-extended's monolithic build.
Also, I don't switch to Miller's next version till he's done with the bugfix releases. It's a lot of work to switch to new sources from Miller, and even more to try to track his changes.
Okay, I can understand that and it sounds sensible.
Ciao
On Oct 27, 2007, at 12:33 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
The thing that holds back Pd-extended is that very few people help to work on a proper release cycle, meaning make a release branch, do lots of testing, and fix the bugs. With more help, this would go faster. I just didn't want to release with showstopper bugs. Sadly I had to, Gem on GNU/Linux new ATI cards is almost unusable, as Roman can attest.
Well, that's what I'm talking about: bugs in one part like Gem will hold up everything else. It's like pd-extended-huge is trying to grab that magical moment in time, when everything works. And even that is not consistent: IIR the Gem in pd-extended is much newer than the Pd in pd-extended. So on one hand everthing may fall apart again when starting to work on whatever is considered version number 0.40, on the other hand it seems an arbitrary decision which versions of certain components get chosen.
And then, assuming somebody can fix Gem on Ati cards, it's not easily possible to upgrade just Gem in Pd-extended's monolithic build.
Also, I don't switch to Miller's next version till he's done with the bugfix releases. It's a lot of work to switch to new sources from Miller, and even more to try to track his changes.
Okay, I can understand that and it sounds sensible.
That said, if someone else wants to speed up the cycle, and start working against miller's code, then they should step right up! :D
And as an experiment, I made a new autobuild called "pd-main+libs", which is Pd straight from the HEAD of MAIN and the rest of Pd- extended. None of the patches are included tho, so it shouldn't be considered "Pd-extended", though it's labeled that way (Pd-0.41.0- extended-20071027-debian-testing-i386.deb). This will only build on GNU/Linux. I need to patch Miller's sources in order to make builds on Windows and Mac OS X.
.hc
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
On 28/10/2007, at 1.28, Hans-Christoph Steiner wrote:
On Oct 27, 2007, at 12:33 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Also, I don't switch to Miller's next version till he's done with the bugfix releases. It's a lot of work to switch to new sources from Miller, and even more to try to track his changes.
Okay, I can understand that and it sounds sensible.
That said, if someone else wants to speed up the cycle, and start working against miller's code, then they should step right up! :D
(...) I need to patch Miller's sources in order to make builds on Windows and Mac OS X.
Hmm.. I thought building vanilla Pd on Mac OS X wasn't an issue. I've been meaning to try that for quite some time. That and then apply some of the patches that i like. We'll see how it goes, when it goes.
In the mean while. If building Millers source on OS X is an issue id hope if he'd share the magic.
Best, Steffen
Hmm, I had no idea that come of teh HC patches were actually necessary in order to be able to compile Pd extended on OSX or Windows... which patches are they?
thanks M
(...) I need to patch Miller's sources in order to make builds on Windows and Mac OS X.
Hmm.. I thought building vanilla Pd on Mac OS X wasn't an issue. I've been meaning to try that for quite some time. That and then apply some of the patches that i like. We'll see how it goes, when it goes.
In the mean while. If building Millers source on OS X is an issue id hope if he'd share the magic.
Best, Steffen
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
MinGW extra fixes http://sourceforge.net/tracker/index.php? func=detail&aid=1561814&group_id=55736&atid=478072
I thought I would get to making ./configure && make work on MinGW, but I didn't. So this MinGW Makefile should be included (my fault): http://sourceforge.net/tracker/index.php? func=detail&aid=1374659&group_id=55736&atid=478072
This one I forgot to submit to the tracker, apparently, so it's new: http://sourceforge.net/tracker/index.php? func=detail&aid=1821459&group_id=55736&atid=478072
Also, having a published build system for Mac OS X and Windows would help a lot.
.hc
On Oct 27, 2007, at 7:38 PM, Miller Puckette wrote:
Hmm, I had no idea that come of teh HC patches were actually necessary in order to be able to compile Pd extended on OSX or Windows... which patches are they?
thanks M
(...) I need to patch Miller's sources in order to make builds on Windows and Mac OS X.
Hmm.. I thought building vanilla Pd on Mac OS X wasn't an issue. I've been meaning to try that for quite some time. That and then apply some of the patches that i like. We'll see how it goes, when it goes.
In the mean while. If building Millers source on OS X is an issue id hope if he'd share the magic.
Best, Steffen
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
On 28/10/2007, at 1.35, Steffen Juul wrote:
I've been meaning to try that for quite some time. That and then apply some of the patches that i like. We'll see how it goes, when it goes.
I had success building pd-0.41-0test06 for Intel Mac OS X. What I did was:
- Made the following symlinks in /Library/Frameworks to link to the -- in resent versions of Mac OS X -- included version of Tcl/TK: /Library/Frameworks/Tcl.framework -> /System/Library/Frameworks/ Tcl.framework /Library/Frameworks/Tk.framework -> /System/Library/Frameworks/ Tk.framework
- Downloaded the src from Millers site
- Unpacked
- cd'ed to the src folder
- ran ./configure
- did not run 'make depend' as the INSTALL.txt said since them same file refers to a HTML document (ie. the Pd manual) that say one are just to run 'make' and doesn't mention 'make depend' at all. Confusing, but...
- ran make
But i didn't get a '.app' application out of it.
I've tried to manually follow the instructions in CVSROOT/packages/ darwin_app/Makefile but whit out much luck. I'm told that the application is either incomplete or corrupted. I'll give it a few more shots, but i have a question now also: Does it make a difference if one use `install` to make the dir's and move in the files as opposed to use `mkdir` and `mv`/`cp`?
When i've completed building a '.app' application i'll put the info up on http://puredata.info/docs/developer/MacOSXApp
This was the building part. Now the apply patches part. Before i blast it all i'd like to know if i could be of any help wrt pd- extended? Is the next Pd-extended aimaed at the 0.41 version of Pd or the 0.40 version? Are there any particular patches i could be helpful trying to apply? I can say for my part i'm mostly interested in those that alter the GUI.
Best, Steffen
Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:
This was the building part. Now the apply patches part. Before i blast it all i'd like to know if i could be of any help wrt pd- extended? Is the next Pd-extended aimaed at the 0.41 version of Pd or the 0.40 version? Are there any particular patches i could be helpful trying to apply? I can say for my part i'm mostly interested in those that alter the GUI.
It seems, Miller is currently working on font size issues, so I'd wait a bit with that feature in regard to 0.41 to see how Miller decides to implement it.
Ciao
On 29/10/2007, at 14.07, Frank Barknecht wrote:
Steffen Juul hat gesagt: // Steffen Juul wrote:
This was the building part. Now the apply patches part. Before i blast it all i'd like to know if i could be of any help wrt pd- extended? Is the next Pd-extended aimaed at the 0.41 version of Pd or the 0.40 version? Are there any particular patches i could be helpful trying to apply? I can say for my part i'm mostly interested in those that alter the GUI.
It seems, Miller is currently working on font size issues, so I'd wait a bit with that feature in regard to 0.41 to see how Miller decides to implement it.
Good idea. Thanks. Though i think it's out of my skill reach anyways.
On Oct 29, 2007, at 6:42 AM, Steffen Juul wrote:
On 28/10/2007, at 1.35, Steffen Juul wrote:
I've been meaning to try that for quite some time. That and then apply some of the patches that i like. We'll see how it goes, when it goes.
I had success building pd-0.41-0test06 for Intel Mac OS X. What I did was:
- Made the following symlinks in /Library/Frameworks to link to the
-- in resent versions of Mac OS X -- included version of Tcl/TK: /Library/Frameworks/Tcl.framework -> /System/Library/Frameworks/ Tcl.framework /Library/Frameworks/Tk.framework -> /System/Library/Frameworks/ Tk.framework
Downloaded the src from Millers site
Unpacked
cd'ed to the src folder
ran ./configure
did not run 'make depend' as the INSTALL.txt said since them same
file refers to a HTML document (ie. the Pd manual) that say one are just to run 'make' and doesn't mention 'make depend' at all. Confusing, but...
- ran make
But i didn't get a '.app' application out of it.
First off, you'll have much better luck with this Tcl/Tk than the Apple ones. The included ones are quite old, this is what I just upgraded the auto-builds to:
http://idmi.poly.edu/pdlab/tcltk/
I've tried to manually follow the instructions in CVSROOT/packages/ darwin_app/Makefile but whit out much luck. I'm told that the application is either incomplete or corrupted. I'll give it a few more shots, but i have a question now also: Does it make a difference if one use `install` to make the dir's and move in the files as opposed to use `mkdir` and `mv`/`cp`?
install vs. mkdir and cp shouldn't matter
When i've completed building a '.app' application i'll put the info up on http://puredata.info/docs/developer/MacOSXApp
excellent :)
This was the building part. Now the apply patches part. Before i blast it all i'd like to know if i could be of any help wrt pd- extended? Is the next Pd-extended aimaed at the 0.41 version of Pd or the 0.40 version? Are there any particular patches i could be helpful trying to apply? I can say for my part i'm mostly interested in those that alter the GUI.
Best, Steffen
You can definitely be a help in Pd-extended! :D
The next version is aimed at 0.40.3, since I hope to release before Miller finishes his 0.41 cycle. As for porting the patches to 0.41, that's a moving target. The 0.41 code will change, the patches will change, so it's not really worth doing just yet. Now is the time to write patches :).
Since you are interested in the GUI, sounds like it would be best if you worked on that. For example, a real preferences pane with tabs on it would be really nice. I'll happily help you make that happen, if you interested. The Tcl/Tk part is not too hard to learn, you mostly avoid the Pd/Tcl oddness, so it would a good place to start. In Pd.app/Contents/Resources/bin/pd.tk, check out: pdtk_path_dialog, pdtk_startup_dialog, pdtk_audio_dialog, pdtk_midi_dialog. For the most part, this is straight Tcl/Tk GUI building, which is quite similar to Java and other things.
I just did some work on the key bindings in the panels. Return hits OK and Esc hits cancel in all the panels now. Plus Cmd/Ctrl-w closes all the windows, including the help browser, find panel, etc. Then I added the "Clear Pd window" option to the Edit menu. You can stick the attached pd.tk in the latest Pd-extended release to try these changes.
.hc
------------------------------------------------------------------------ ----
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On 29/10/2007, at 16.10, Hans-Christoph Steiner wrote:
First off, you'll have much better luck with this Tcl/Tk than the Apple ones. The included ones are quite old, this is what I just upgraded the auto-builds to:
Not asking where you dug that up. How do you install it? When i dump them into /Library/Frameworks (and remove the old symlinks) i can still build Pd-0.41-test6 but when i run it it doesn't behave the intended way. The console window appears but i can't open patches and much of the menus are not working either. It "the same as" when i build it before adding the before mentioned symlinks. I have the feeling i'm doing something wrong, but i'm lost as to know what.
The next version is aimed at 0.40.3, since I hope to release before Miller finishes his 0.41 cycle.
Cool. I'll work up against that one. First problem is that i don't have success building it. No matter what Tcl/Tk i use. With "old" (shipped-in) Tcl/Tk it does build, but when i run it i get:
sh: line 1: /Applications/Wish.app/Contents/MacOS/Wish: No such file or directory
This is (all) using the makefile Miller supplies -- or which is rendered by ./configure.
I'll get back to and reply to the rest when i get to it. Not forgotten. Defo interesting. Thanks!
On Oct 29, 2007, at 3:30 PM, Steffen Juul wrote:
On 29/10/2007, at 16.10, Hans-Christoph Steiner wrote:
First off, you'll have much better luck with this Tcl/Tk than the Apple ones. The included ones are quite old, this is what I just upgraded the auto-builds to:
Not asking where you dug that up. How do you install it? When i dump them into /Library/Frameworks (and remove the old symlinks)
Just copy them into /Library/Frameworks
i can still build Pd-0.41-test6 but when i run it it doesn't behave the intended way. The console window appears but i can't open patches and much of the menus are not working either. It "the same as" when i build it before adding the before mentioned symlinks. I have the feeling i'm doing something wrong, but i'm lost as to know what.
The next version is aimed at 0.40.3, since I hope to release before Miller finishes his 0.41 cycle.
Cool. I'll work up against that one. First problem is that i don't have success building it. No matter what Tcl/Tk i use. With "old" (shipped-in) Tcl/Tk it does build, but when i run it i get:
sh: line 1: /Applications/Wish.app/Contents/MacOS/Wish: No such file or directory
This is (all) using the makefile Miller supplies -- or which is rendered by ./configure.
I'll get back to and reply to the rest when i get to it. Not forgotten. Defo interesting. Thanks!
Miller has some hidden secrets, I am not really sure how he does it. I have some tricks as well, they are in packages/darwin_app/Makefile :)
.hc
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On 29/10/2007, at 21.31, Hans-Christoph Steiner wrote:
Miller has some hidden secrets, I am not really sure how he does it. I have some tricks as well, they are in packages/darwin_app/ Makefile :)
It's a shame Millers doesn't want do share his tricks.
I again tried to imitate the darwin_app_wrapper target but got no further -- i skipped the if condition as i've build up against the Tcl/Tk in /System though through symlinks in /Library/Frameworks. That's my main trouble maker suspect.
I'll dig deeper into your tricks. I think there are some fundamental stuff about make that i don't know enough about to get to the juice. But i've found the GNU Make book online [1] and will see if it can help me dig.
My goal is to skin your /packages/Darwin_app/Makefile to get light Makefile that can be dropped into the vanilla src folder as a replacement that can build a .app application.
On Oct 30, 2007, at 4:49 PM, Steffen Juul wrote:
On 29/10/2007, at 21.31, Hans-Christoph Steiner wrote:
Miller has some hidden secrets, I am not really sure how he does it. I have some tricks as well, they are in packages/darwin_app/ Makefile :)
It's a shame Millers doesn't want do share his tricks.
To be fair, he did give me the code when I asked for it a while back. I mean more it's not in CVS or in the source downloads.
I again tried to imitate the darwin_app_wrapper target but got no further -- i skipped the if condition as i've build up against the Tcl/Tk in /System though through symlinks in /Library/Frameworks. That's my main trouble maker suspect.
I'll dig deeper into your tricks. I think there are some fundamental stuff about make that i don't know enough about to get to the juice. But i've found the GNU Make book online [1] and will see if it can help me dig.
My goal is to skin your /packages/Darwin_app/Makefile to get light Makefile that can be dropped into the vanilla src folder as a replacement that can build a .app application.
It would be good to work on pd/src/makefile.in. Then you can submit a patch, and then pd-vanilla could build an app from the main sources.
.hc
------------------------------------------------------------------------ ----
On 29/10/2007, at 16.10, Hans-Christoph Steiner wrote:
Since you are interested in the GUI, sounds like it would be best if you worked on that. For example, a real preferences pane with tabs on it would be really nice. I'll happily help you make that happen, if you interested. The Tcl/Tk part is not too hard to learn, you mostly avoid the Pd/Tcl oddness, so it would a good place to start. In Pd.app/Contents/Resources/bin/pd.tk, check out: pdtk_path_dialog, pdtk_startup_dialog, pdtk_audio_dialog, pdtk_midi_dialog. For the most part, this is straight Tcl/Tk GUI building, which is quite similar to Java and other things.
It would be a challenge. But i'll look into it and see how it goes. It would for sure be a cool thing to add.
There are also, to my knowledge, some issues with scrolling and adding of scroll-bar at load time if the window is smaller then the patch. And sometimes the window is bigger then my screen which renders use problems as i can't even get to resize. ( -- This is partly due to the (lame) way the os x wm is designed but still a problematic issue from Pd point of view, imho. I don't know if this only happens on os x though.)
Are all the other GUI patches in /packages/patches ported to work up against 0.40-3?
If not there are some (disable_close_confirm-0.39.2.patch, cmd- click_manipulates_GUIs-0.41.0-test03.patch, pd_autoscrollbars-0.40- pre.patch, pd_controls-anchor-fix-0.40-pre.patch) i'm particular willing to help with.
Also scrolling in the help browser, is that just a bonus of a newer Tcl/Tk version or is invoked by a patch somewhere?
I just did some work on the key bindings in the panels. Return hits OK and Esc hits cancel in all the panels now. Plus Cmd/Ctrl-w closes all the windows, including the help browser, find panel, etc. Then I added the "Clear Pd window" option to the Edit menu. You can stick the attached pd.tk in the latest Pd-extended release to try these changes.
Thats great. Really useful features. Just as a note ctrl/cmd-w doesn't close the Font Bomb. Esc and Return doesn't have effect there either.
On Oct 30, 2007, at 5:20 PM, Steffen Juul wrote:
On 29/10/2007, at 16.10, Hans-Christoph Steiner wrote:
Since you are interested in the GUI, sounds like it would be best if you worked on that. For example, a real preferences pane with tabs on it would be really nice. I'll happily help you make that happen, if you interested. The Tcl/Tk part is not too hard to learn, you mostly avoid the Pd/Tcl oddness, so it would a good place to start. In Pd.app/Contents/Resources/bin/pd.tk, check out: pdtk_path_dialog, pdtk_startup_dialog, pdtk_audio_dialog, pdtk_midi_dialog. For the most part, this is straight Tcl/Tk GUI building, which is quite similar to Java and other things.
It would be a challenge. But i'll look into it and see how it goes. It would for sure be a cool thing to add.
There are also, to my knowledge, some issues with scrolling and adding of scroll-bar at load time if the window is smaller then the patch. And sometimes the window is bigger then my screen which renders use problems as i can't even get to resize. ( -- This is partly due to the (lame) way the os x wm is designed but still a problematic issue from Pd point of view, imho. I don't know if this only happens on os x though.)
Yes, that would be a nice one to have fixed, but probably not a good one to start on... :)
Are all the other GUI patches in /packages/patches ported to work up against 0.40-3?
If not there are some (disable_close_confirm-0.39.2.patch, cmd- click_manipulates_GUIs-0.41.0-test03.patch, pd_autoscrollbars-0.40- pre.patch, pd_controls-anchor-fix-0.40-pre.patch) i'm particular willing to help with.
Everything in packages/patches is currently being applied to the nightly Pd-0.40.3-extended builds.
Also scrolling in the help browser, is that just a bonus of a newer Tcl/Tk version or is invoked by a patch somewhere?
I think that's just Tcl/Tk. Maybe there's a patch, I don't remember.
I just did some work on the key bindings in the panels. Return hits OK and Esc hits cancel in all the panels now. Plus Cmd/Ctrl- w closes all the windows, including the help browser, find panel, etc. Then I added the "Clear Pd window" option to the Edit menu. You can stick the attached pd.tk in the latest Pd-extended release to try these changes.
Thats great. Really useful features. Just as a note ctrl/cmd-w doesn't close the Font Bomb. Esc and Return doesn't have effect there either.
I just noticed that and fixed it. I'll make patches soon and add them to the auto-builds and patch tracker.
.hc
------------------------------------------------------------------------ ----
Mistrust authority - promote decentralization. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
And as an experiment, I made a new autobuild called "pd-main+libs", which is Pd straight from the HEAD of MAIN and the rest of Pd- extended. None of the patches are included tho, so it shouldn't be considered "Pd-extended", though it's labeled that way (Pd-0.41.0- extended-20071027-debian-testing-i386.deb).
Thanks, I will test later.
NB: I'd suggest to drop autobuilding debs. All debs, as the currently are, are very wrong in lots of places (policy violations, package name with uppercase, installs to /usr/local, etc.). Instead of fixing this it's easier to test-install simple tar.gz files
CIao
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
And as an experiment, I made a new autobuild called "pd-main+libs", which is Pd straight from the HEAD of MAIN and the rest of Pd- extended. None of the patches are included tho, so it shouldn't be considered "Pd-extended", though it's labeled that way (Pd-0.41.0- extended-20071027-debian-testing-i386.deb).
Thanks, I will test later.
NB: I'd suggest to drop autobuilding debs. All debs, as the currently are, are very wrong in lots of places (policy violations, package name with uppercase, installs to /usr/local, etc.). Instead of fixing this it's easier to test-install simple tar.gz files
the only reasoning behind the .deb is to get the dependencies right. apart from that, i agree to frank.
one hack to solve this would be to distribute pd-extended as .tgz and additionally provide a "pd-extended-deps" package (which conforms to the debian standards)
or make the pd-extended package be standard-compliant, but install to /usr/lib/pd-extended/ rather than /usr/lib/pd
mf.asdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
the only reasoning behind the .deb is to get the dependencies right. apart from that, i agree to frank.
one hack to solve this would be to distribute pd-extended as .tgz and additionally provide a "pd-extended-deps" package (which conforms to the debian standards)
or make the pd-extended package be standard-compliant, but install to /usr/lib/pd-extended/ rather than /usr/lib/pd
I think, the latter is the better option ... and use /usr/bin/pd-extended as binary name.
Dropping debs for autobuilds may be a bit too harsh, but they really don't make much sense to me for just testing stuff. And as Hans mentioned, even as a general distribution package, the debs still need a lot of work to evolve from their quick hack status. However this work IMO would have to include splitting into subpackages, if alone because it's too risky that something will deinstall the full pd-extended shebang when some package it depends on changes, which could happen every day in the Debian world.
Ciao
On Oct 28, 2007, at 4:53 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
And as an experiment, I made a new autobuild called "pd-main+libs", which is Pd straight from the HEAD of MAIN and the rest of Pd- extended. None of the patches are included tho, so it shouldn't be considered "Pd-extended", though it's labeled that way (Pd-0.41.0- extended-20071027-debian-testing-i386.deb).
Thanks, I will test later.
NB: I'd suggest to drop autobuilding debs. All debs, as the currently are, are very wrong in lots of places (policy violations, package name with uppercase, installs to /usr/local, etc.). Instead of fixing this it's easier to test-install simple tar.gz files
Patches welcome! :D
.hc
CIao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
-
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luke Iannini (pd) -
Mathieu Bouchard -
Miller Puckette -
Steffen Juul