--- On Thu, 7/7/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM
On Thu, 07 Jul 2011 16:39 +0200, "Ivica Ico Bukvic" ico@vt.edu wrote:
I ended up refactoring the magic glass and
highlighting code quite a
bit, I think there might be something worth
checking out. As for
other bug fixes, it would be great to have them
in the patch tracker
so we can sort them out. It would take me a
massive amount of time to
figure out what code changes are for what in
pdl2ork since there isn't
any version control (that I could find at least)
and it seems to be a
mix of 0.42 and 0.43 versions.
It's based off of 0.42.6 extended tree. As for
submitting patches, I've
been doing this in the past. Alas, a good number of
them never got any
attention which is not very encouraging.
If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle.
.hc
bugfix 3127123 Closed bugfix 3110267 Open, no comments, no assignees bugfix 3109768 Open, and I added a new comment (Note: the comment I added is fixed in Pd-l2ork) bugfix 3108513 Open, no comments
- bugfix 3106837 Open, comments
bugfix 3106799 Open, comments, bug still exists (Note: fixed in Pd-l2ork) bugfix 3102512 Open, comments patch 3077431 Open, comments, I emailed the cyclone author to ask if he's ok with Ico's improvements... patch 1670440 Closed, accepted
If any of these didn't apply cleanly and didn't build, there's no comment indicating so.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 07 Jul 2011 10:06 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Thu, 7/7/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM
On Thu, 07 Jul 2011 16:39 +0200, "Ivica Ico Bukvic" ico@vt.edu wrote:
I ended up refactoring the magic glass and
highlighting code quite a
bit, I think there might be something worth
checking out. As for
other bug fixes, it would be great to have them
in the patch tracker
so we can sort them out. It would take me a
massive amount of time to
figure out what code changes are for what in
pdl2ork since there isn't
any version control (that I could find at least)
and it seems to be a
mix of 0.42 and 0.43 versions.
It's based off of 0.42.6 extended tree. As for
submitting patches, I've
been doing this in the past. Alas, a good number of
them never got any
attention which is not very encouraging.
If you look at the patch tracker, and filter on Closed ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and build, then I'm not really likely to pursue it much further. I've tried figuring out patches like that in the past, and it just takes too much time to try to figure out what's wrong, etc. and it doesn't speak well of the patch if it doesn't past the first hurdle.
.hc
bugfix 3127123 Closed
http://sourceforge.net/tracker/?func=detail&aid=3127123&group_id=557... Accepted with comments. Am I missing something?
bugfix 3110267 Open, no comments, no assignees patch 3077431 Open, comments, I emailed the cyclone author to ask if he's ok with Ico's improvements...
No word from the upstream author of cyclone, he's not active anymore. The focus of the cyclone library is to be clones of Max/MSP objects. I'm not in a place to test that stuff, so I'm not likely to handle patches for cyclone. I don't really have a criteria to judge if its correct, unless its a really simple bugfix.
bugfix 3109768 Open, and I added a new comment (Note: the comment I added is fixed in Pd-l2ork)
donno, haven't reviewed
bugfix 3108513 Open, no comments
patch out of date, applies to 0.42 but not 0.43
- bugfix 3106837 Open, comments
commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere.
bugfix 3106799 Open, comments, bug still exists (Note: fixed in Pd-l2ork) bugfix 3102512 Open, comments patch 1670440 Closed, accepted
If any of these didn't apply cleanly and didn't build, there's no comment indicating so.
I haven't necessarily had time to review everything, nagging and poking me is perfectly appropriate if you think I should review something. And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds.
.hc
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--- On Thu, 7/7/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com, "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 9:20 PM
On Thu, 07 Jul 2011 10:06 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Thu, 7/7/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing features
To: "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM
On Thu, 07 Jul 2011 16:39 +0200, "Ivica Ico
Bukvic" ico@vt.edu wrote:
I ended up refactoring the magic glass
and
highlighting code quite a
bit, I think there might be something
worth
checking out. As for
other bug fixes, it would be great to
have them
in the patch tracker
so we can sort them out. It would
take me a
massive amount of time to
figure out what code changes are for
what in
pdl2ork since there isn't
any version control (that I could find
at least)
and it seems to be a
mix of 0.42 and 0.43 versions.
It's based off of 0.42.6 extended tree. As
for
submitting patches, I've
been doing this in the past. Alas, a good
number of
them never got any
attention which is not very encouraging.
If you look at the patch tracker, and filter on
Closed
ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and
build, then I'm
not really likely to pursue it much further. I've tried
figuring
out patches like that in the past, and it just takes too much time
to try to
figure out what's wrong, etc. and it doesn't speak well of
the
patch if it doesn't past the first hurdle.
.hc
bugfix 3127123 Closed
http://sourceforge.net/tracker/?func=detail&aid=3127123&group_id=557... Accepted with comments. Am I missing something?
bugfix 3110267 Open, no comments, no assignees patch 3077431 Open, comments, I emailed the cyclone
author to ask if he's
ok with Ico's improvements...
No word from the upstream author of cyclone, he's not active anymore. The focus of the cyclone library is to be clones of Max/MSP objects.
The Max/MSP stuff is proprietary, so we can only guess at how the code is actually written. So to get a "clone" of a Max object one needs to a) read the Max docs, and b) compare results from using [foo] in Max to using [foo] in Pd.
Ico seems to be saying that Max's [coll] isn't causing audio dropouts, and Pd's is, and that his patch fixes this. AFAICT his implementation still adheres to the interface for [coll] listed in the Max docs, so I don't see how this isn't a better clone of Max's [coll] behavior.
I'm not in a place to test that stuff, so I'm not likely to handle patches for cyclone. I don't really have a criteria to judge if its correct, unless its a really simple bugfix.
But if Mr. Czaja says, "Sure, go ahead," you won't have a problem with this patch, right?
bugfix 3109768 Open, and I added a new comment (Note:
the comment I added
is fixed in Pd-l2ork)
donno, haven't reviewed
bugfix 3108513 Open, no comments
patch out of date, applies to 0.42 but not 0.43
- bugfix 3106837 Open, comments
commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere.
bugfix 3106799 Open, comments, bug still exists (Note:
fixed in Pd-l2ork)
bugfix 3102512 Open, comments patch 1670440 Closed, accepted
If any of these didn't apply cleanly and didn't build,
there's no comment
indicating so.
I haven't necessarily had time to review everything, nagging and poking me is perfectly appropriate if you think I should review something.
Ok, but it's not really a solution, because the time I have to nag and poke is probably about the same amount that you have to review stuff.
-Jonathan
And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds.
.hc
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jul 7, 2011, at 5:14 PM, Jonathan Wilkes wrote:
--- On Thu, 7/7/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com, "Ivica Ico Bukvic" <ico@vt.eduCc: pd-list@iem.at Date: Thursday, July 7, 2011, 9:20 PM
On Thu, 07 Jul 2011 10:06 -0700, "Jonathan Wilkes" <jancsika@yahoo.com
wrote:
--- On Thu, 7/7/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing features
To: "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Thursday, July 7, 2011, 5:33 PM
On Thu, 07 Jul 2011 16:39 +0200, "Ivica Ico
Bukvic" ico@vt.edu wrote:
I ended up refactoring the magic glass
and
highlighting code quite a
bit, I think there might be something
worth
checking out. As for
other bug fixes, it would be great to
have them
in the patch tracker
so we can sort them out. It would
take me a
massive amount of time to
figure out what code changes are for
what in
pdl2ork since there isn't
any version control (that I could find
at least)
and it seems to be a
mix of 0.42 and 0.43 versions.
It's based off of 0.42.6 extended tree. As
for
submitting patches, I've
been doing this in the past. Alas, a good
number of
them never got any
attention which is not very encouraging.
If you look at the patch tracker, and filter on
Closed
ones, you'll see which ones get accepted. Most do. It takes a lot of time to review patches, so if they don't cleanly apply and
build, then I'm
not really likely to pursue it much further. I've tried
figuring
out patches like that in the past, and it just takes too much time
to try to
figure out what's wrong, etc. and it doesn't speak well of
the
patch if it doesn't past the first hurdle.
.hc
bugfix 3127123 Closed
http://sourceforge.net/tracker/?func=detail&aid=3127123&group_id=557... Accepted with comments. Am I missing something?
bugfix 3110267 Open, no comments, no assignees patch 3077431 Open, comments, I emailed the cyclone
author to ask if he's
ok with Ico's improvements...
No word from the upstream author of cyclone, he's not active anymore. The focus of the cyclone library is to be clones of Max/MSP objects.
The Max/MSP stuff is proprietary, so we can only guess at how the
code is actually written. So to get a "clone" of a Max object one
needs to a) read the Max docs, and b) compare results from using
[foo] in Max to using [foo] in Pd.Ico seems to be saying that Max's [coll] isn't causing audio
dropouts, and Pd's is, and that his patch fixes this. AFAICT his
implementation still adheres to the interface for [coll] listed in
the Max docs, so I don't see how this isn't a better clone of Max's
[coll] behavior.I'm not in a place to test that stuff, so I'm not likely to handle patches for cyclone. I don't really have a criteria to judge if its correct, unless its a really simple bugfix.
But if Mr. Czaja says, "Sure, go ahead," you won't have a problem
with this patch, right?
That is correct.
bugfix 3109768 Open, and I added a new comment (Note:
the comment I added
is fixed in Pd-l2ork)
donno, haven't reviewed
bugfix 3108513 Open, no comments
patch out of date, applies to 0.42 but not 0.43
- bugfix 3106837 Open, comments
commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere.
bugfix 3106799 Open, comments, bug still exists (Note:
fixed in Pd-l2ork)
bugfix 3102512 Open, comments patch 1670440 Closed, accepted
If any of these didn't apply cleanly and didn't build,
there's no comment
indicating so.
I haven't necessarily had time to review everything, nagging and poking me is perfectly appropriate if you think I should review something.
Ok, but it's not really a solution, because the time I have to nag
and poke is probably about the same amount that you have to review
stuff.
That's just one option. You could also maintain your own fork/branch
and accept these patches yourself. That's another option that seems
to be working for Ico. I fix things that affect my work because I see
them. I try to do as much as I can otherwise, but like you say, time
is limited.
The problem with forks is if improvements don't migrate upstream.
Then we don't benefit from sharing the fixes. Making things migrate
upstream takes time in itself. Try getting a patch into the Linux
kernel, that'll make Pd seem like cake ;-)
.hc
-Jonathan
And anything assigned to Miller and reviewed positively by IOhannes I'm going to defer any action on until Miller responds.
.hc
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at wrote:
[...]
The problem with forks is if improvements don't migrate upstream.
I think it's both a problem-with and a cause-of.
Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself.
How does one figure out who has the responsibility to make sure things migrate upstream (for example: [initbang] and [closebang])?
Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd.
-Jonathan
.hc
-Jonathan
And anything assigned to Miller and reviewed
positively by
IOhannes I'm going to defer any action on until Miller
responds.
.hc
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at wrote:
[...]
The problem with forks is if improvements don't migrate upstream.
I think it's both a problem-with and a cause-of.
Yup, that makes sense.
Then we don't benefit from sharing the fixes. Making things migrate upstream takes time in itself.
How does one figure out who has the responsibility to make sure
things migrate upstream (for example: [initbang] and [closebang])?
Mostly by someone deciding its important enough that they want to work
on it themself, and then lots of testing and communication.
Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the core of the largest
free software project in the history of computing is a wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects than Linux, things like
Debian are quite a bit larger in scale.
.hc
-Jonathan
.hc
-Jonathan
And anything assigned to Miller and reviewed
positively by
IOhannes I'm going to defer any action on until Miller
responds.
.hc
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
http://at.or.at/hans/
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at
wrote:
[...]
The problem with forks is if improvements don't
migrate
upstream.
I think it's both a problem-with and a cause-of.
Yup, that makes sense.
Then we don't benefit from sharing the fixes. Making things migrate upstream takes
time in
itself.
How does one figure out who has the responsibility to
make sure
things migrate upstream (for example: [initbang] and
[closebang])?
Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication.
Ok. So in patch id#2838176, what is Guenter's idea for a clean implementation of tooltips that you were referring to? I didn't find anything on the user or dev list.
Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the core of
the largest
free software project in the history of computing is a
wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale.
I read a white paper on total development cost of a linux distro and just remembered "linux". I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel.
-Jonathan
.hc
-Jonathan
.hc
-Jonathan
And anything assigned to Miller and reviewed
positively by
IOhannes I'm going to defer any action on until Miller
responds.
.hc
-Jonathan
> >
> Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management
->
http://lists.puredata.info/listinfo/pd-list
>
"[T]he greatest purveyor of violence in the world
today
[is] my own government." - Martin Luther King,
Jr.
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PMOn Jul 9, 2011, at 1:48 AM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at
wrote:
[...]
The problem with forks is if improvements don't
migrate
upstream.
I think it's both a problem-with and a cause-of.
Yup, that makes sense.
Then we don't benefit from sharing the fixes. Making things migrate upstream takes
time in
itself.
How does one figure out who has the responsibility to
make sure
things migrate upstream (for example: [initbang] and
[closebang])?
Mostly by someone deciding its important enough that they want to work on it themself, and then lots of testing and communication.
Ok. So in patch id#2838176, what is Guenter's idea for a clean
implementation of tooltips that you were referring to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was, but I do have a
vague idea of how to do it cleanly. I think it should be similar to
the way its done in Max/MSP. Basically there is a standard function,
something like nlet_info(), which returns the tooltip info. Pd would
then check whether an object had that function when it loaded the
binary, and if so register it in the tooltips.
.hc
Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the core of
the largest
free software project in the history of computing is a
wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects than Linux, things like Debian are quite a bit larger in scale.
I read a white paper on total development cost of a linux distro and
just remembered "linux". I think the distro in the paper was Fedora
9, which was estimated to be almost an order of magnitude more
expensive than the Linux kernel.-Jonathan
.hc
-Jonathan
.hc
-Jonathan
And anything assigned to Miller and reviewed
positively by
IOhannes I'm going to defer any action on until Miller
responds.
.hc
> > -Jonathan > >> >>
>> Pd-list@iem.at >> mailing list >> UNSUBSCRIBE and account-management
->
http://lists.puredata.info/listinfo/pd-list
>> >
"[T]he greatest purveyor of violence in the world
today
[is] my own government." - Martin Luther King,
Jr.
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
--- On Sun, 7/10/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner
wrote:
[...]
The problem with forks is if improvements
don't
migrate
upstream.
I think it's both a problem-with and a
cause-of.
Yup, that makes sense.
Then we don't benefit from sharing the fixes. Making things migrate
upstream takes
time in
itself.
How does one figure out who has the
responsibility to
make sure
things migrate upstream (for example:
[initbang] and
[closebang])?
Mostly by someone deciding its important enough
that they
want to work on it themself, and then lots of testing and communication.
Ok. So in patch id#2838176, what is Guenter's
idea for a clean
implementation of tooltips that you were referring
to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info.
Where would one define the standard function?
Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips.
This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind <Enter> and <Leave> to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of "motion" messages that don't trigger anything.
-Jonathan
.hc
Try getting a patch into the Linux
kernel,
that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the
core of
the largest
free software project in the history of
computing is a
wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects than
Linux, things
like Debian are quite a bit larger in scale.
I read a white paper on total development cost of a
linux distro and
just remembered "linux". I think the distro in
the paper was Fedora
9, which was estimated to be almost an order of
magnitude more
expensive than the Linux kernel.
-Jonathan
.hc
-Jonathan
.hc
-Jonathan
> And > anything assigned to Miller and
reviewed
positively by
> IOhannes I'm > going to defer any action on until
Miller
responds.
> > .hc > >> >> -Jonathan >> >>> >>>
>>> Pd-list@iem.at >>> mailing list >>> UNSUBSCRIBE and
account-management
->
http://lists.puredata.info/listinfo/pd-list
>>> >> > >
"[T]he greatest purveyor of violence in
the world
today
[is] my own government." - Martin Luther
King,
Jr.
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Jonathan Wilkes jancsika@yahoo.com wrote:
--- On Sun, 7/10/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner
wrote:
[...]
The problem with forks is if improvements
don't
migrate
upstream.
I think it's both a problem-with and a
cause-of.
Yup, that makes sense.
Then we don't benefit from sharing the fixes. Making things migrate
upstream takes
time in
itself.
How does one figure out who has the
responsibility to
make sure
things migrate upstream (for example:
[initbang] and
[closebang])?
Mostly by someone deciding its important enough
that they
want to work on it themself, and then lots of testing and communication.
Ok. So in patch id#2838176, what is Guenter's
idea for a clean
implementation of tooltips that you were referring
to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info.
Where would one define the standard function?
Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips.
This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind <Enter> and <Leave> to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of "motion" messages that don't trigger anything.
I may be way off the mark here, if I recall correctly I think that info is used for dragging stuff and similar actions.
-Jonathan
.hc
Try getting a patch into the Linux
kernel,
that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the
core of
the largest
free software project in the history of
computing is a
wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects than
Linux, things
like Debian are quite a bit larger in scale.
I read a white paper on total development cost of a
linux distro and
just remembered "linux". I think the distro in
the paper was Fedora
9, which was estimated to be almost an order of
magnitude more
expensive than the Linux kernel.
-Jonathan
.hc
-Jonathan
.hc
> > -Jonathan > >> And >> anything assigned to Miller and
reviewed
positively by >> IOhannes I'm >> going to defer any action on until
Miller
responds. >> >> .hc >> >>> >>> -Jonathan >>> >>>> >>>>
>>>> Pd-list@iem.at >>>> mailing list >>>> UNSUBSCRIBE and
account-management
->
http://lists.puredata.info/listinfo/pd-list >>>> >>> >> >>
"[T]he greatest purveyor of violence in
the world
today
[is] my own government." - Martin Luther
King,
Jr.
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
--- On Mon, 7/11/11, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com, "Hans-Christoph Steiner" hans@at.or.at Cc: pd-list@iem.at Date: Monday, July 11, 2011, 2:56 AM
Jonathan Wilkes jancsika@yahoo.com wrote:
--- On Sun, 7/10/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing
features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43
updates: lots
of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan
Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph
Steiner
wrote:
[...]
> The problem with forks is if
improvements
don't
migrate
> upstream.
I think it's both a problem-with and
a
cause-of.
Yup, that makes sense.
> Then we don't benefit from
sharing the
> fixes. Making things migrate
upstream takes
time in
> itself.
How does one figure out who has the
responsibility to
make sure
things migrate upstream (for
example:
[initbang] and
[closebang])?
Mostly by someone deciding its important
enough
that they
want to work on it themself, and then lots of testing
and
communication.
Ok. So in patch id#2838176, what is
Guenter's
idea for a clean
implementation of tooltips that you were
referring
to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was,
but I do
have a vague idea of how to do it cleanly. I think it
should
be similar to the way its done in Max/MSP. Basically there is
a
standard function, something like nlet_info(), which returns the
tooltip
info.
Where would one define the standard function?
Pd would then check whether an object had that function
when it
loaded the binary, and if so register it in the tooltips.
This brings up an issue I've been wondering about since
learning a
little more about the canvas editor: why does the pd
gui send 'motion'
messages to pd? Why not, for example, just have a
tag for an inlet
rectangle and bind <Enter> and <Leave> to
it? Then you'd only be
sending messages from the gui for the events you care
about, instead of
tons of "motion" messages that don't trigger anything.
I may be way off the mark here, if I recall correctly I think that info is used for dragging stuff and similar actions.
Yes, it is, but I was just thinking that extending a wire from an outlet, which sends a message to pd every mouse motion and walks through the objects in the glist to see if it hit a box, could be simplified if you just handled it on the gui end. Then only send a message if the wire connection is successful, or if there is a disconnection.
But I guess you'd still have to send a message every pixel you drag an object in editmode anyway.
-Jonathan
.hc
> Try getting a patch into the
Linux
kernel,
> that'll make Pd seem like cake
;-)
Yes, I would hope that making changes
to the
core of
the largest
free software project in the history
of
computing is a
wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects
than
Linux, things
like Debian are quite a bit larger in scale.
I read a white paper on total development
cost of a
linux distro and
just remembered "linux". I think the distro
in
the paper was Fedora
9, which was estimated to be almost an order
of
magnitude more
expensive than the Linux kernel.
-Jonathan
.hc
-Jonathan
> > .hc > > >> >> -Jonathan >> >>> And >>> anything assigned to
Miller and
reviewed
> positively by >>> IOhannes I'm >>> going to defer any action
on until
Miller
> responds. >>> >>> .hc >>> >>>> >>>> -Jonathan >>>> >>>>> >>>>> >
>>>>> Pd-list@iem.at >>>>> mailing list >>>>> UNSUBSCRIBE and
account-management
->
> http://lists.puredata.info/listinfo/pd-list >>>>> >>>> >>> >>> > > > > > >
> > "[T]he greatest purveyor of
violence in
the world
today
> [is] my own government." - Martin
Luther
King,
Jr.
> > > >
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
On Jul 10, 2011, at 11:28 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com, "Hans-Christoph
Steiner" hans@at.or.at Cc: pd-list@iem.at Date: Monday, July 11, 2011, 2:56 AMJonathan Wilkes jancsika@yahoo.com wrote:
--- On Sun, 7/10/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing
features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43
updates: lots
of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan
Wilkes
wrote:
> > > --- On Sat, 7/9/11, Hans-Christoph
Steiner
wrote: > > [...] > >> The problem with forks is if
improvements
don't
migrate >> upstream. > > I think it's both a problem-with and
a
cause-of.
Yup, that makes sense.
>> Then we don't benefit from
sharing the
>> fixes. Making things migrate
upstream takes
time in >> itself. > > How does one figure out who has the
responsibility to
make sure > things migrate upstream (for
example:
[initbang] and
[closebang])?
Mostly by someone deciding its important
enough
that they
want to work on it themself, and then lots of testing
and
communication.
Ok. So in patch id#2838176, what is
Guenter's
idea for a clean
implementation of tooltips that you were
referring
to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was,
but I do
have a vague idea of how to do it cleanly. I think it
should
be similar to the way its done in Max/MSP. Basically there is
a
standard function, something like nlet_info(), which returns the
tooltip
info.
Where would one define the standard function?
Pd would then check whether an object had that function
when it
loaded the binary, and if so register it in the tooltips.
This brings up an issue I've been wondering about since
learning a
little more about the canvas editor: why does the pd
gui send 'motion'
messages to pd? Why not, for example, just have a
tag for an inlet
rectangle and bind <Enter> and <Leave> to
it? Then you'd only be
sending messages from the gui for the events you care
about, instead of
tons of "motion" messages that don't trigger anything.
I may be way off the mark here, if I recall correctly I think that info is used for dragging stuff and similar actions.
Yes, it is, but I was just thinking that extending a wire from an
outlet, which sends a message to pd every mouse motion and walks
through the objects in the glist to see if it hit a box, could be
simplified if you just handled it on the gui end. Then only send a
message if the wire connection is successful, or if there is a
disconnection.But I guess you'd still have to send a message every pixel you drag
an object in editmode anyway.
For connections/cords, you've illustrated it well. Pd only tracks
whether they are connected or not, so it doesn't need to know the
position, especially during creation. For moving boxes, Pd would
mostly not need to know about the location, GUI objects would, but
that would be within the GUI object. The one thing I can think of
where Pd needs to know the location is with inlets and outlets, since
the position could change the program.
Changing the connection logic to be entirely in the GUI would be a
good place to start on this. I think pd-gui would just need to
communicate using the 'connect' message, then the disconnect, and
which cord is under the magic glass.
.hc
-Jonathan
.hc
>> Try getting a patch into the
Linux
kernel,
>> that'll make Pd seem like cake
;-)
> > Yes, I would hope that making changes
to the
core of
the largest > free software project in the history
of
computing is a
wee bit more > difficult than making changes to Pd.
Actually, there are much bigger projects
than
Linux, things
like Debian are quite a bit larger in scale.
I read a white paper on total development
cost of a
linux distro and
just remembered "linux". I think the distro
in
the paper was Fedora
9, which was estimated to be almost an order
of
magnitude more
expensive than the Linux kernel.
-Jonathan
.hc
> > -Jonathan > >> >> .hc >> >> >>> >>> -Jonathan >>> >>>> And >>>> anything assigned to
Miller and
reviewed
>> positively by >>>> IOhannes I'm >>>> going to defer any action
on until
Miller
>> responds. >>>> >>>> .hc >>>> >>>>> >>>>> -Jonathan >>>>> >>>>>> >>>>>> >>
>>>>>> Pd-list@iem.at >>>>>> mailing list >>>>>> UNSUBSCRIBE and
account-management
-> >> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>> >>>> >>>> >> >> >> >> >> >>
>> >> "[T]he greatest purveyor of
violence in
the world
today >> [is] my own government." - Martin
Luther
King,
Jr. >> >> >> >>
http://at.or.at/hans/
The arc of history bends towards justice.
- Dr. Martin Luther
King, Jr.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Jul 10, 2011, at 2:00 PM, Jonathan Wilkes wrote:
--- On Sun, 7/10/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PMOn Jul 9, 2011, at 8:07 PM, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner
wrote:
[...]
The problem with forks is if improvements
don't
migrate
upstream.
I think it's both a problem-with and a
cause-of.
Yup, that makes sense.
Then we don't benefit from sharing the fixes. Making things migrate
upstream takes
time in
itself.
How does one figure out who has the
responsibility to
make sure
things migrate upstream (for example:
[initbang] and
[closebang])?
Mostly by someone deciding its important enough
that they
want to work on it themself, and then lots of testing and communication.
Ok. So in patch id#2838176, what is Guenter's
idea for a clean
implementation of tooltips that you were referring
to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was, but I do have a vague idea of how to do it cleanly. I think it should be similar to the way its done in Max/MSP. Basically there is a standard function, something like nlet_info(), which returns the tooltip info.
Where would one define the standard function?
On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf
You can see the 'assist' message. The Max GUI sends the 'assist'
message to an objectclass when you hover above an inlet or outlet,
then its up to the objectclass to implement a function which copies
the text into a provider buffer. Then the Max GUI displays that text.
I guess we might as well just copy the interface of Max/MSP. It seems
very Max/Pd-ish, and straightforward.
Pd would then check whether an object had that function when it loaded the binary, and if so register it in the tooltips.
This brings up an issue I've been wondering about since learning a
little more about the canvas editor: why does the pd gui send
'motion' messages to pd? Why not, for example, just have a tag for
an inlet rectangle and bind <Enter> and <Leave> to it? Then you'd
only be sending messages from the gui for the events you care about,
instead of tons of "motion" messages that don't trigger anything.
I agree that the GUI should really handle the motion and guts of the
interaction, and 'pd' should just handle the logical messages like
"object selected".
The original design of Pd was to have as much of the logic in 'pd'
itself, for better or worse.
.hc
-Jonathan
.hc
Try getting a patch into the Linux
kernel,
that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the
core of
the largest
free software project in the history of
computing is a
wee bit more
difficult than making changes to Pd.
Actually, there are much bigger projects than
Linux, things
like Debian are quite a bit larger in scale.
I read a white paper on total development cost of a
linux distro and
just remembered "linux". I think the distro in
the paper was Fedora
9, which was estimated to be almost an order of
magnitude more
expensive than the Linux kernel.
-Jonathan
.hc
-Jonathan
.hc
> > -Jonathan > >> And >> anything assigned to Miller and
reviewed
positively by >> IOhannes I'm >> going to defer any action on until
Miller
responds. >> >> .hc >> >>> >>> -Jonathan >>> >>>> >>>>
>>>> Pd-list@iem.at >>>> mailing list >>>> UNSUBSCRIBE and
account-management
->
http://lists.puredata.info/listinfo/pd-list >>>> >>> >> >>
"[T]he greatest purveyor of violence in
the world
today
[is] my own government." - Martin Luther
King,
Jr.
http://at.or.at/hans/
The arc of history bends towards justice.
- Dr. Martin Luther
King, Jr.
"[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 Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Monday, July 11, 2011, 4:24 AM
On Jul 10, 2011, at 2:00 PM, Jonathan Wilkes wrote:
[...]
Where would one define the standard function?
On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf
You can see the 'assist' message.
If I'm understanding this correctly, "addmess" is analogous to class_addmethod (I guess if we made it standard, we could do class_addtooltip or something). But then this would break [list], for example, or any object that currently has an anything method defined. Or am I misunderstanding the model?
I mean, what happens in Max if the user happens to send the message "assist" to an inlet?
-Jonathan
The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, then its up to the objectclass to implement a function which copies the text into a provider buffer. Then the Max GUI displays that text.
I guess we might as well just copy the interface of Max/MSP. It seems very Max/Pd-ish, and straightforward.
Pd would then check whether an object had that function
when it
loaded the binary, and if so register it in the tooltips.
On Jul 11, 2011, at 12:01 AM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Monday, July 11, 2011, 4:24 AMOn Jul 10, 2011, at 2:00 PM, Jonathan Wilkes wrote:
[...]
Where would one define the standard function?
On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf
You can see the 'assist' message.
If I'm understanding this correctly, "addmess" is analogous to
class_addmethod (I guess if we made it standard, we could do
class_addtooltip or something). But then this would break [list],
for example, or any object that currently has an anything method
defined. Or am I misunderstanding the model?
Yes, addmess() is class_addmethod(). No need for a special function,
class_addmethod() would do it.
I mean, what happens in Max if the user happens to send the message
"assist" to an inlet?
Yeah, that would claim the message 'assist' in all objects. I just
did a quick survey of all objects in the pure-data SVN. None of them
use 'assist'.
.hc
-Jonathan
The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet, then its up to the objectclass to implement a function which copies the text into a provider buffer. Then the Max GUI displays that text.
I guess we might as well just copy the interface of Max/MSP. It seems very Max/Pd-ish, and straightforward.
Pd would then check whether an object had that function
when it
loaded the binary, and if so register it in the tooltips.
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)
On Sun, 10 Jul 2011, Hans-Christoph Steiner wrote:
On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. The Max GUI sends the 'assist' message to an objectclass when you hover above an inlet or outlet,
It's sent to the object, not to the objectclass.
It's similar to the "dsp" method in that it's a special method-entry registered with A_CANT, but otherwise it's the same : it's registered in the objectclass so that it's callable in the object. It's just not available from Max itself, as A_CANT means that its input is not a Max message.
I don't know anything about Max, but Max's addmess looks the same as Pd's class_addmethod, and A_CANT is exactly the same, and so are many other things when I browse around in that manual.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com, pd-list@iem.at Date: Monday, July 11, 2011, 4:30 PM On Sun, 10 Jul 2011, Hans-Christoph Steiner wrote:
On page 32 of this document: http://peabody.sapp.org/class/dmp2/read/WritingMax_MSPExternals.pdf You can see the 'assist' message. The Max GUI
sends the 'assist' message to an objectclass when you hover above an inlet or outlet,
It's sent to the object, not to the objectclass.
It's similar to the "dsp" method in that it's a special method-entry registered with A_CANT, but otherwise it's the same : it's registered in the objectclass so that it's callable in the object. It's just not available from Max itself, as A_CANT means that its input is not a Max message.
Does A_CANT actually work? If I do [dsp(---[+~] it crashes pd 0.43, and if I add a "foo" method to [bang] using A_CANT I can still send [foo(--[bang] and it will still run the method that I added.
Also, what if someone is parsing arbitrary sequences of anythings-- say, with [route] or any number of other objects that have an anything method? Now those objectclasses have to choose between truly accepting any selector, or being helpful and having a tooltip. Also problems with anything outlets: for instance, [textfile] (which I've mentioned before) outputs an anything, which could possibly start with whatever symbol you attach to tooltips, thus making that message practically unusable (though unlike say "float blah" you won't get an error message).
Unfortunately there are still lots of "anything operators" out there in the wild, and probably always will be, so I don't think it's a good idea to reserved a selector for a general feature like this.
Here's an idea:
- bind xlet rectangles to pdtk_tooltips for <Enter> and <Leave>
- have a menu checkbutton for "Turn on tooltips"
- if turned on, pdtk_tooltips sends the mouse location as args to canvas_tooltips (and whether we're entering or leaving)
- canvas_tooltips checks to see if there's a box under the mouse, and if there is and it has a tooltip string, display the text in a little rectangle on the canvas.
- on <Leave>, delete the tooltip.
But I'm not sure where to store the tooltip string...
-Jonathan
I don't know anything about Max, but Max's addmess looks the same as Pd's class_addmethod, and A_CANT is exactly the same, and so are many other things when I browse around in that manual.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip string...
Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Martin
On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip string...
Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever.
In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level.
But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that).
GF has its own parallel class-table for storing some meta-info, and C++'s «static members» for the rest.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On 2011-07-11 13:45, Mathieu Bouchard wrote:
On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip string...
Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever.
OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object will have allocated the memory for it.
In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level.
That is indeed what happens: a shared library has a section for strings (or "data"). Unless it is generating them on-the-fly, each instance of the class will refer to the same location in memory for its strings.
But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except GÃŒnter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that).
I don't see a need to extend any structs, Pd just needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets, and display the returned string inside a box. If there is no assist method, then Pd would use a default string from its own class, depending on what types were registered to that inlet/outlet at creation time.
Martin
On Jul 11, 2011, at 3:15 PM, Martin Peach wrote:
On 2011-07-11 13:45, Mathieu Bouchard wrote:
On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip string...
Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing the data
anywhere, or generating it on-the-fly from whatever.OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object
will have allocated the memory for it.In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called
at the object-level refer to a method-table stored at the class-level.That is indeed what happens: a shared library has a section for
strings (or "data"). Unless it is generating them on-the-fly, each
instance of the class will refer to the same location in memory for
its strings.
This leads to the question: should tooltip messages be per-instance or
per-class? It could easily just be a field with a standard name in
each object's struct, then it would be a simple per-class
implementation. Having an 'assist' method means that the external
writer can decide whether the string is per-class or per-instance.
But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that).
I don't see a need to extend any structs, Pd just needs to call an
object's assist method whenever the mouse is hovering over one of
its inlet/outlets, and display the returned string inside a box. If
there is no assist method, then Pd would use a default string from
its own class, depending on what types were registered to that inlet/ outlet at creation time.
I could see this whole thing happening when the object is drawn to the
screen. When an object is drawn, then it would just bind a
'show_tooltip {accepts float, symbol}' proc to each inlet/outlet's
rectangle. Then the tooltip message would only be sent across the pd
--> pd-gui network socket once, and there wouldn't be a need for
complicated lookups later to determine which instance to send the
'assist' message to. This would take more memory, but less CPU, and
would bother the core 'pd' process less. Since 'pd-gui' runs in a
separate process, that would mean offloading most of the work to the
lower priority 'pd-gui' process.
On Jul 11, 2011, at 2:43 PM, Jonathan Wilkes wrote:
I don't get the idea of having a new method that's supposed to be
hidden from the user (but really isn't) for every object that wants
tooltips; in some cases it would subtly change the function of the
object class, like [bang] and [route]. (Aside from crashing Pd,
"dsp" isn't such a big deal because there isn't much of a need for
an object that takes a signal AND parses arbitrary selectors, esp.
on the same inlet.) Maybe this wouldn't be a problem if [textfile] output lists, and there was a [routelist] in Pd vanilla...
This is an important point that Jonathan brings up: if we add an
'assist' method, that could mess up anything that ever sent a message
that started with 'assist'. One idea to work around this would be to
have the object just send the info to the GUI when it was drawn, like
above. This means the GUI would not need to send a message to 'pd' to
request the data, it would already be in the GUI. Then we don't need
to have a new 'assist' message.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom
On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
This leads to the question: should tooltip messages be per-instance or per-class? It could easily just be a field with a standard name in each object's struct, then it would be a simple per-class implementation. Having an 'assist' method means that the external writer can decide whether the string is per-class or per-instance.
Yes... whichever is appropriate. But the default assist-method should be designed so that in most cases, externals don't need to have a custom assist-method.
I don't see a need to extend any structs, Pd just needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets,
A default assist-method needs to be storing data somewhere, and it cannot automatically pickup inlet names from anywhere in an external's source code. It has to be stored in some data-structures... For example, in both t_class and t_inlet (for nonproxy inlets).
This is an important point that Jonathan brings up: if we add an 'assist' method, that could mess up anything that ever sent a message that started with 'assist'.
Then just do it like it is for savefn and propertiesfn. You see, it doesn't have to be something that goes through class_addmethod. The 'assist' symbol issue is not an argument against defining an assist-method because it could be a field named assistfn directly in t_class.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features To: "Hans-Christoph Steiner" hans@at.or.at Cc: "pd-list" pd-list@iem.at, "Martin Peach" martin.peach@sympatico.ca Date: Saturday, July 16, 2011, 6:11 PM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
This leads to the question: should tooltip messages be
per-instance or per-class? It could easily just be a field with a standard name in each object's struct, then it would be a simple per-class implementation. Having an 'assist' method means that the external writer can decide whether the string is per-class or per-instance.
Yes... whichever is appropriate. But the default assist-method should be designed so that in most cases, externals don't need to have a custom assist-method.
I don't see a need to extend any structs, Pd just
needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets,
A default assist-method needs to be storing data somewhere, and it cannot automatically pickup inlet names from anywhere in an external's source code. It has to be stored in some data-structures... For example, in both t_class and t_inlet (for nonproxy inlets).
Is it possible in c to parse a help file for "OUTLET_0 float symbol"? That's what I'm currently doing (which is trivial on the tcl side).
Actually the way I do it, you parse on the fly only when the mouse hovers over the xlet (which you could toggle with a menu button).
This is an important point that Jonathan brings up: if
we add an 'assist' method, that could mess up anything that ever sent a message that started with 'assist'.
Then just do it like it is for savefn and propertiesfn. You see, it doesn't have to be something that goes through class_addmethod. The 'assist' symbol issue is not an argument against defining an assist-method because it could be a field named assistfn directly in t_class.
What do I have to do to register a new "assistfn"? I don't really understand that part of the source code.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jul 16, 2011, at 5:59 PM, Jonathan Wilkes wrote:
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43
updates: lots of new editing features To: "Hans-Christoph Steiner" hans@at.or.at Cc: "pd-list" pd-list@iem.at, "Martin Peach" <martin.peach@sympatico.caDate: Saturday, July 16, 2011, 6:11 PM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
This leads to the question: should tooltip messages be
per-instance or per-class? It could easily just be a field with a standard name in each object's struct, then it would be a simple per-class implementation. Having an 'assist' method means that the external writer can decide whether the string is per-class or per-instance.
Yes... whichever is appropriate. But the default assist-method should be designed so that in most cases, externals don't need to have a custom assist-method.
I don't see a need to extend any structs, Pd just
needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets,
A default assist-method needs to be storing data somewhere, and it cannot automatically pickup inlet names from anywhere in an external's source code. It has to be stored in some data-structures... For example, in both t_class and t_inlet (for nonproxy inlets).
Is it possible in c to parse a help file for "OUTLET_0 float
symbol"? That's what I'm currently doing (which is trivial on the
tcl side).Actually the way I do it, you parse on the fly only when the mouse
hovers over the xlet (which you could toggle with a menu button).
Parsing text in C is definitely possible, just not fun. Its much
easier in Tcl.
This is an important point that Jonathan brings up: if
we add an 'assist' method, that could mess up anything that ever sent a message that started with 'assist'.
Then just do it like it is for savefn and propertiesfn. You see, it doesn't have to be something that goes through class_addmethod. The 'assist' symbol issue is not an argument against defining an assist-method because it could be a field named assistfn directly in t_class.
What do I have to do to register a new "assistfn"? I don't really
understand that part of the source code.
That would require adding the assistfn to the t_class structure.
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
--- On Sun, 7/17/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "pd-list" pd-list@iem.at, "Martin Peach" martin.peach@sympatico.ca Date: Sunday, July 17, 2011, 1:05 AM
On Jul 16, 2011, at 5:59 PM, Jonathan Wilkes wrote:
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] implementing tooltips WAS:
Pd-extended 0.43 updates: lots of new editing features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "pd-list" pd-list@iem.at,
"Martin Peach" martin.peach@sympatico.ca
Date: Saturday, July 16, 2011, 6:11 PM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
This leads to the question: should tooltip
messages be
per-instance or per-class? It could easily
just be a
field with a standard name in each object's
struct, then it
would be a simple per-class implementation.
Having an
'assist' method means that the external writer can
decide
whether the string is per-class or per-instance.
Yes... whichever is appropriate. But the default assist-method should be designed so that in most
cases,
externals don't need to have a custom
assist-method.
I don't see a need to extend any structs,
Pd just
needs to call an object's assist method whenever
the mouse
is hovering over one of its inlet/outlets,
A default assist-method needs to be storing data
somewhere,
and it cannot automatically pickup inlet names
from anywhere
in an external's source code. It has to be stored
in some
data-structures... For example, in both t_class
and t_inlet
(for nonproxy inlets).
Is it possible in c to parse a help file for "OUTLET_0
float symbol"? That's what I'm currently doing (which is trivial on the tcl side).
Actually the way I do it, you parse on the fly only
when the mouse hovers over the xlet (which you could toggle with a menu button).
Parsing text in C is definitely possible, just not fun. Its much easier in Tcl.
This is an important point that Jonathan
brings up: if
we add an 'assist' method, that could mess up
anything that
ever sent a message that started with 'assist'.
Then just do it like it is for savefn and
propertiesfn. You
see, it doesn't have to be something that goes
through
class_addmethod. The 'assist' symbol issue is not
an
argument against defining an assist-method because
it could
be a field named assistfn directly in t_class.
What do I have to do to register a new
"assistfn"? I don't really understand that part of the source code.
That would require adding the assistfn to the t_class structure.
Well, my current workaround is to create a binding for each xlet that holds "%W %x %y $xlettype $xletno [list $object_name] [list $object_dir] [list $helpname]". It's a prototype and obviously not very efficient (takes about 4 seconds to create 1000 [route 1 2 3 4 5 6 7 8 9] objects while unpatched pd takes about 3 seconds), but it's the only way I could figure out to get useful tooltips without redesigning the way the gui interacts with pd AND not add anything to t_class.
Actually maybe there's another way: just create 4 bindings-- 2 for <Enter>/<Leave> of tag "outlet" and 2 for tag "inlet"-- and create a canvas method "canvas_inlethover". Could actually create a binding for the object itself, too: canvas_objhover, which could be used to send "enter" and "leave" messages to a [struct] object for scalars... :)
-Jonathan
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Can I have a humble question please? Is it possible to extend [inlet] and [outlet] in a way that I can write [inlet foo] and [outlet bar] and 'foo' and 'bar' become the names of the xlets when no help file available? I still don't understand the depths of programming this so I'm just curious.
Andras
On Sun, 17 Jul 2011, András Murányi wrote:
Can I have a humble question please? Is it possible to extend [inlet] and [outlet] in a way that I can write [inlet foo] and [outlet bar] and 'foo' and 'bar' become the names of the xlets when no help file available? I still don't understand the depths of programming this so I'm just curious.
It's been already done in Günter's tooltips (2003) but it's conflicting with [inlet~]/[outlet~]'s upsampling/downsampling features added by Johannes Zmölnig some years later, which also use the $1 fields.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
2011/7/17 Mathieu Bouchard matju@artengine.ca
On Sun, 17 Jul 2011, András Murányi wrote:
Can I have a humble question please? Is it possible to extend [inlet] and
[outlet] in a way that I can write [inlet foo] and [outlet bar] and 'foo' and 'bar' become the names of the xlets when no help file available? I still don't understand the depths of programming this so I'm just curious.
It's been already done in Günter's tooltips (2003) but it's conflicting with [inlet~]/[outlet~]'s upsampling/downsampling features added by Johannes Zmölnig some years later, which also use the $1 fields.
OK, I see.
Thanks, Andras
[inlet~] and [outlet~] already take the args "hold" and "lin" for upsampling/downsampling.
-Jonathan
--- On Sun, 7/17/11, András Murányi muranyia@gmail.com wrote:
From: András Murányi muranyia@gmail.com Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features To: "PD List" pd-list@iem.at Date: Sunday, July 17, 2011, 4:30 PM
Can I have a humble question please? Is it possible to extend [inlet] and [outlet] in a way that I can write [inlet foo] and [outlet bar] and 'foo' and 'bar' become the names of the xlets when no help file available?
I still don't understand the depths of programming this so I'm just curious.
Andras
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So does adding to struct _widgetbehavior count as adding to t_class?
--- On Sun, 7/17/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] implementing tooltips WAS: Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "pd-list" pd-list@iem.at, "Martin Peach" martin.peach@sympatico.ca Date: Sunday, July 17, 2011, 1:05 AM
On Jul 16, 2011, at 5:59 PM, Jonathan Wilkes wrote:
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] implementing tooltips WAS:
Pd-extended 0.43 updates: lots of new editing features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "pd-list" pd-list@iem.at,
"Martin Peach" martin.peach@sympatico.ca
Date: Saturday, July 16, 2011, 6:11 PM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
This leads to the question: should tooltip
messages be
per-instance or per-class? It could easily
just be a
field with a standard name in each object's
struct, then it
would be a simple per-class implementation.
Having an
'assist' method means that the external writer can
decide
whether the string is per-class or per-instance.
Yes... whichever is appropriate. But the default assist-method should be designed so that in most
cases,
externals don't need to have a custom
assist-method.
I don't see a need to extend any structs,
Pd just
needs to call an object's assist method whenever
the mouse
is hovering over one of its inlet/outlets,
A default assist-method needs to be storing data
somewhere,
and it cannot automatically pickup inlet names
from anywhere
in an external's source code. It has to be stored
in some
data-structures... For example, in both t_class
and t_inlet
(for nonproxy inlets).
Is it possible in c to parse a help file for "OUTLET_0
float symbol"? That's what I'm currently doing (which is trivial on the tcl side).
Actually the way I do it, you parse on the fly only
when the mouse hovers over the xlet (which you could toggle with a menu button).
Parsing text in C is definitely possible, just not fun. Its much easier in Tcl.
This is an important point that Jonathan
brings up: if
we add an 'assist' method, that could mess up
anything that
ever sent a message that started with 'assist'.
Then just do it like it is for savefn and
propertiesfn. You
see, it doesn't have to be something that goes
through
class_addmethod. The 'assist' symbol issue is not
an
argument against defining an assist-method because
it could
be a field named assistfn directly in t_class.
What do I have to do to register a new
"assistfn"? I don't really understand that part of the source code.
That would require adding the assistfn to the t_class structure.
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Wed, 20 Jul 2011, Jonathan Wilkes wrote:
So does adding to struct _widgetbehavior count as adding to t_class?
According to whom ? Well, if you want permission from Miller, you have to ask Miller, and not anyone else.
Well, assistfn wouldn't be out of place in t_widgetbehavior, in terms of what it's for, though I wouldn't be able to tell you either why is c_propertiesfn outside of t_widgetbehavior. However, I can picture c_savefn being used outside of a GUI.
BTW, c_blobmethod was added to t_class by Martin Peach and merged into pd-extended 42 a while ago.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, 16 Jul 2011, Jonathan Wilkes wrote:
Is it possible in c to parse a help file for "OUTLET_0 float symbol"? That's what I'm currently doing (which is trivial on the tcl side).
Pd is written in C.
Use the binbuf_text() function to parse Pd files.
Pd file parsing is not necessarily trivial on the tcl side. It depends on whether you want to accept the files that Pd can produce, or the files that Pd can accept. The only non-C-based parser that accepts the same thing that Miller's parser accepts, is DesireData's Tcl-based parser.
But for files saved using Pd, it might not make much of a difference, as Pd can't save spaces in symbols correctly, anyway (Pd's parser is better than Pd's unparser).
What do I have to do to register a new "assistfn"? I don't really understand that part of the source code.
I mean add a new field in t_class, just like savefn is one, and add functions to edit it, just like savefn has.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Jul 16, 2011, at 12:11 PM, Mathieu Bouchard wrote:
On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
This leads to the question: should tooltip messages be per-instance
or per-class? It could easily just be a field with a standard name
in each object's struct, then it would be a simple per-class
implementation. Having an 'assist' method means that the external
writer can decide whether the string is per-class or per-instance.Yes... whichever is appropriate. But the default assist-method
should be designed so that in most cases, externals don't need to
have a custom assist-method.I don't see a need to extend any structs, Pd just needs to call an
object's assist method whenever the mouse is hovering over one of
its inlet/outlets,A default assist-method needs to be storing data somewhere, and it
cannot automatically pickup inlet names from anywhere in an
external's source code. It has to be stored in some data- structures... For example, in both t_class and t_inlet (for nonproxy
inlets).This is an important point that Jonathan brings up: if we add an
'assist' method, that could mess up anything that ever sent a
message that started with 'assist'.Then just do it like it is for savefn and propertiesfn. You see, it
doesn't have to be something that goes through class_addmethod. The
'assist' symbol issue is not an argument against defining an assist- method because it could be a field named assistfn directly in t_class.
If you care about getting it into Vanilla, then Miller said he didn't
like modifying t_class. But I suppose someone could lobby him to
change his mind.
.hc
Access to computers should be unlimited and total. - the hacker ethic
On Sat, 16 Jul 2011, Hans-Christoph Steiner wrote:
If you care about getting it into Vanilla, then Miller said he didn't like modifying t_class. But I suppose someone could lobby him to change his mind.
The Pd community surely has plenty of non-matjus who can take care of that.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 7/11/11, Martin Peach martin.peach@sympatico.ca wrote:
From: Martin Peach martin.peach@sympatico.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Mathieu Bouchard" matju@artengine.ca Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 9:15 PM On 2011-07-11 13:45, Mathieu Bouchard wrote:
On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip
string...
Not sure if that's what you mean, but in max the
assist method
receives a number corresponding to the inlet or
outlet and returns a
pointer to the appropriate string, so the string
is already stored
somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing
the data anywhere,
or generating it on-the-fly from whatever.
OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object will have allocated the memory for it.
In theory, tooltip strings could be stored in
something at the
class-level instead of the object-level, just like
methods called at the
object-level refer to a method-table stored at the
class-level.
That is indeed what happens: a shared library has a section for strings (or "data"). Unless it is generating them on-the-fly, each instance of the class will refer to the same location in memory for its strings.
But Pd doesn't allow extending struct t_class by
externals, and it
doesn't have a tooltip field (except Günter's tooltip
diff included a
field for storing a symbol containing the text of the
left-inlet's
text... and only that).
I don't see a need to extend any structs, Pd just needs to call an object's assist method whenever the mouse is hovering over one of its inlet/outlets, and display the returned string inside a box. If there is no assist method, then Pd would use a default string from its own class, depending on what types were registered to that inlet/outlet at creation time.
Well in that case, I don't see any need whatsoever for an "assist" method. Just have pd lookup the methods and display them. If one needs more information than that, the help patch is just two clicks away.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 11 Jul 2011, Jonathan Wilkes wrote:
Well in that case, I don't see any need whatsoever for an "assist" method. Just have pd lookup the methods and display them. If one needs more information than that, the help patch is just two clicks away.
That'll be great for learning GridFlow, as all it'll ever say is :
anything
because GridFlow has its own method-lookup system. That's one example of what an assist-method slot could help with. This is also usually the way that methods are registered in pd bindings for lua, tcl, and probably several more.
Another totally different example is what you're supposed to do to hide kludges like the bunch of methods registered under the name "ft1" that exist because pd's internals make it easier to that than to have non-first inlets act independently of first-inlets.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Thu, 7/14/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Thursday, July 14, 2011, 3:51 AM On Mon, 11 Jul 2011, Jonathan Wilkes wrote:
Well in that case, I don't see any need whatsoever for
an "assist" method. Just have pd lookup the methods and display them. If one needs more information than that, the help patch is just two clicks away.
That'll be great for learning GridFlow, as all it'll ever say is :
anything
I'm not doing it that way. I'm looking up the xlet info in the help patch in [pd META] when the xlet is created, then putting the relevant text as an argument to the command that gets "bind"ed to the xlet tag's <Enter> and <Leave> events.
because GridFlow has its own method-lookup system. That's one example of what an assist-method slot could help with. This is also usually the way that methods are registered in pd bindings for lua, tcl, and probably several more.
Better to just add a few lines of tcl to gather the relevant info from your help docs.
Another totally different example is what you're supposed to do to hide kludges like the bunch of methods registered under the name "ft1" that exist because pd's internals make it easier to that than to have non-first inlets act independently of first-inlets.
I can't remember whether I put those in the [pd META] stuff-- but I don't think I did.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Wed, 13 Jul 2011, Jonathan Wilkes wrote:
I'm not doing it that way. I'm looking up the xlet info in the help patch in [pd META] when the xlet is created, then putting the relevant text as an argument to the command that gets "bind"ed to the xlet tag's <Enter> and <Leave> events. Better to just add a few lines of tcl to gather the relevant info from your help docs.
I wonder whether there might be any other reasons to have an assist-method in a way that can't be done in any other way. What are the possible use for the tooltips ?
Tell the name of the inlet. This is not an info already present in the class, and usually not in the docs either.
Tell the list of methods.
Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet).
Other. (which uses ?)
I think that you are mostly only thinking about #2, and Günter's system was only taking care of #1, and I think that there was a pd-list discussion about something like #3 a long time ago.
I don't know what's available in MAX, and I don't think that it necessarily has to be implemented in the same way.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Saturday, July 16, 2011, 5:54 PM On Wed, 13 Jul 2011, Jonathan Wilkes wrote:
I'm not doing it that way. I'm looking up the
xlet info in the help patch in [pd META] when the xlet is created, then putting the relevant text as an argument to the command that gets "bind"ed to the xlet tag's <Enter> and <Leave> events.
Better to just add a few lines of tcl to gather the
relevant info from your help docs.
I wonder whether there might be any other reasons to have an assist-method in a way that can't be done in any other way. What are the possible use for the tooltips ?
1. Tell the name of the inlet. This is not an info already present in the class, and usually not in the docs either.
My tooltips do that.
2. Tell the list of methods.
My tooltips do that.
3. Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet).
If this is desired, then it's probably better to do everything except draw the tooltip window on the c side.
4. Other. (which uses ?)
That's plenty. The only thing that sucks harder than being annoyed by tooltips is being annoyed by gigantic tooltips <-[gigantic tooltips have lots and lots and lots of text inside them. They were designed by geniuses who think that informative paragraphs of text are important enough to interrupt the main interface view, yet ephemeral enough that a single accidental mouse movement of 2 pixels can cause the whole tooltip to].
I think that you are mostly only thinking about #2, and Günter's system was only taking care of #1, and I think that there was a pd-list discussion about something like #3 a long time ago.
I don't know what's available in MAX, and I don't think that it necessarily has to be implemented in the same way.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, 16 Jul 2011, Jonathan Wilkes wrote:
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca wrote:
3. Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet).
If this is desired, then it's probably better to do everything except draw the tooltip window on the c side.
Why ?
That's plenty. The only thing that sucks harder than being annoyed by tooltips is being annoyed by gigantic tooltips <-[gigantic tooltips have lots and lots and lots of text inside them. They were designed by geniuses who think that informative paragraphs of text are important enough to interrupt the main interface view, yet ephemeral enough that a single accidental mouse movement of 2 pixels can cause the whole tooltip to].
Well, «tooltips» don't have to be implemented as bad as you describe, and for example, they don't have to be necessarily tooltips, and they don't have to display information that the user doesn't want to see.
Thus there can be features to display that info differently than as tooltips : statusbar, sidebar, or tooltip-like boxes that don't necessarily activate on <Enter> or don't necessarily deactivate on <Leave>. Implement whatever is comfortable and useful.
What would be a good way to toggle «enable inlet name tooltips», «enable method-list tooltips», etc., as separate settings ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Sun, 7/17/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Sunday, July 17, 2011, 8:22 PM On Sat, 16 Jul 2011, Jonathan Wilkes wrote:
--- On Sat, 7/16/11, Mathieu Bouchard matju@artengine.ca
wrote:
3. Tell the value last put in an inlet, if
it's
currently stored (and if the concept makes sense for that particular inlet).
If this is desired, then it's probably better to do
everything except draw the tooltip window on the c side.
Why ?
That's plenty. The only thing that sucks harder
than being annoyed by tooltips is being annoyed by gigantic tooltips <-[gigantic tooltips have lots and lots and lots of text inside them. They were designed by geniuses who think that informative paragraphs of text are important enough to interrupt the main interface view, yet ephemeral enough that a single accidental mouse movement of 2 pixels can cause the whole tooltip to].
Well, «tooltips» don't have to be implemented as bad as you describe, and for example, they don't have to be necessarily tooltips, and they don't have to display information that the user doesn't want to see.
Thus there can be features to display that info differently than as tooltips : statusbar, sidebar, or tooltip-like boxes that don't necessarily activate on <Enter> or don't necessarily deactivate on <Leave>. Implement whatever is comfortable and useful.
What would be a good way to toggle «enable inlet name tooltips», «enable method-list tooltips», etc., as separate settings ?
Probably just a drop-down list in a menu.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Jul 16, 2011, at 11:54 AM, Mathieu Bouchard wrote:
On Wed, 13 Jul 2011, Jonathan Wilkes wrote:
I'm not doing it that way. I'm looking up the xlet info in the
help patch in [pd META] when the xlet is created, then putting the
relevant text as an argument to the command that gets "bind"ed to
the xlet tag's <Enter> and <Leave> events. Better to just add a few lines of tcl to gather the relevant info
from your help docs.I wonder whether there might be any other reasons to have an assist- method in a way that can't be done in any other way. What are the
possible use for the tooltips ?
Tell the name of the inlet. This is not an info already present in the class, and usually not in the docs either.
Tell the list of methods.
Tell the value last put in an inlet, if it's currently stored (and if the concept makes sense for that particular inlet).
The magicglass functionality does this, but doesn't show the stored
value, only the message as it passes. I suppose it would be nice to
see a stored value in an inlet...
.hc
- Other. (which uses ?)
I think that you are mostly only thinking about #2, and Günter's
system was only taking care of #1, and I think that there was a pd- list discussion about something like #3 a long time ago.I don't know what's available in MAX, and I don't think that it
necessarily has to be implemented in the same way.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray,
Montréal, QC_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds
On Mon, 11 Jul 2011, Martin Peach wrote:
OK, but the object is responsible for knowing where it is, not Pd. If the string is generated on-the-fly or stored elsewhere the object will have allocated the memory for it.
Well, if pd has a default assist-method, externals might need a way to give info to that assist-method so that it can do its own work. That would be in t_class and in t_inlet.
In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level.
That is indeed what happens: a shared library has a section for strings (or "data"). Unless it is generating them on-the-fly, each instance of the class will refer to the same location in memory for its strings.
I mean exactly what I write, something at the class-level, not something at the executable-level. That's because I'm thinking about a default assist-method.
If there is no assist method, then Pd would use a default string from its own class, depending on what types were registered to that inlet/outlet at creation time.
There are several different purposes for the assist-method. Naming inlets is one. Listing methods of an inlet is another. There are others. We have to decide which such features we want to support, and then we will be able to figure out what we need to add in t_class.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Martin Peach" martin.peach@sympatico.ca Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip
string...
Not sure if that's what you mean, but in max the
assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever.
Hm...
1 when creating an xlet for the first time, bind its tag on <Enter> and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments
2 in tcl, search helppath for $object_name-help.pd, then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too)
3 filter the matching line in tcl to display everything after $inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float symbol bang;" becomes "float symbol bang")
4 create that text on a little tooltip rectangle on $canvas; delete it on <Leave>
All you add on the pd side is a sys_gui call to create the binding, then handle everything else on the tcl side.
Does that make sense? If so, then once someone gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like "list split", and variable/rightmost inlets which I'm not sure how to handle...)
Also doesn't address tooltips for abstractions.
-Jonathan
In theory, tooltip strings could be stored in something at the class-level instead of the object-level, just like methods called at the object-level refer to a method-table stored at the class-level.
But Pd doesn't allow extending struct t_class by externals, and it doesn't have a tooltip field (except Günter's tooltip diff included a field for storing a symbol containing the text of the left-inlet's text... and only that).
GF has its own parallel class-table for storing some meta-info, and C++'s «static members» for the rest.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Martin Peach" martin.peach@sympatico.ca Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote:On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip
string...
Not sure if that's what you mean, but in max the
assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever.
Hm...
1 when creating an xlet for the first time, bind its tag on <Enter>
and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and
$object_name as arguments2 in tcl, search helppath for $object_name-help.pd, then parse it
for $inletno (which I added as a pd META tag for every internal help
patch-- plus lots of externals, too)3 filter the matching line in tcl to display everything after
$inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float
symbol bang;" becomes "float symbol bang")4 create that text on a little tooltip rectangle on $canvas; delete
it on <Leave>All you add on the pd side is a sys_gui call to create the binding,
then handle everything else on the tcl side.Does that make sense? If so, then once someone gets it working
(maybe me), you'd not only have tooltips, but you'd have tooltip
content for over 1000 object classes (minus exceptions like "list
split", and variable/rightmost inlets which I'm not sure how to
handle...)Also doesn't address tooltips for abstractions.
-Jonathan
I like this idea quite a bit. If the tooltip info is stored in a help
patch, then we have a single way of specifying the tooltip info
regardless if the object was written in C, Pd, Lua, etc. The downside
will be a lot more file parsing on load. Perhaps we can do some kind
of low priority thread kind of thing in Tcl to do that loading.
One detail, instead of searching the path for the help patch, really
we should try to get the full path of the object in question, then use
that to get the help patch...
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
--- On Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "Mathieu Bouchard" matju@artengine.ca, "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 11:18 PM
On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing features
To: "Martin Peach" martin.peach@sympatico.ca Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the
tooltip
string...
Not sure if that's what you mean, but in max
the
assist method receives a number corresponding to
the inlet
or outlet and returns a pointer to the appropriate
string,
so the string is already stored somewhere in the
memory
allocated to the object.
Not necessarily : the assist-method could be
storing the
data anywhere, or generating it on-the-fly from
whatever.
Hm...
1 when creating an xlet for the first time, bind its
tag on <Enter> and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments
2 in tcl, search helppath for $object_name-help.pd,
then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too)
3 filter the matching line in tcl to display
everything after $inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float symbol bang;" becomes "float symbol bang")
4 create that text on a little tooltip rectangle on
$canvas; delete it on <Leave>
All you add on the pd side is a sys_gui call to create
the binding, then handle everything else on the tcl side.
Does that make sense? If so, then once someone
gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like "list split", and variable/rightmost inlets which I'm not sure how to handle...)
Also doesn't address tooltips for abstractions.
-Jonathan
I like this idea quite a bit. If the tooltip info is stored in a help patch, then we have a single way of specifying the tooltip info regardless if the object was written in C, Pd, Lua, etc. The downside will be a lot more file parsing on load. Perhaps we can do some kind of low priority thread kind of thing in Tcl to do that loading.
One detail, instead of searching the path for the help patch, really we should try to get the full path of the object in question, then use that to get the help patch...
Ok. Is c_helpname guaranteed to be inside c_externdir?
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Jul 11, 2011, at 5:35 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates:
lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "Mathieu Bouchard" <matju@artengine.ca, "pd-list" pd-list@iem.at
Date: Monday, July 11, 2011, 11:18 PM
On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing features
To: "Martin Peach" martin.peach@sympatico.ca Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the
tooltip
string...
Not sure if that's what you mean, but in max
the
assist method receives a number corresponding to
the inlet
or outlet and returns a pointer to the appropriate
string,
so the string is already stored somewhere in the
memory
allocated to the object.
Not necessarily : the assist-method could be
storing the
data anywhere, or generating it on-the-fly from
whatever.
Hm...
1 when creating an xlet for the first time, bind its
tag on <Enter> and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments
2 in tcl, search helppath for $object_name-help.pd,
then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too)
3 filter the matching line in tcl to display
everything after $inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float symbol bang;" becomes "float symbol bang")
4 create that text on a little tooltip rectangle on
$canvas; delete it on <Leave>
All you add on the pd side is a sys_gui call to create
the binding, then handle everything else on the tcl side.
Does that make sense? If so, then once someone
gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like "list split", and variable/rightmost inlets which I'm not sure how to handle...)
Also doesn't address tooltips for abstractions.
-Jonathan
I like this idea quite a bit. If the tooltip info is stored in a help patch, then we have a single way of specifying the tooltip info regardless if the object was written in C, Pd, Lua, etc. The downside will be a lot more file parsing on load. Perhaps we can do some kind of low priority thread kind of thing in Tcl to do that loading.
One detail, instead of searching the path for the help patch, really we should try to get the full path of the object in question, then use that to get the help patch...
Ok. Is c_helpname guaranteed to be inside c_externdir?
I can't remember ever using c_helpname, so I can't really say.
IMHO, I don't think we should support other ways of specifying the
help file. There are very few objects that use it, those are fixed in
Pd-extended, it'll add a lot to the work of doing this, etc. etc. So
I say just take the object name and add the '-help' to it. That
covers 99.5% of objects. Then once its working, it should be possible
to go back and add hacks to support hacks ;)
.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 Mon, Jul 11, 2011 at 23:50, Hans-Christoph Steiner hans@at.or.at wrote:
On Jul 11, 2011, at 5:35 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at
Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "Mathieu Bouchard" < matju@artengine.ca>, "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 11:18 PM
On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca
Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing features
To: "Martin Peach" martin.peach@sympatico.ca
Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote:
On 2011-07-11 12:06, Jonathan Wilkes wrote:
> But I'm not sure where to store the > tooltip
string...
Not sure if that's what you mean, but in max
the
assist method receives a number corresponding to
the inlet
or outlet and returns a pointer to the appropriate
string,
so the string is already stored somewhere in the
memory
allocated to the object.
Not necessarily : the assist-method could be
storing the
data anywhere, or generating it on-the-fly from
whatever.
Hm...
1 when creating an xlet for the first time, bind its
tag on <Enter> and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments
2 in tcl, search helppath for $object_name-help.pd,
then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too)
3 filter the matching line in tcl to display
everything after $inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float symbol bang;" becomes "float symbol bang")
4 create that text on a little tooltip rectangle on
$canvas; delete it on <Leave>
All you add on the pd side is a sys_gui call to create
the binding, then handle everything else on the tcl side.
Does that make sense? If so, then once someone
gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like "list split", and variable/rightmost inlets which I'm not sure how to handle...)
Also doesn't address tooltips for abstractions.
-Jonathan
I like this idea quite a bit. If the tooltip info is stored in a help patch, then we have a single way of specifying the tooltip info regardless if the object was written in C, Pd, Lua, etc. The downside will be a lot more file parsing on load. Perhaps we can do some kind of low priority thread kind of thing in Tcl to do that loading.
One detail, instead of searching the path for the help patch, really we should try to get the full path of the object in question, then use that to get the help patch...
Ok. Is c_helpname guaranteed to be inside c_externdir?
I can't remember ever using c_helpname, so I can't really say.
IMHO, I don't think we should support other ways of specifying the help file. There are very few objects that use it, those are fixed in Pd-extended, it'll add a lot to the work of doing this, etc. etc. So I say just take the object name and add the '-help' to it. That covers 99.5% of objects. Then once its working, it should be possible to go back and add hacks to support hacks ;)
.hc
Am I getting right, that this logic could be applied to abstraction xlets too? How cool... I don't know much about the new help file system, but I know it's well thought out, so I'm just asking very carefully: could it be it possible to allow abstractions to contain their own META tags (in case there's no help file)? That would make things even easier (+ less files).
Andras
On Jul 11, 2011, at 6:09 PM, András Murányi wrote:
On Mon, Jul 11, 2011 at 23:50, Hans-Christoph Steiner
hans@at.or.at wrote:On Jul 11, 2011, at 5:35 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates:
lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "Mathieu Bouchard" <matju@artengine.ca, "pd-list" pd-list@iem.at
Date: Monday, July 11, 2011, 11:18 PM
On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Martin Peach" martin.peach@sympatico.ca Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote: On 2011-07-11 12:06, Jonathan Wilkes wrote: But I'm not sure where to store the tooltip string...
Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Not necessarily : the assist-method could be storing the data anywhere, or generating it on-the-fly from whatever.
Hm...
1 when creating an xlet for the first time, bind its tag on <Enter> and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments
2 in tcl, search helppath for $object_name-help.pd, then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too)
3 filter the matching line in tcl to display everything after $inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float symbol bang;" becomes "float symbol bang")
4 create that text on a little tooltip rectangle on $canvas; delete it on <Leave>
All you add on the pd side is a sys_gui call to create the binding, then handle everything else on the tcl side.
Does that make sense? If so, then once someone gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like "list split", and variable/rightmost inlets which I'm not sure how to handle...)
Also doesn't address tooltips for abstractions.
-Jonathan
I like this idea quite a bit. If the tooltip info is stored in a help patch, then we have a single way of specifying the tooltip info regardless if the object was written in C, Pd, Lua, etc. The downside will be a lot more file parsing on load. Perhaps we can do some kind of low priority thread kind of thing in Tcl to do that loading.
One detail, instead of searching the path for the help patch, really we should try to get the full path of the object in question, then use that to get the help patch...
Ok. Is c_helpname guaranteed to be inside c_externdir?
I can't remember ever using c_helpname, so I can't really say.
IMHO, I don't think we should support other ways of specifying the
help file. There are very few objects that use it, those are fixed
in Pd-extended, it'll add a lot to the work of doing this, etc.
etc. So I say just take the object name and add the '-help' to it.
That covers 99.5% of objects. Then once its working, it should be
possible to go back and add hacks to support hacks ;).hc
Am I getting right, that this logic could be applied to abstraction
xlets too? How cool... I don't know much about the new help file system, but I know it's
well thought out, so I'm just asking very carefully: could it be it
possible to allow abstractions to contain their own META tags (in
case there's no help file)? That would make things even easier (+
less files).
Why not just keep it in the helpfile? Its super easy to make help
files, and its a good habit even for your own projects. If we have to
parse both abstractions and help files, that means a lot more parsing,
making the system even slower.
.hc
There is no way to peace, peace is the way. -A.J. Muste
2011/7/12 Hans-Christoph Steiner hans@at.or.at
On Jul 11, 2011, at 6:09 PM, András Murányi wrote:
On Mon, Jul 11, 2011 at 23:50, Hans-Christoph Steiner hans@at.or.atwrote:
On Jul 11, 2011, at 5:35 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at
Subject: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Martin Peach" martin.peach@sympatico.ca, "Mathieu Bouchard" < matju@artengine.ca>, "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 11:18 PM
On Jul 11, 2011, at 3:58 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca
Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing features
To: "Martin Peach" martin.peach@sympatico.ca
Cc: "pd-list" pd-list@iem.at Date: Monday, July 11, 2011, 7:45 PM On Mon, 11 Jul 2011, Martin Peach wrote:
> On 2011-07-11 12:06, Jonathan Wilkes wrote: > >> But I'm not sure where to store the >> > tooltip
string...
> > Not sure if that's what you mean, but in max > the
assist method receives a number corresponding to
the inlet
or outlet and returns a pointer to the appropriate
string,
so the string is already stored somewhere in the
memory
allocated to the object.
Not necessarily : the assist-method could be
storing the
data anywhere, or generating it on-the-fly from
whatever.
Hm...
1 when creating an xlet for the first time, bind its
tag on <Enter> and <Leave> to call pdtk_tooltips, and send $canvas, $inletno and $object_name as arguments
2 in tcl, search helppath for $object_name-help.pd,
then parse it for $inletno (which I added as a pd META tag for every internal help patch-- plus lots of externals, too)
3 filter the matching line in tcl to display
everything after $inletno minus the semicolon. (I.e., "text 20 20 INLET_0 float symbol bang;" becomes "float symbol bang")
4 create that text on a little tooltip rectangle on
$canvas; delete it on <Leave>
All you add on the pd side is a sys_gui call to create
the binding, then handle everything else on the tcl side.
Does that make sense? If so, then once someone
gets it working (maybe me), you'd not only have tooltips, but you'd have tooltip content for over 1000 object classes (minus exceptions like "list split", and variable/rightmost inlets which I'm not sure how to handle...)
Also doesn't address tooltips for abstractions.
-Jonathan
I like this idea quite a bit. If the tooltip info is stored in a help patch, then we have a single way of specifying the tooltip info regardless if the object was written in C, Pd, Lua, etc. The downside will be a lot more file parsing on load. Perhaps we can do some kind of low priority thread kind of thing in Tcl to do that loading.
One detail, instead of searching the path for the help patch, really we should try to get the full path of the object in question, then use that to get the help patch...
Ok. Is c_helpname guaranteed to be inside c_externdir?
I can't remember ever using c_helpname, so I can't really say.
IMHO, I don't think we should support other ways of specifying the help file. There are very few objects that use it, those are fixed in Pd-extended, it'll add a lot to the work of doing this, etc. etc. So I say just take the object name and add the '-help' to it. That covers 99.5% of objects. Then once its working, it should be possible to go back and add hacks to support hacks ;)
.hc
Am I getting right, that this logic could be applied to abstraction xlets too? How cool... I don't know much about the new help file system, but I know it's well thought out, so I'm just asking very carefully: could it be it possible to allow abstractions to contain their own META tags (in case there's no help file)? That would make things even easier (+ less files).
Why not just keep it in the helpfile? Its super easy to make help files, and its a good habit even for your own projects. If we have to parse both abstractions and help files, that means a lot more parsing, making the system even slower.
.hc
As Matju pointed out, abstractions' help file is canvas-help.pd. Other things to advocate my suggestion:
- Patches themselves are parsed anyway, CPU will only be needed to look up
the META elements.
- The overwhelming majority of abstractions is self-documented at the moment
(also because of the before mentioned canvas-help functionality). So I could still imagine this logic:
- If the object is an abstraction, its parsed content gets searched for META
elements first.
- If no META stuff found, *maybe* myabstaction-help.pd is checked if exists
(and then parsed etc.).
Andras
On Tue, 12 Jul 2011, András Murányi wrote:
As Matju pointed out, abstractions' help file is canvas-help.pd.
No, Jonathan is the one who said it.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
IMHO, I don't think we should support other ways of specifying the help file. There are very few objects that use it, those are fixed in Pd-extended, it'll add a lot to the work of doing this, etc. etc. So I say just take the object name and add the '-help' to it. That covers 99.5% of objects. Then once its working, it should be possible to go back and add hacks to support hacks ;)
c_helpname is not a hack, it doesn't need to be «fixed», and it shouldn't be «fixed». It's there for a reason.
If I right-click help on a [*~] box, will it try to get *~-help.pd, which is not an allowed filename on win32 ?
What could hexloader possibly do about this ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
IMHO, I don't think we should support other ways of
specifying the help file. There are very few objects that use it, those are fixed in Pd-extended, it'll add a lot to the work of doing this, etc. etc. So I say just take the object name and add the '-help' to it. That covers 99.5% of objects. Then once its working, it should be possible to go back and add hacks to support hacks ;)
c_helpname is not a hack, it doesn't need to be «fixed», and it shouldn't be «fixed». It's there for a reason.
One thing I'm running into is that c_helpname doesn't help with abstractions-- it obviously just returns "canvas". I guess I could then compare to the first atom in te_binbuf and if it's not "pd" then it's the name of the abstraction. But that still doesn't get me the dir.
-Jonathan
If I right-click help on a [*~] box, will it try to get *~-help.pd, which is not an allowed filename on win32 ?
What could hexloader possibly do about this ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Jul 11, 2011, at 10:03 PM, Jonathan Wilkes wrote:
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43
updates: lots of new editing features To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com, "Martin Peach" <martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
IMHO, I don't think we should support other ways of
specifying the help file. There are very few objects that use it, those are fixed in Pd-extended, it'll add a lot to the work of doing this, etc. etc. So I say just take the object name and add the '-help' to it. That covers 99.5% of objects. Then once its working, it should be possible to go back and add hacks to support hacks ;)
c_helpname is not a hack, it doesn't need to be «fixed», and it shouldn't be «fixed». It's there for a reason.
One thing I'm running into is that c_helpname doesn't help with
abstractions-- it obviously just returns "canvas". I guess I could
then compare to the first atom in te_binbuf and if it's not "pd"
then it's the name of the abstraction. But that still doesn't get
me the dir.
You could look for the standard help patch location first, and if that
fails, use c_helpname to solve the issue that Matju brought up.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 4:40 AM
On Jul 11, 2011, at 10:03 PM, Jonathan Wilkes wrote:
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS: [PD]
Pd-extended 0.43 updates: lots of new editing features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
IMHO, I don't think we should support other
ways of
specifying the help file. There are very few
objects that
use it, those are fixed in Pd-extended, it'll add
a lot to
the work of doing this, etc. etc. So I say
just take
the object name and add the '-help' to it.
That covers
99.5% of objects. Then once its working, it
should be
possible to go back and add hacks to support hacks
;)
c_helpname is not a hack, it doesn't need to be
«fixed»,
and it shouldn't be «fixed». It's there for a
reason.
One thing I'm running into is that c_helpname doesn't
help with abstractions-- it obviously just returns "canvas". I guess I could then compare to the first atom in te_binbuf and if it's not "pd" then it's the name of the abstraction. But that still doesn't get me the dir.
You could look for the standard help patch location first, and if that fails, use c_helpname to solve the issue that Matju brought up.
That still doesn't help with abstractions, because c_helpname is still "canvas".
Additionally, internal objects don't have a c_externdir in 0.43 vanilla, but I guess even the vanilla objects are going to be in their own lib so that won't matter going forward, right?
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Mon, 11 Jul 2011 19:57 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 4:40 AM
On Jul 11, 2011, at 10:03 PM, Jonathan Wilkes wrote:
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS: [PD]
Pd-extended 0.43 updates: lots of new editing features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
IMHO, I don't think we should support other
ways of
specifying the help file. There are very few
objects that
use it, those are fixed in Pd-extended, it'll add
a lot to
the work of doing this, etc. etc. So I say
just take
the object name and add the '-help' to it.
That covers
99.5% of objects. Then once its working, it
should be
possible to go back and add hacks to support hacks
;)
c_helpname is not a hack, it doesn't need to be
«fixed»,
and it shouldn't be «fixed». It's there for a
reason.
One thing I'm running into is that c_helpname doesn't
help with abstractions-- it obviously just returns "canvas". I guess I could then compare to the first atom in te_binbuf and if it's not "pd" then it's the name of the abstraction. But that still doesn't get me the dir.
You could look for the standard help patch location first, and if that fails, use c_helpname to solve the issue that Matju brought up.
That still doesn't help with abstractions, because c_helpname is still "canvas".
It helps if it first finds the help patch right next to the abstraction's file in the same folder. Then it wouldn't even check c_helpname.
Additionally, internal objects don't have a c_externdir in 0.43 vanilla, but I guess even the vanilla objects are going to be in their own lib so that won't matter going forward, right?
This is the case where it would fall back to using c_helpname. Like this:
- build helpfile path using c_externdir, classname and '-help.pd'
- else if above file does not exist, try c_helpname
- else, use built-in defaults (or not).
That should cover all cases, including abstractions, internals, etc.
.hc
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 6:39 PM
On Mon, 11 Jul 2011 19:57 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD]
Pd-extended 0.43 updates: lots of new editing features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 4:40 AM
On Jul 11, 2011, at 10:03 PM, Jonathan Wilkes
wrote:
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS:
[PD]
Pd-extended 0.43 updates: lots of new editing
features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
IMHO, I don't think we should
support other
ways of
specifying the help file. There are very
few
objects that
use it, those are fixed in Pd-extended,
it'll add
a lot to
the work of doing this, etc. etc. So I
say
just take
the object name and add the '-help' to
it.
That covers
99.5% of objects. Then once its
working, it
should be
possible to go back and add hacks to
support hacks
;)
c_helpname is not a hack, it doesn't
need to be
«fixed»,
and it shouldn't be «fixed». It's
there for a
reason.
One thing I'm running into is that
c_helpname doesn't
help with abstractions-- it obviously just
returns
"canvas". I guess I could then compare to the
first
atom in te_binbuf and if it's not "pd" then it's
the name of
the abstraction. But that still doesn't get me
the
dir.
You could look for the standard help patch
location first,
and if that fails, use c_helpname to solve the
issue that
Matju brought up.
That still doesn't help with abstractions, because
c_helpname is still
"canvas".
It helps if it first finds the help patch right next to the abstraction's file in the same folder.
Given a t_object, what's the best way to tell if it's an abstraction, and-- if it is-- how can I query its glist members (gl_name and the canvasenvironment ce_path?)
Then it wouldn't even check c_helpname.
Additionally, internal objects don't have a
c_externdir in 0.43 vanilla,
but I guess even the vanilla objects are going to be
in their own lib so
that won't matter going forward, right?
This is the case where it would fall back to using c_helpname. Like this:
- build helpfile path using c_externdir, classname and
'-help.pd'
- else if above file does not exist, try c_helpname
- else, use built-in defaults (or not).
Is there a tcl variable for the built-in default doc directory?
That should cover all cases, including abstractions, internals, etc.
.hc
On Tue, 12 Jul 2011, Jonathan Wilkes wrote:
Given a t_object, what's the best way to tell if it's an abstraction, and-- if it is-- how can I query its glist members (gl_name and the canvasenvironment ce_path?)
EXTERN int canvas_isabstraction(t_canvas *x);
declared in #include "g_canvas.h"
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@at.or.at, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 7:43 PM On Tue, 12 Jul 2011, Jonathan Wilkes wrote:
Given a t_object, what's the best way to tell if it's
an abstraction, and-- if it is-- how can I query its glist members (gl_name and the canvasenvironment ce_path?)
EXTERN int canvas_isabstraction(t_canvas *x);
declared in #include "g_canvas.h"
but it takes a t_canvas and I have a t_object.
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 12 Jul 2011, Jonathan Wilkes wrote:
Mathieu Bouchard matju@artengine.ca wrote:
EXTERN int canvas_isabstraction(t_canvas *x); declared in #include "g_canvas.h"
but it takes a t_canvas and I have a t_object.
pd_class(x)==canvas_class ? canvas_isabstraction((t_canvas *)x) : 0;
thus you check whether it makes sense to cast the pointer to t_canvas*, and if it does, you call the function, otherwise you know that it's not an abstraction.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 12 Jul 2011, Mathieu Bouchard wrote:
On Tue, 12 Jul 2011, Jonathan Wilkes wrote:
Mathieu Bouchard matju@artengine.ca wrote:
EXTERN int canvas_isabstraction(t_canvas *x); declared in #include "g_canvas.h"
but it takes a t_canvas and I have a t_object.
pd_class(x)==canvas_class ? canvas_isabstraction((t_canvas *)x) : 0;
thus you check whether it makes sense to cast the pointer to t_canvas*, and if it does, you call the function, otherwise you know that it's not an abstraction.
sorry, pd_class(x) is just *(x), so it assumes that typeof(x) is t_pd*, or in other words, t_class**.
so you can write pd_class((t_pd *)x)==canvas_class ? canvas_isabstraction((t_canvas *)x) : 0;
or just *(t_pd *)x==canvas_class ? canvas_isabstraction((t_canvas *)x) : 0;
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 12 Jul 2011 10:33 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 6:39 PM
On Mon, 11 Jul 2011 19:57 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD]
Pd-extended 0.43 updates: lots of new editing features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 4:40 AM
On Jul 11, 2011, at 10:03 PM, Jonathan Wilkes
wrote:
--- On Tue, 7/12/11, Mathieu Bouchard matju@artengine.ca
wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: implementing tooltips WAS:
[PD]
Pd-extended 0.43 updates: lots of new editing
features
To: "Hans-Christoph Steiner" hans@at.or.at Cc: "Jonathan Wilkes" jancsika@yahoo.com,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 3:28 AM On Mon, 11 Jul 2011, Hans-Christoph Steiner wrote:
> IMHO, I don't think we should
support other
ways of
specifying the help file. There are very
few
objects that
use it, those are fixed in Pd-extended,
it'll add
a lot to
the work of doing this, etc. etc. So I
say
just take
the object name and add the '-help' to
it.
That covers
99.5% of objects. Then once its
working, it
should be
possible to go back and add hacks to
support hacks
;)
c_helpname is not a hack, it doesn't
need to be
«fixed»,
and it shouldn't be «fixed». It's
there for a
reason.
One thing I'm running into is that
c_helpname doesn't
help with abstractions-- it obviously just
returns
"canvas". I guess I could then compare to the
first
atom in te_binbuf and if it's not "pd" then it's
the name of
the abstraction. But that still doesn't get me
the
dir.
You could look for the standard help patch
location first,
and if that fails, use c_helpname to solve the
issue that
Matju brought up.
That still doesn't help with abstractions, because
c_helpname is still
"canvas".
It helps if it first finds the help patch right next to the abstraction's file in the same folder.
Given a t_object, what's the best way to tell if it's an abstraction, and-- if it is-- how can I query its glist members (gl_name and the canvasenvironment ce_path?)
Then it wouldn't even check c_helpname.
Additionally, internal objects don't have a
c_externdir in 0.43 vanilla,
but I guess even the vanilla objects are going to be
in their own lib so
that won't matter going forward, right?
This is the case where it would fall back to using c_helpname. Like this:
- build helpfile path using c_externdir, classname and
'-help.pd'
- else if above file does not exist, try c_helpname
- else, use built-in defaults (or not).
Is there a tcl variable for the built-in default doc directory?
In Tcl/pd-gui: $::sys_libdir/doc
In C/pd:
char docdir[MAXPDSTRING]; strcat(docdir, sys_libdir); strcat(docdir, "/doc")
But you probably want to use strncat() to be safe.
.hc
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD] Pd-extended 0.43 updates: lots of new editing features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca, "Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at Date: Tuesday, July 12, 2011, 8:16 PM On Tue, 12 Jul 2011 10:33 -0700, "Jonathan Wilkes" jancsika@yahoo.com wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS: [PD]
Pd-extended 0.43 updates: lots of new editing features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 6:39 PM
On Mon, 11 Jul 2011 19:57 -0700, "Jonathan
Wilkes" jancsika@yahoo.com
wrote:
--- On Tue, 7/12/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: implementing tooltips WAS:
[PD]
Pd-extended 0.43 updates: lots of new editing
features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Mathieu Bouchard" matju@artengine.ca,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
Date: Tuesday, July 12, 2011, 4:40 AM
On Jul 11, 2011, at 10:03 PM, Jonathan
Wilkes
wrote:
--- On Tue, 7/12/11, Mathieu
Bouchard matju@artengine.ca
wrote:
> From: Mathieu Bouchard matju@artengine.ca > Subject: Re: implementing
tooltips WAS:
[PD]
Pd-extended 0.43 updates: lots of new
editing
features
> To: "Hans-Christoph Steiner"
> Cc: "Jonathan Wilkes" jancsika@yahoo.com,
"Martin Peach" martin.peach@sympatico.ca, "pd-list" pd-list@iem.at
> Date: Tuesday, July 12, 2011,
3:28 AM
> On Mon, 11 Jul 2011,
Hans-Christoph
> Steiner wrote: > >> IMHO, I don't think we
should
support other
ways of
> specifying the help file.
There are very
few
objects that
> use it, those are fixed in
Pd-extended,
it'll add
a lot to
> the work of doing this, etc.
etc. So I
say
just take
> the object name and add the
'-help' to
it.
That covers
> 99.5% of objects. Then once
its
working, it
should be
> possible to go back and add
hacks to
support hacks
;)
> > c_helpname is not a hack, it
doesn't
need to be
«fixed»,
> and it shouldn't be «fixed».
It's
there for a
reason.
One thing I'm running into is
that
c_helpname doesn't
help with abstractions-- it obviously
just
returns
"canvas". I guess I could then
compare to the
first
atom in te_binbuf and if it's not "pd"
then it's
the name of
the abstraction. But that still
doesn't get me
the
dir.
You could look for the standard help
patch
location first,
and if that fails, use c_helpname to
solve the
issue that
Matju brought up.
That still doesn't help with abstractions,
because
c_helpname is still
"canvas".
It helps if it first finds the help patch right
next to
the abstraction's file in the same folder.
Given a t_object, what's the best way to tell if it's
an abstraction,
and-- if it is-- how can I query its glist members
(gl_name and the
canvasenvironment ce_path?)
Then it wouldn't even check c_helpname.
Additionally, internal objects don't have a
c_externdir in 0.43 vanilla,
but I guess even the vanilla objects are
going to be
in their own lib so
that won't matter going forward, right?
This is the case where it would fall back to
using
c_helpname. Like this:
- build helpfile path using c_externdir,
classname and
'-help.pd'
- else if above file does not exist, try
c_helpname
- else, use built-in defaults (or not).
Is there a tcl variable for the built-in default doc
directory?
In Tcl/pd-gui: $::sys_libdir/doc
Oh thanks. Wouldn't it be $::sys_libdir/doc/5.reference, though?
In C/pd:
char docdir[MAXPDSTRING]; strcat(docdir, sys_libdir); strcat(docdir, "/doc")
But you probably want to use strncat() to be safe.
.hc
Then it wouldn't even check c_helpname.
Additionally, internal objects don't have a
c_externdir in 0.43 vanilla,
but I guess even the vanilla objects are
going to be
in their own lib so
that won't matter going forward, right?
This is the case where it would fall back to
using
c_helpname. Like this:
- build helpfile path using c_externdir,
classname and
'-help.pd'
- else if above file does not exist, try
c_helpname
- else, use built-in defaults (or not).
Is there a tcl variable for the built-in default doc
directory?
In Tcl/pd-gui: $::sys_libdir/doc
Oh thanks. Wouldn't it be $::sys_libdir/doc/5.reference, though?
If you want the directory for the built-in help, yes.
.hc
On Mon, 11 Jul 2011, Jonathan Wilkes wrote:
One thing I'm running into is that c_helpname doesn't help with abstractions-- it obviously just returns "canvas". I guess I could then compare to the first atom in te_binbuf and if it's not "pd" then it's the name of the abstraction. But that still doesn't get me the dir.
Comparing binbuf_getvec(te_binbuf)[0] with "pd" is not sufficient. There are other names that could be there and aren't abstractions, such as "page" and Arrays (appearing as "graph" and Graphs (also appearing as "graph").
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 11 Jul 2011, Jonathan Wilkes wrote:
All you add on the pd side is a sys_gui call to create the binding, then handle everything else on the tcl side. Does that make sense?
It's one easy way of doing it. You could also define a proc so that the contents of the sys_gui call is as short as possible, if that makes any difference.
Also doesn't address tooltips for abstractions.
Why ? abstractions have accompanying *-help.pd files too...
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Mon, 7/11/11, Martin Peach martin.peach@sympatico.ca wrote:
From: Martin Peach martin.peach@sympatico.ca Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing features To: "pd-list" pd-list@iem.at Cc: "Jonathan Wilkes" jancsika@yahoo.com Date: Monday, July 11, 2011, 6:42 PM On 2011-07-11 12:06, Jonathan Wilkes wrote:
But I'm not sure where to store the tooltip string...
Not sure if that's what you mean, but in max the assist method receives a number corresponding to the inlet or outlet and returns a pointer to the appropriate string, so the string is already stored somewhere in the memory allocated to the object.
Ok, I see.
I don't get the idea of having a new method that's supposed to be hidden from the user (but really isn't) for every object that wants tooltips; in some cases it would subtly change the function of the object class, like [bang] and [route]. (Aside from crashing Pd, "dsp" isn't such a big deal because there isn't much of a need for an object that takes a signal AND parses arbitrary selectors, esp. on the same inlet.) Maybe this wouldn't be a problem if [textfile] output lists, and there was a [routelist] in Pd vanilla...
Did desiredata have tooltips? If so, how were they implemented?
-Jonathan
Martin
On Mon, 11 Jul 2011, Jonathan Wilkes wrote:
I don't get the idea of having a new method that's supposed to be hidden from the user (but really isn't) for every object that wants tooltips;
Forget about how MAX does it and how bad that might be : just define an assistfn field in t_class and the problem you mention will not happen.
Did desiredata have tooltips? If so, how were they implemented?
Nothing fantastic. Because desiredata was a fork of devel_0_39, it had Günter's tooltips, and I modified them so that they look like other apps' existing tooltips (yellow rectangles with the usual mouse behaviour) and I didn't have time to improve the concept further.
I think that dd's tooltips would crash dd but I don't remember whether I fixed it or not. In any case, dd's tooltip code is only relevant because of the yellow rectangle / mouse behaviour thing, and that's because it's standard GUI behaviour, nothing original.
And as Günter's, it only did inlet-names, not method-lists nor any other things that could be interesting to have in tooltips.
DD's class-browser could list first-inlet methods, but pd's whole internals-design prevents listing all methods in the class-browser. It's easier to do it on a live object. The exception to this is GridFlow's [gf/class_info], which can list all methods of any GF class without instantiating, but that doesn't work on non-GF classes.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Mon, 11 Jul 2011, Jonathan Wilkes wrote:
Does A_CANT actually work?
Well, maybe it doesn't... ;)
Also, what if someone is parsing arbitrary sequences of anythings-- say, with [route] or any number of other objects that have an anything method? Now those objectclasses have to choose between truly accepting any selector, or being helpful and having a tooltip.
That's the problem with "loadbang" and "dsp" already, and the fact that those things aren't named "__loadbang__" and "__dsp__", or better, "!@#$%^&*()loadbang" and "<?+[]dsp", to make them unreachable by accident.
Alternately, they could be put in a parallel universe (a completely insulated namespace), such as Pd's already existing freefn, widgetbehavior, parentwidgetbehavior, savefn and propertiesfn... or else... I think that GF still uses a pseudo-inlet number -1 for internal use.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sun, 10 Jul 2011, Jonathan Wilkes wrote:
This brings up an issue I've been wondering about since learning a little more about the canvas editor: why does the pd gui send 'motion' messages to pd? Why not, for example, just have a tag for an inlet rectangle and bind <Enter> and <Leave> to it? Then you'd only be sending messages from the gui for the events you care about, instead of tons of "motion" messages that don't trigger anything.
Just because almost all the canvas patching operations (create box, edit box, delete box, select box, connect, disconnect, etc) are made completely from server side computations without using any <Enter>, <Leave> nor TkCanvas's "find overlapping" feature.
DD used "find overlapping". It finds the list of canvas-items that intersects a given rectangle. Then DD had a standard tag system in which mandatory tags allowed DD itself to figure out the origin of a certain item and trace it back to an object. That allowed to delete a chunk of C code, but to remove the need for 'motion' messages, a lot more work is necessary.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, 9 Jul 2011, Jonathan Wilkes wrote:
I read a white paper on total development cost of a linux distro and just remembered "linux". I think the distro in the paper was Fedora 9, which was estimated to be almost an order of magnitude more expensive than the Linux kernel.
That estimation model probably considers Linux as a part of Fedora, and every other piece of software of Fedora as being part of Fedora.
Do you have any link to that paper ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Fri, 8 Jul 2011, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at wrote:
Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the core of the largest free software project in the history of computing is a wee bit more difficult than making changes to Pd.
It's easy to use the Linux project as a reference, to justify that submitting changes to Pd ought to remain hard and that things are just fine as they are now. After all, the Linux project is a well-respected success story, nevermind that it's a project so different from pd in many ways.
Just more expressions of millercentrism... nothing to see, move along...
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Jul 17, 2011, at 1:15 PM, Mathieu Bouchard wrote:
On Fri, 8 Jul 2011, Jonathan Wilkes wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner hans@at.or.at wrote:
Try getting a patch into the Linux kernel, that'll make Pd seem like cake ;-)
Yes, I would hope that making changes to the core of the largest
free software project in the history of computing is a wee bit more
difficult than making changes to Pd.It's easy to use the Linux project as a reference, to justify that
submitting changes to Pd ought to remain hard and that things are
just fine as they are now. After all, the Linux project is a well- respected success story, nevermind that it's a project so different
from pd in many ways.Just more expressions of millercentrism... nothing to see, move
along...
Think about why it remains hard. Managing patches is a lot of work,
and its not fun, unless the patch happens to fix something that you
want fixed. This is almost all work on people's own time.
Start a fork, git makes it much easier. Then you can have your own
version that includes every patch that you want it to. DesireData was
a great effort, pd-devel too. Pd-extended is another example, as well
as pd_l2ork. If we all use git forked from Miller's pure-data git it
makes keeping in sync vastly easier than before. Git has a steep
learning curve. Take 2 days to really study and learn it, and it will
save you vast amount of time tracking code and bisecting for patches.
Having multiple forks in rough sync all working with git means that
more patches get accepted, written, tested, etc.
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
commented: Looks worth including, but with GOP bugs, I'm currently waiting to see what Miller is going to do with GOP restructuring before tackling this stuff. I still don't really have a grasp of the GOP code, so I don't know what the repercussions of GOP-related patches are. From my experience, one little simple fix causes some weird behavior elsewhere.
I have no idea how Miller approaches reworking things. However, if I were the one doing it, I would prefer reworking a working rather than a buggy code. Wouldn't it make sense to stabilize existing code with patches like these until we know it works as-is and then clean it up and reimplement based on *working* code? AFAIK (as I mentioned before) pd-l2ork's implementation is as close to fully working gop as it gets. Apart from the GOP bug reported recently and for which I provided a fix that will be easy to re-implement, I am unable to reproduce any other buggy behavior I am aware of and that is apparent in pd vanilla/extended.
Best wishes,
Ico
Best wishes,
Ico
-
András Murányi -
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jonathan Wilkes -
Martin Peach -
Mathieu Bouchard