The problem with [coords( is that you also need to do [map 0, map1( to
force a redraw of the parent canvas. This means you would have to
document [map( as well.
I would say don't document it for now and instead let's hope that we
will *finally* get https://github.com/pure-data/pure-data/pull/627 (this
PR is now already 2 1/2 years old...)
Christof
On 01.12.2021 20:24, Alexandre Torres Porres wrote:
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]:
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 <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>
_______________________________________________
[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
_______________________________________________
[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
