Hello list,
I just noticed something new: when sending a donecanvasdialog message to a subpatch in a GOP, it starts editmode in the parent patch. Afaik, this wasn't the previous behaviour (it still isn't in pd extended).
Here is a patch to illustrate the problem. Doesn't happen with coords, though.
Best,
Joao
yeah, I brought this up when pd-0.49, or whatever it's going by these days, was released, it seems to be something that was imported from L2ork along with the infinite undo, perhaps, or maybe some other new, uh, smart editing feature, which I seem to be too simple to get much out of except frustration, though I'm still using 0.48-2 and maybe I haven't given it a chance yet.
On Thu, Dec 13, 2018, 9:09 PM João Pais, jmmmpais@gmail.com wrote:
Hello list,
I just noticed something new: when sending a donecanvasdialog message to a subpatch in a GOP, it starts editmode in the parent patch. Afaik, this wasn't the previous behaviour (it still isn't in pd extended).
Here is a patch to illustrate the problem. Doesn't happen with coords, though.
Best,
Joao
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/14/18 3:07 AM, João Pais wrote:
Hello list,
I just noticed something new: when sending a donecanvasdialog message to a subpatch in a GOP, it starts editmode in the parent patch. Afaik, this wasn't the previous behaviour
Here is a patch to illustrate the problem. Doesn't happen with coords, though.
i don't have an explanation (nor thought about one, really). (it probably is related to some infinite undo thing)
however: i'm sure you are aware that the donecanvasdialog message is part of a "private" API, that is: it is used for the internal working of Pd and users are not supposed to use it directly (even though it allows you to do nice and handy things). so i don't see anything inherently wrong with the new behaviour.
you could always send an [editmode 0( message to the parent patch, to inhibit the problem.
(it still isn't in pd extended).
i guess the next release will bring it.
gfmadsr IOhannes
however: i'm sure you are aware that the donecanvasdialog message is part of a "private" API, that is: it is used for the internal working of Pd and users are not supposed to use it directly (even though it allows you to do nice and handy things). so i don't see anything inherently wrong with the new behaviour.
is there a "public" version of it? as this is very important for some of my abstractions and very useful, specially jp.menu and jp.preset, which simulate a drop-down menu only using Pd mechanics.
you could always send an [editmode 0( message to the parent patch, to inhibit the problem.
theoretically yes, but when being used in abstractions (which is my particular case) it makes things harder to determine what is the main patch window where to send the message to. And make it dependent on an external library that will find out the main window name.
Joao
I think I noticed this issue when I fixed another regression with the donecanvasdialog message but I didn't have time to tackle it. I'll give it a try for the next bug fix release.
Gesendet: Samstag, 15. Dezember 2018 um 12:07 Uhr Von: "João Pais" jmmmpais@gmail.com An: "IOhannes m zmölnig" zmoelnig@iem.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] Pd Vanilla donecanvasdialog GOP starts edit mode
however: i'm sure you are aware that the donecanvasdialog message is part of a "private" API, that is: it is used for the internal working of Pd and users are not supposed to use it directly (even though it allows you to do nice and handy things). so i don't see anything inherently wrong with the new behaviour. is there a "public" version of it? as this is very important for some of my abstractions and very useful, specially jp.menu and jp.preset, which simulate a drop-down menu only using Pd mechanics. you could always send an [editmode 0( message to the parent patch, to inhibit the problem. theoretically yes, but when being used in abstractions (which is my particular case) it makes things harder to determine what is the main patch window where to send the message to. And make it dependent on an external library that will find out the main window name. Joao_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
IOhannes m zmölnig -
João Pais -
JTG III