It also goes against one the best things about Pd: peeking under the hood for abstractions. Are adding dependencies/workarounds really worth the time for something that is at most a "nice to have"? (I ask myself this more and more the older I get...)
On Mar 6, 2018, at 6:31 PM, pd-list-request@lists.iem.at wrote:
but if you just want to prevent users from opening up objects in your publicly facing installation
Nope, the idea is just try and make an abstraction behave like a compiled external. I know some people might think that's crazy, ludicrous, pointless, stupid, counterproductive, shameful and just bad... but... I liked the idea :)
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Yeah, like I said, I can see the criticism, but I was hoping to avoid the discussion and just stick to the technical issue if it is possible or not.
Now, in my defense, I can say there could be not so pointless features here. Like, I have a nice GUI abstraction, and people may think it's an external and that they can change its properties, but it's not, so it'd be nice to suppress the properties option, I think. And I don't think it's nice to have a useless and pointless canvas properties for a GUI abstraction. Now, if this were an external, it would just not show any properties, because there isn't one, but when it comes to abstractions, we do not have a choice... Moreover, it wouldn't add any dependency, as this would be for my external library, and the abstraction already has dependencies to other externals in the library.
Now, regarding the clicking thing, I thought one could use it to not only prevent from opening, but also make the object react and do something when clicked. Again, this is something we can do with externals, as you can program an object to react to clicking. In cyclone we have [loadmess] that outputs a loaded message when clicked. In else I have [loadbanger] that can send bangs when clicked.
People would still be able to open and check the abstraction. The documentation would still mention the object is an abstraction and that you can check it out.
Now, this [protect_against_open] object is indeed funny. But it doesn't interfere with the right click options, and is just kinda hardcore, as it'll just close the patch you're working on if you include it, and it also seems it won't ever let you open a subpatch again :) and I can't help but think about this https://www.youtube.com/watch?v=aqAUmgE3WyM haha
Anyway, I'm now throwing a few balls in the air here, like how to prevent from opening when clicking, how to make it respond to clicking, and how to change the right clicking options and suppress some of them (specially properties).
So, one thing at a time, and let me focus on technical issue about being possible or not to suppress the properties option, for starters. So, what do you say?
I have my doubts it's even possible, and I figure if there is a way, it's probably not too trivial.
thanks
2018-03-06 14:41 GMT-03:00 Dan Wilcox danomatika@gmail.com:
It also goes against one the best things about Pd: peeking under the hood for abstractions. Are adding dependencies/workarounds really worth the time for something that is at most a "nice to have"? (I ask myself this more and more the older I get...)
On Mar 6, 2018, at 6:31 PM, pd-list-request@lists.iem.at wrote:
but if you just want to prevent users from opening up objects in your publicly facing installation
Nope, the idea is just try and make an abstraction behave like a compiled external. I know some people might think that's crazy, ludicrous, pointless, stupid, counterproductive, shameful and just bad... but... I liked the idea :)
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
On 03/06/2018 07:23 PM, Alexandre Torres Porres wrote:
Now, in my defense, I can say there could be not so pointless features here. Like, I have a nice GUI abstraction, and people may think it's an external and that they can change its properties, but it's not, so it'd be nice to suppress the properties option, I think. And I don't think it's nice to have a useless and pointless canvas properties for a GUI abstraction. Now, if this were an external, it would just not show any properties, because there isn't one, but when it comes to abstractions, we do not have a choice... Moreover, it wouldn't add any dependency, as this would be for my external library, and the abstraction already has dependencies to other externals in the library.
you know, with [propertybang] your GUI abstraction would (well: could) have *real* properties. not just the generic ones every abstraction has, but properties like GUI externals. which i think is rather more interesting than having no properties menu.
fgadsmr IOhannes
yes, I know, and it's great and awesome, but there might also be the case where you don't really want to have any properties at all, cause it's just a simple abstraction. I have a couple of such examples in my library. And I think it would be worse to come up with dummy properties just for the sake of having properties, just because you're not allowed to not have properties. In other words, it can also be limiting to force it to have properties.
cheers
2018-03-06 15:52 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/06/2018 07:23 PM, Alexandre Torres Porres wrote:
Now, in my defense, I can say there could be not so pointless features here. Like, I have a nice GUI abstraction, and people may think it's an external and that they can change its properties, but it's not, so it'd
be
nice to suppress the properties option, I think. And I don't think it's nice to have a useless and pointless canvas properties for a GUI abstraction. Now, if this were an external, it would just not show any properties, because there isn't one, but when it comes to abstractions,
we
do not have a choice... Moreover, it wouldn't add any dependency, as this would be for my external library, and the abstraction already has dependencies to other externals in the library.
you know, with [propertybang] your GUI abstraction would (well: could) have *real* properties. not just the generic ones every abstraction has, but properties like GUI externals. which i think is rather more interesting than having no properties menu.
fgadsmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2018-03-06 16:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
I have a couple of such examples in my library.
Actually I have much more, dozens of it, as I don't think any non graphical abstraction of mine needs properties! I was just thinking and meant about the graphical ones, which even so don't always need properties... but I forgot to mention about the non graphical ones.
cheers
Hi, today I got back to giving this a chance.
I see tcl/pdtk_canvas.tcl https://github.com/pure-data/pure-data/blob/1c60a514eab4141b708c5df5e6f401d796500088/tcl/pdtk_canvas.tcl has the *proc ::pdtk_canvas::pdtk_canvas_popup* function that deals with this. I was able to make an external that switches this on and off, but for all canvases and patches, by overwriting this function, here's the prototype: https://github.com/porres/pd-else/blob/master/classes/lock.c That's a step further, but still far from what I want, which is to switch it on/off in a subpatch or abstraction. But well, can it even be possible to tweak with this without affecting all of Pd?
Any ideas?
thanks
2018-03-06 18:41 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2018-03-06 16:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
I have a couple of such examples in my library.
Actually I have much more, dozens of it, as I don't think any non graphical abstraction of mine needs properties! I was just thinking and meant about the graphical ones, which even so don't always need properties... but I forgot to mention about the non graphical ones.
cheers
On 2018-04-12 04:02, Alexandre Torres Porres wrote:
subpatch or abstraction. But well, can it even be possible to tweak with this without affecting all of Pd?
Any ideas?
take a look at how this is handled in iemguts' [propertybang].
mgfasdrt IOhannes
Hi, thanks, yeah, I had checked properties before like you suggested earlier. And I see how it has extra code to not make the new properties behaviour affect all canvases. I think I'm ok with that. But I can just use that same logic and put the *tcl* code instead. I have other issues when trying to achieve my goal.
You see, for what I get, [propertybag] uses "class_setpropertiesfn" (declared in m_pd.h and the way to create properties for externals) to add a different properties behaviour, and then hack it to overwrite the behaviour of a canvas. But I'm after removing properties instead off adding them.
So this needs to be accessed and hacked earlier than the stage we're accessing the properties, like when we capture a right click! This seems to be done in g_editor.c https://github.com/pure-data/pure-data/blob/6b42a26d52708a4cc8df18f4901bfa48fc9fbb66/src/g_editor.c in the canvas_rightclick function. If there was a way to set rightclick function in Pd headers, this would be easy and done, but none of this is declared in the Pd headers...
In its turn, canvas_rightclick calls the "*::pdtk_canvas::pdtk_canvas_popup*" function in tcl/pdtk_canvas.tcl https://github.com/pure-data/pure-data/blob/1c60a514eab4141b708c5df5e6f401d796500088/tcl/pdtk_canvas.tcl, and we can mess with that by overwritting it, as the kiosk plugin does. Overwriting it seems to be the only way I can imagine to do this. I can't overwrite canvas_rightclick or other code from g_editor.c https://github.com/pure-data/pure-data/blob/6b42a26d52708a4cc8df18f4901bfa48fc9fbb66/src/g_editor.c, right?
But how to overwrite it only when I'm dealing with a particular canvas? I can't find the answer to this by checking propertybang, and I'm not even sure it can be done in any way.
Please tell me if I'm missing something obvious and an answer to that within the code of propertybang
Thanks
2018-04-12 4:17 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2018-04-12 04:02, Alexandre Torres Porres wrote:
subpatch or abstraction. But well, can it even be possible to tweak with this without affecting all of Pd?
Any ideas?
take a look at how this is handled in iemguts' [propertybang].
mgfasdrt IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 04/12/2018 10:44 PM, Alexandre Torres Porres wrote:
But how to overwrite it only when I'm dealing with a particular canvas? I can't find the answer to this by checking propertybang, and I'm not even sure it can be done in any way.
why would you want to do that on the tcl side?
you could also just use iemgut's [canvaslock] object, which i think does exactly what you want. (and if you insist in taking the code to duplicate the object, please honor the GPL)
fdmasr IOhannes
IOhannes m zmölnig wrote:
On 04/12/2018 10:44 PM, Alexandre Torres Porres wrote:
But how to overwrite it only when I'm dealing with a particular canvas? I can't find the answer to this by checking propertybang, and I'm not even sure it can be done in any way.
why would you want to do that on the tcl side?
you could also just use iemgut's [canvaslock] object, which i think does exactly what you want.
could it be that this object is not included in the official distribution ?
IEMGUT's deken version is v.0.2.1 and it doesn't include an object called [canvaslock].
at least not here on my machine which is Win7 / 64bit / PD 0.48.1
best
oliver
could it be that this object is not included in the official distribution ?
it's only about an hour old :-). checkout the github repo: https://github.com/iem-projects/pd-iemguts
Gesendet: Samstag, 14. April 2018 um 00:12 Uhr Von: oliver oliver@klingt.org An: "pd-list@mail.iem.at" pd-list@mail.iem.at Betreff: Re: [PD] avoid "properities"/"open" options in abstractions
IOhannes m zmölnig wrote:
On 04/12/2018 10:44 PM, Alexandre Torres Porres wrote:
But how to overwrite it only when I'm dealing with a particular canvas? I can't find the answer to this by checking propertybang, and I'm not even sure it can be done in any way.
why would you want to do that on the tcl side?
you could also just use iemgut's [canvaslock] object, which i think does exactly what you want.
could it be that this object is not included in the official distribution ?
IEMGUT's deken version is v.0.2.1 and it doesn't include an object called [canvaslock].
at least not here on my machine which is Win7 / 64bit / PD 0.48.1
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yeah, I was like "does this object really exist?" :)
But then, this is not what I was looking for. I can see it doesn't allow you to open the subpatch, but it still shows the "open" option in the menu when you right click it. I know there can be different strategies to achieve practically equivalent results, but I'm not looking into alternatives, I'm just trying to find a way to code an external that allows me to avoid the "properities"/"open" options when you right click abstractions.
IOhannes m zmölnig wrote:
why would you want to do that on the tcl side?
As of yet, I can't see any other way to achieve this.
cheers
Hi, I just learned that the Gem library similarly achieves what I wanted somehow...
If you don't have the Gem library in the startup, you can load an abstraction like gemmouse and click it to open or right click it and get all the options (properties, open, help). But when the library is loaded, this gets locked somehow and doesn't affect all canvases and abstractions.
The code of Gem is quite big and I can't seem to find where and how it does that. It doesn't seem to use "canvas_rightclick" or " ::pdtk_canvas::pdtk_canvas_popup". Any help please?
thanks
2018-04-13 20:29 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Yeah, I was like "does this object really exist?" :)
But then, this is not what I was looking for. I can see it doesn't allow you to open the subpatch, but it still shows the "open" option in the menu when you right click it. I know there can be different strategies to achieve practically equivalent results, but I'm not looking into alternatives, I'm just trying to find a way to code an external that allows me to avoid the "properities"/"open" options when you right click abstractions.
IOhannes m zmölnig wrote:
why would you want to do that on the tcl side?
As of yet, I can't see any other way to achieve this.
cheers
well, I'm now confused, cause it was mentioned how Gem automatically adds a path to Pd to load abstractions, so I was testing that even though I never used Gem, and I was checking its abstractions, like gemmouse, to see if it was instantiated without the path added. It got created, but I couldn't open it as a normal abstraction in the patch. But it seems actually that there is also a [gemmouse] object inside Gem... which would explain all this...
2018-04-19 18:09 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Hi, I just learned that the Gem library similarly achieves what I wanted somehow...
If you don't have the Gem library in the startup, you can load an abstraction like gemmouse and click it to open or right click it and get all the options (properties, open, help). But when the library is loaded, this gets locked somehow and doesn't affect all canvases and abstractions.
The code of Gem is quite big and I can't seem to find where and how it does that. It doesn't seem to use "canvas_rightclick" or " ::pdtk_canvas::pdtk_canvas_popup". Any help please?
thanks
2018-04-13 20:29 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Yeah, I was like "does this object really exist?" :)
But then, this is not what I was looking for. I can see it doesn't allow you to open the subpatch, but it still shows the "open" option in the menu when you right click it. I know there can be different strategies to achieve practically equivalent results, but I'm not looking into alternatives, I'm just trying to find a way to code an external that allows me to avoid the "properities"/"open" options when you right click abstractions.
IOhannes m zmölnig wrote:
why would you want to do that on the tcl side?
As of yet, I can't see any other way to achieve this.
cheers
On 2018-04-20 05:52, Alexandre Torres Porres wrote:
well, I'm now confused, cause it was mentioned how Gem automatically adds a path to Pd to load abstractions, so I was testing that even though I never used Gem, and I was checking its abstractions, like gemmouse, to see if it was instantiated without the path added. It got created, but I couldn't open it as a normal abstraction in the patch. But it seems actually that there is also a [gemmouse] object inside Gem... which would explain all this...
yes. but i wasn't talking about this.
gmasdr IOhannes
-
Alexandre Torres Porres -
Christof Ressi -
Dan Wilcox -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
oliver