If you don't send [map 0, map 1( to the parent canvas, the graph will still contain previous graphical elements. You don't notice this if you use a mycanvas in the background, though.

On 01.12.2021 22:04, Alexandre Torres Porres wrote:
yeah, I'll just take the 'coords' message out and keep the rest

but it's not like it always needs map 0/1, does it?

Em qua., 1 de dez. de 2021 às 18:03, Christof Ressi <[email protected]> escreveu:

    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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to