Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

send messages to a (parent) canvas #835

Open
Spacechild1 opened this issue Dec 12, 2019 · 4 comments · May be fixed by #837
Open

send messages to a (parent) canvas #835

Spacechild1 opened this issue Dec 12, 2019 · 4 comments · May be fixed by #837
Labels

Comments

@Spacechild1
Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 12, 2019

Sometimes we need to a way to send messages to the current canvas or one of its parents. Currently, this is only possible if you know the symbol the canvas is bound to. [namecanvas] does allow to bind an abstraction to a (unique) symbol, but still gives no way to talk to the parent.

I see four basic ways how to implement this:

  1. have a dedicated object, similar to [iemguts/sendcanvas] (with the parent level as a creation argument)
  2. expand [pointer]'s [traverse( message to (alternatively) accept the parent level as a float argument, so we can send a message to this canvas with [traverse 0, send-window foo bar( -> [pointer] and to the parent canvas with [traverse 1, send-window foo bar( -> [pointer]
    *** note that the [send-window( method already exists! ***
  3. add a message to some existing class (e.g. [pdcontrol] or maybe even t_canvas) like [send-window <parent-level> <message...>(
  4. add a second argument to [namecanvas] to specify the parent level, as suggested by @porres

Are there more ways?

As @umlaeute points out in #794 (comment), using a receive symbol (as in 4) might not be the cleanest approach.

Personally, I don't care much because I use iemguts anyway :-) Conceptually, I like 2) but other people might find it too arcane.

@Spacechild1 Spacechild1 added the feature label Dec 12, 2019
@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 12, 2019

As @umlaeute points out in #794 (comment), using a receive symbol (as in 4) might not be the cleanest approach.

No, not "as in 4". As I see it, this comment talks about getting a file name so you can send messages to it, not about setting a name with [namecanvas] (as in 4).

[sendcanvas] is merely a conjunction of [namecanvas] and [send], but it bypasses the need of setting a name. [sendcanvas] can also refer to a parent patch, and this is why I'm proposing [namecanvas] could do the same.

My main opposition here is with creating a whole new object (option 1). I think we can find a way to use an existing object.

Conceptually, I like 2) but other people might find it too arcane.

yeah, I can't understand this one at all.

As for the others, I feel [namecanvas] seems the best candidate as it's closely related to [sendcanvas] and its purpose is exactly to allow communication to a patch. Therefore, if we include the functionality to talk to a patch with another object like [pdcontrol], then [namecanvas] becomes completely and actually obsolete.

Now, @millerpuckette seems to have thoughts on how [namecanvas] isn't that great. It's already placed in an 'obsolete' section of help-intro.pd, and the code said it ought to have been deleted (but obviously it won't be anymore). It's not really obsolete, though, it's just that there seems to be issues here I have no real idea, and I'm also assuming that it is a matter of the mechanism itself, not the object, meaning the issue will be there regardless where and how we implement this. So I'd like to hear from him.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 12, 2019

Not to impose my solution, but there's a PR for my proposal that people can maybe test #837

@Spacechild1

This comment has been minimized.

Copy link
Contributor Author

@Spacechild1 Spacechild1 commented Dec 12, 2019

No, not "as i 4". As I see it, this comment talks about getting a file name so you can send messages to it, not about setting a name with [namecanvas] (as in 4).

I think you've misunderstood the comment. IOhannes talked about using symbols in general as a means of communication with a canvas. Actually, I don't agree with his assertion that canvas symbols are an implementation detail, e.g. they are required for working with data structures (see the [traverse( method), but I would agree that the [namecanvas] solution is rather hacky - also in its current form!

yeah, I can't understand this one at all.

Just in case you're curious: [traverse( gets a pointer to the canvas and [send-window ...( sends a message to the canvas. Note that [send-window( already exists.

becomes completely and actually obsolete.

why is this a problem? it's totally ok for objects to become obsolete, see [table] -> [array define], [qlist] -> [text], [fiddle~] -> [sigmund~], etc.

[sendcanvas] is merely a conjunction of [namecanvas] and [send]

I'd say it's the opposite: [namecanvas] + [send] is a more convoluted way to achieve what [sendcanvas] does.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 13, 2019

you've misunderstood the comment. IOhannes talked about using symbols in general

Ok, seems then that "exposing an implementation detail" in a lower level is the only issue? Is there any 'danger' with this implementation? I can't see it.

Actually, I don't agree with his assertion that canvas symbols are an implementation detail

Yeah, sending messages to Pd patches like that is common and even documented.

I'd say it's the opposite: [namecanvas] + [send] is a more convoluted way to achieve what [sendcanvas] does.

Well, never said the contrary, just wanted to note [namecanvas] + [send] is vanilla's way.

the [namecanvas] solution is rather hacky

I kinda agree, I'd say is lower level, with no advantages for it that I can see. Maybe just use [send] objects in different places? But yeah, the design of [sendcanvas] seems nice, never criticized it.

why is this a problem? it's totally ok for objects to become obsolete

I don't personally have problems actually. But I do think it's worth noting and I guess this is usually undesired and only pursued in Pd for more "extreme" cases.

The issue with [namecanvas] seems to be only about "dirty design". And well, I got many design options I prefer over vanilla (that's why I develop too many externals), but I think it's not an "extreme" case. Quoting @millerpuckette : "Adding features is how software inflates and eventually dies of bloat. One wants a valid use case before just adding stuff. And even then, if there's already a way to do the same thing, one should think twice."

So I'm trying to follow what I believe is the philosophy of Pd development, and then I'm thinking twice before ditching [namecanvas] and adding a similar functionality to another object.

Having said all that, I can take it back that adding [sendcanvas] is my main opposition, but it's not up to me :)

Just in case you're curious: [traverse( gets a pointer to the canvas and [send-window ...( sends a message to the canvas. Note that [send-window( already exists.

I have to say this feels dirtier and hackier and that it's my new main opposition :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.