sorry to insist, but this has been already committed to my documentation branch and it's the only big change that I really worry about. So let's settle this before it's too late :)
thanks Em sáb., 27 de nov. de 2021 às 22:28, Alexandre Torres Porres < [email protected]> escreveu: > I updated my file. It seems the only "tricky" message is 'coords', right? > > I put a warning about it. So, does it settle it? > > Em sáb., 27 de nov. de 2021 às 22:01, Christof Ressi < > [email protected]> escreveu: > >> I very much agree with your points. >> >> If we lump "user space" and "internal" messaging together in an open >> manual, then they should be clearly delineated with special placed on >> emphasizing what things are more or less stable and what things are not. >> Then the user can decide how they want to proceed. >> >> As you say, it's better to document all of it and at the same time make >> it clear what is public and what is private. And figure out how to deal >> with the large gray area in between :-) >> >> Christof >> On 28.11.2021 00:37, Dan Wilcox wrote: >> >> Howdy all, >> >> My feeling on this is: >> >> 1. Recognize that, despite using "private" or "unstable" internal APIs, >> people have been using/abusing them for years. (So far, I feel we have been >> recognizing this by being careful not to break things, more or less.) >> >> 2. We should document all internal messaging, at least for the sake of >> developer documentation. If we lump "user space" and "internal" messaging >> together in an open manual, then they should be clearly delineated with >> special placed on emphasizing what things are more or less stable and what >> things are not. Then the user can decide how they want to proceed. I don't >> see a problem if people want to play with the internals on their own >> machine and crash Pd... that's half the fun for such activities anyway >> (learning). >> >> 3. We should get a poll of which internal messages are currently in use >> and consider which of these could be moved into "user space" and/or >> replaced by a better API. I believe this thread is already providing a good >> list... >> >> 4. Open a technical discussion on supporting "dynamic patching" >> officially. It's clearly very useful even if clunky through the current >> workarounds. Even with [clone] there are still many use cases... >> >> On Nov 28, 2021, at 12:25 AM, [email protected] wrote: >> >> Message: 1 >> Date: Sat, 27 Nov 2021 20:20:49 +0100 >> From: Jean-Yves Gratius <[email protected]> >> To: [email protected] >> Subject: Re: [PD] documenting messages to/from Pd and dynamic patching >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> On 27/11/2021 17:19, [email protected] wrote: >> >> ForwardedMessage.eml >> >> Subject: >> Re: [PD] documenting messages to/from Pd and dynamic patching >> From: >> Christof Ressi <[email protected]> >> Date: >> 27/11/2021 ? 17:01 >> >> To: >> Pd-List <[email protected]> >> >> >> Two examples that come to my mind: >> >> 1) [iemguts/canvasselect] allows to (de)select objects simply by >> index. No need to emulate mouse selection with "mouse" and "mouseup". >> >> 2) canvases/objects can be moved around with [iemguts/canvasposition] >> resp. [iemguts/canvasobjectposition] >> >> Are there any other use cases for "mouse" and "mouseup"? >> >> Hi. My 2 cents >> >> Personally, I use mouse and mouseup messages to forward multitouch >> events into the patch, received? from my multitouch linux laptop. >> >> If those messages were blocked, all my multitouch ecosystem would be out >> of order :-) . >> >> >> -------- >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com >> robotcowboy.com >> >> >> >> >> _______________________________________________pd-l...@lists.iem.at mailing >> list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
