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

(feature request) pdcontrol - get canvas name #794

Closed
mariobuoninfante opened this issue Nov 25, 2019 · 34 comments
Closed

(feature request) pdcontrol - get canvas name #794

mariobuoninfante opened this issue Nov 25, 2019 · 34 comments

Comments

@mariobuoninfante
Copy link

@mariobuoninfante mariobuoninfante commented Nov 25, 2019

Hi,

I thought it would be great to have something like a get_namecanvas method for [pdcontrol], that returns the name of the canvas where the object lives.
Afaik the only way to talk with a canvas is:

  • knowing the name of the canvas and use [s pd-mycanvas]
  • use [namecanvas] to set the name to a known one

Please correct me if I'm wrong

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Nov 25, 2019

alternatively, we could add a [bang( method to [namecanvas] which outputs the canvas name.

BTW, people use [namecanvas] on a root canvas not only to be able to send messages, usually they also set it to a unique name, so that messages go only to this instance, not all instances of the same patch/abstraction.

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 25, 2019

@Spacechild1 that makes sense. Only thing, and I'm most certainly wrong here, I know [namecanvas] seems to be the obvious candidate for that, but would [pdcontrol] be a good one as well?
it kind of feels weird to me that you get args from [pdcontrol] and then the name of the canvas from a different object. What I mean is, shouldn't everything come from the same source? Wouldn't be a better workflow?
what are your thoughts?

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 25, 2019

what do you need that feature for? (i'm not saying that there are no uses but probably all are edge cases...)

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 25, 2019

well, dynamic patching could be one reason

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 25, 2019

surely it's not a must-have feature, I'd agree

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 25, 2019

as for dynamic-patching: what would this new functionality allow you to do that [namecanvas] does not already allow?

i guess you had some specific use-cases in mind, and i wondered.

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 25, 2019

my idea was to have a simple toolbar abstraction that allows you to automatically create objects, number boxes, messages, etc. in your patch.
it would be probably simpler (maybe neater more than simpler) without having to change the name of the canvas.
nothing I can't do with [namecanvas], but then I'd need to actually change the name of the canvas. Maybe there are even other ways.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 26, 2019

[namecanvas] doesnt change the nam of the canvas, it only adds a new name.

knowing the (generic) name of the canvas is usually not helpful, as all abstractions share the same name ( as @SpaceChild pointed out).

to talk to the "parent canvas" (which is usually what you want in the case you described) i think the cleanest solution is something like iemgut's [sendcancas]

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Nov 26, 2019

to talk to the "parent canvas" (which is usually what you want in the case you described) i think the cleanest solution is something like iemgut's [sendcancas]

yeah, but not sure @mariobuoninfante even needed this. And by the way, why would you need to do that? I know I never needed it

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 26, 2019

to talk to the "parent canvas" (which is usually what you want in the case you described)

@umlaeute exactly, that's what I want (thought I didn't need to call it out explicitly, but yes).
And [sendcanvas] does the job (I wasn't aware of it, my bad).
Since it seems like a bit of clarity is needed (about the use case I had in mind), here's a video that shows what I'd like to achieve

https://www.youtube.com/watch?v=qIxhiCP242A&feature=youtu.be

Then in general, even if not officially supported, you know we can send several messages to the canvas knowing its name, thus I think there is some value in being able to get the name of the canvas (parent as well).
Like you said, [sendcanvas] does the job, just I was wondering (in case we'd like to have it in Vanilla) whether [pdcontrol] would be a better place where to implement this.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 26, 2019

Like you said, [sendcanvas] does the job, just I was wondering (in case we'd like to have it in Vanilla) whether [pdcontrol] would be a better place where to implement this.

<rant>
of course i'm heavily biased (as author of [sendcanvas]), but i don't think that we should slump every feature that we like to see in Pd onto [pdcontrol]: it seems that people see this new object as a jamboree bag where they can slip in all the wond'rous functionality they ever needed. weirdly enough the [slop~] object is not an extension of [pdcontrol]....

so no, it wouldn't be a better place.
</rant>

on a more constructive level: the only reason i see why you need to get the implicit receive-name of a canvas is to send messages to this canvas. the receive-name is only a means to accomplish this, an implementation detail of the communication between Pd-core and Pd-gui.
i'm pretty sure that we shouldn't expose this implementation detail, and instead we should provide a high-level abstraction (in the CS sense) to accomplish the goal. i couldn't come up with a better one than [sendcanvas] (that's why i implemented it), although there might be other ways.

@mariobuoninfante

This comment has been minimized.

Copy link
Author

@mariobuoninfante mariobuoninfante commented Nov 26, 2019

@umlaeute fair enough, yours are all valid points. In fact as I already said above, I'm sure my request is NOT a must-have, for all the obvious reasons you called out.
I don't think of [pdcontrol] the way you described it, at all. Just, from a user perspective I could expect [pdcontrol] to provide that info since is able to provide, for example, the args of the parent patch.
In my (probably distorted) vision, I've always been considering the name of the canvas a kind of argument.
Anyway I totally get your points though.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Nov 26, 2019

you seem to be asking for the abstraction name, e.g. "MAIN.pd" resp. the argument of a subpatch (e.g. "foo" for [pd foo]).
i agree, that this is similar to abstraction-arguments, and could be queried by [pdcontrol].
(iirc, in iemguts, the first iteration of [canvasargs] would also be able to give you the canvas-name; however, sice then i've factored this into a separate [canvasname] object)

however, as @Spacechild1 pointed out, this is not a good way to send messages to a (single) instance: if you have a patch with multiple abstractions [foo], then sending a message to pd-foo.pd will be received by all instances, not just a single one.
this is usually not what you want.

so: if you want to send messages to a specific canvas, you need to find a unique indentifier to send messages to. [sendcanvas] does this for you. [namecanvas] allows you to do this. the "name" does not.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 6, 2019

get the name of the patch is something that purr data's [canvasinfo] object gives you. I've already checked [canvasinfo] to see what we could get into vanilla, [pdcontrol] already has 3 methods that [canvasinfo] already has (visibility / dir / args), and maybe it could include a bit more, but surely not all as many of those seem not that useful, at least I don't see much of the use cases.

Anyway, is there any crucial use case for getting the patch file name?

And could we change the title of this request for getting file name instead of canvas name?

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 10, 2019

is there any crucial use case for getting the patch file name?

For 'crucial' I meant "something you cannot do in any other way without an external". For the use case we discussed here, we can manage and achieve this in Vanilla with the hassle of sending the current patch name to the abstraction, which is not something you want for an external/abstraction to work 'out of the box'.

Anyway, I just realised I also have a use case for something like this. I designed a few GUI abstractions and I wanted Pd to know when the arguments changed so it'd ask you if you wanted to save the parent patch (to save the modifications). This is what happens if you change the colors of any iemguis, for instance.

So I designed a very specific external just for that single purpose in my last update of the else library, called [savechange]. If you send it "1", Pd asks if you want to save the patch, and an argument of "1" asks you to save the parent patch. I don't like the idea of designing that kind of specific external and I had it in my mind that Pd Vanilla could have some functionality that wouldn't make an external necessary. So I'm now with you on this one. (I don't actually care if I have to carry this external, now that I'm over 360 objects in my library, but even so it feels silly to have it and I'd rather not to).

So I'm now thinking of the simplest and most powerful way to have something like this in Vanilla. Getting the file name of the parent patch seems like the best idea, that's why I was asking for other use cases, specially 'crucial' ones.

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 11, 2019

@porres the parent canvas name is not helpful as it doesn't refer to a specific instance. Many canvasses can be bound to the same symbol. What you need is a way to send a message to the parent canvas.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

hmm, I'm thinking of a patch that loads objects, externals, abstractions and whatever.

it doesn't refer to a specific instance.

an instance is like an abstraction that you call multiple times, then you need to force a locality, be it with [namecanvas] or whatever. But in the case of a patch that calls abstractions, the idea is that there's only one of it. Then you can get its name (like "main.pd" as in the example by @mariobuoninfante or whatever) and be done with.

But then, what you're asking is basically having [sendcanvas] built into Pd Vanilla... I think that's a higher level object just for this purpose and maybe we can think of a lower level solution. Something like adding a new functionality into an existing object rather than creating a whole new object just for this.

Following the discussion on this issue, it could be a new functionality into [namecanvas], that allows you to name a parent patch with a 'depth' level optional 2nd argument, or getting the file name with a new method in [pdcontrol]

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 11, 2019

But in the case of a patch that calls abstractions, the idea is that there's only one of it.

but how can you know? why limit it to that special case?

then you need to force a locality, be it with [namecanvas] or whatever

so why not go towards the simple solution me and @umlaeute have described?

But then, what you're asking is basically having [sendcanvas] built into Pd Vanilla...

no, I've just talked about the functionality.

I think that's a higher level object just for this purpose and maybe we can think of a lower level solution.

how is sending a message to a canvas "higher" level than getting the name of canvas?

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

why not go towards the simple solution me and @umlaeute have described?

sorry, which one exactly is it? If not just including [sendcanvas] into vanilla?

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 11, 2019

#794 (comment)

when we talk about [sendcanvas] we don't mean we should include the object as is, we rather talk about the functionality itself. how to best implement this functionality is the next step.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

how about a depth level argument so you can name a parent canvas in [namecavas]?

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

for getting the patch name, I'd go for [pdcontrol], but if getting the patch name is something not that great, I think this functionality to [namecanvas] could be the idea everyone's happy with.

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 11, 2019

I think this functionality to [namecanvas] could be the idea everyone's happy with.

no, not me. why do you keep proposing more complicated (non)solutions?

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

what is exactly the simple solution you want then? I ask if you want a new [sendcanvas] object, you say no, I ask/propose a new functionality to [namecanvas] then... ok, not that either...

I'm cool with not trying to guess what you think it's best, just say it.

how to best implement this functionality is the next step.

so, what's your take on it?

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 11, 2019

I ask if you want a new [sendcanvas] object, you say no

I clearly said I want the functionality of [sendcanvas]. And I clearly said what I think is not a solution (getting the parent canvas name, renaming the parent canvas). There's nothing more I have to say at this point. If someone opens an issue about a functionality like [sendcanvas], then we can discuss further.

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

I clearly said what I think is not a solution (getting the parent canvas name, renaming the parent canvas). There's nothing more I have to say at this point.

Oh, sorry, I thought we were like discussing ideas, trying to find the common ground towards a next step. I also thought that maybe you could tell us a bit more why that is so... even though I clearly saw that you mentioned you didn't like this.

I see the problem with getting the parent name, as you can have the patch opened twice. Valuable point, even though I can see why anyone would do that.

Maybe I missed something, but all I've seen you say about the naming the parent patch idea is that "no, not me. why do you keep proposing more complicated (non)solutions?", and I'm like not really gonna get into why I don't think this is the best attitude in discussing your ideas and proposing stuff, but anyway, if you don't really have anything else to say, fine, I already got you have some problem with this, no need to just keep stressing that :)

Anyway, I'll just say that I hope we don't get too passional or nervous in the activity of devoting our precious time to the cause and love we have for Pure Data, and that maybe a constructive criticism and more assertiveness is better welcome here. Cause I'd like to spend more energy in finding solutions rather than dealing with this kind of attitude.

But for the record, naming a parent patch works pretty fine for me and I had tested this before. I once developed an external for this but didn't keep it. Here's a screenshot with a proof of concept. It's like [namecanvas], but it can name a parent patch. Using "$0" works just fine, so you can send to the parent, and the parent only, not to the same patch opened twice containing the same abstraction or three times or more... if I got it right, that's exactly what you wanted. Anyway, here it goes.

Screen Shot 2019-12-11 at 03 36 40

Now, if that's also something we don't want, for whatever reason that I'm not even disputing, all I can see is having a whole new object which is just exactly like [sendcavas].

I'm really just hoping to see what's the higher consensus towards a solution here, and if it's within my reach, I can go ahead and make a PR.

cheers

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 11, 2019

more details on the modification I did to [namecanvas], a 2nd optional argument sets the depth level, in this case "1" is the parent.

porres added a commit to porres/pure-data that referenced this issue Dec 11, 2019
this is a solution that closes pure-data#794 even though the request was for something else

It is also a solution to pure-data#833
@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 11, 2019

Sorry, I admit I was a bit harsh. I just got annoyed because you kept bringing up the canvas name thing, although we've already pointed out the various flaws very early in this thread. And the other discussions on your recent GitHub issues have been quite exhausting as well.

I see the problem with getting the parent name, as you can have the patch opened twice. Valuable point, even though I can see why anyone would do that.

Why not? Also, a user might put your abstraction into another abstraction. You can't know.

To be fair, the [namecanvas] approach you've just shown is indeed a possible solution, but I see at least 3 other ways to implement this functionality, so we could have a discussion about this - in another GitHub issue!

Generally, we should only make feature requests like "implement A (so we can do B)" if we're 99% certain that A is either the only or the best way to implement B. When in doubt, a feature request should rather be "add support for B".

Also, we should aim to convey as much information in as few words as possible, otherwise the threads become unreadable.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 11, 2019

in another GitHub issue!

yes please.
this ticket is supposedly about "get[ting the] canvas name".
i think we have established, that the original request was mislead (as it was meant as a means to communicate with a given parent, but it turned out that this was the wrong way to do it).
i'll therefore close this ticket (even though there might be merits in getting an abstraction's name for other purposes; but this ticket has been flooded with suggestions about all kind of things none of which are about "getting the canvas name" at all and therefore OT; afaict this ticket has accumulated enough noise to become useless)

@mariobuoninfante if you do want [pdcontrol] to be able to retrieve an abstraction/subpatch name, please open another ticket.
sorry for the inconvenience.

@umlaeute umlaeute closed this Dec 11, 2019
@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 12, 2019

To be fair, the [namecanvas] approach you've just shown is indeed a possible solution

well, if we're gonna be fair, this was the only approach I ever proposed involving [namecanvas] - see #794 (comment) (when I first mentioned about it)

I just got annoyed because you kept bringing up the canvas name thing, although we've already pointed out the various flaws very early in this thread.

that didn't really happen, I didn't really insist on something you had objected or ignored the criticisms you've made to another proposal that wasn't mine involving [namecanvas]. I can see you may have thought so and that explains how you got annoyed here and on the other thread (where I made the very same proposal), but I'm sorry, you just misread things.

but I see at least 3 other ways to implement this functionality, so we could have a discussion about this

Right on, I'd love to hear what you have in mind. Wanna go ahead and open the new issue yourself?

cheers

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 12, 2019

that didn't really happen, I didn't really insist on something you had objected or ignored the criticisms you've made to another proposal

@umlaeute already summed it up concisely in #794 (comment) but you completely ignored his arguments (using a receive symbol may be not the cleanest way to do implement the desired functionality) and also kept talking about the canvas filename in your next three comments. Look, I'm usually a very patient guy, and

I'm trying to help managing the GitHub issues and I try to be polite, helpful and patient. When I do get annoyed there's often a good reason ;-)

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 12, 2019

 and also kept talking about the canvas filename in your next three comments

Yup, but how? 1) Asked of other 'crucial' use cases of the request (so it could still be worth it, btw). 2) was more of a development than yet another reply, where I said what 'crucial meant', that I too had a use case and was thinking how getting the name still seemed best (which doesn't mean perfect, which doesn't mean we can find a better one, it just means "I can't think of anything else yet").

The 3rd message I reasoned why the given drawback on getting the name wasn't so bad, because I was confronted on it. It's not like I ignored, I just had a thought of my own that wasn't so bad. But it was also on the 3rd message that I said "ok, I also have this new idea then, what do you think?". So I'm arguing you cannot count this one as me insisting on (or ignoring) something...

You make it seem differently, you're trying to portray something else, but the messages are there. I think I've shown how you misread me before when you just didn't get my [namecanvas] proposal, now the issues seem to be the messages before that, but c'mon...

 When I do get annoyed there's often a good reason ;-)

sorry, I think you may have blown this one a bit out of proportion, I was hoping you could concede.

On a constructive note, I'll concede and try to avoid this by trying to be more clear that I'm not really ignoring people - I reckon I usually struggle with communication, it's a constant battle

cheers

@Spacechild1

This comment has been minimized.

Copy link
Contributor

@Spacechild1 Spacechild1 commented Dec 12, 2019

was thinking how getting the name still seemed best

that's the thing. at this point it has already become very clear that the canvas name is useless for this purpose. anyway, we've both made mistakes, so let's bury it.

generally, we should keep in mind that a GitHub issue is not a chat, it's a technical discussion which has to be read by other people. therefore we should try to make each comment as concise as possible, which means: a) think hard before writing b) make it as short as possible

@porres

This comment has been minimized.

Copy link
Contributor

@porres porres commented Dec 13, 2019

a) think hard before writing b) make it as short as possible

guilty as charged

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