Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmoelnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

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 :

> 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 :
>
>> 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
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

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 :

> 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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Christof Ressi]

> 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 <oli...@klingt.org>
> An: "pd-l...@mail.iem.at" <pd-l...@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
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[oliver]

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

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

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

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
,
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
,
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 :

> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmoelnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

Hi, today I got back to giving this a chance.

I see 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 :

>
>
> 2018-03-06 16:02 GMT-03:00 Alexandre Torres Porres :
>
>> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

2018-03-06 16:02 GMT-03:00 Alexandre Torres Porres :

> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

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 :

> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmölnig]

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



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

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 :

> 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-requ...@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 
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmölnig]

On 03/06/2018 06:29 PM, Alexandre Torres Porres wrote:
> 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 :)

it *is* pointless.

apart from that, the iemlib (iemlib2 to be precise) has an (equally
pointless) object called [protect_against_open] which will just close
the canvas whenever you try to open it.

gfrdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[Alexandre Torres Porres]

2018-03-06 6:34 GMT-03:00 IOhannes m zmoelnig :

> On 2018-03-06 00:53, Alexandre Torres Porres wrote:
>
> the right-click menu can be changed


Ok, but how about being suppressed? Can it be?


> (e.g. see the iemguts' [propertybang] object, which changes the effect of
> the "Properties" item
> in the menu, and requires some extra code to hide this for canvases that
> don't have a a [propertybang] object).
>

Awesome!!! And I guess one can use this and then don't do anything with the
bang output, this would effectively avoid the canvas properties from
showing up, but my ideal concept would be completely hide and avoid the
"properties" option to be highlighted and show up.

I wonder if it is possible at all... [propertybang] shows us how to change
and mess with it, but how would you actually hide the properties?


> 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 :)

Thanks!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] avoid "properities"/"open" options in abstractions

[IOhannes m zmoelnig]

On 2018-03-06 00:53, Alexandre Torres Porres wrote:
> Hi, I'm looking for a way to avoid "properties" from popping up as an
> option when right clicking in an abstraction.
> 
> This is not really "important", basically only merely aesthetical, as I
> want to make abstractions look more closely as compiled objects... but
> anyway, please don't judge :)
> 
> So, is there a way to do it? Like an external out there? If not, I guess I
> need to figure out how to make my own...
> 
> Moreover, I'm also after a way to avoid clicking on an abstraction and
> opening it, or also even preventing the "open" option from the right click
> menu as well.

the right-click menu can be changed, but this would apply to *all*
abstractions, not just specific ones (e.g. see the iemguts'
[propertybang] object, which changes the effect of the "Properties" item
in the menu, and requires some extra code to hide this for canvases that
don't have a a [propertybang] object).

but if you just want to prevent users from opening up objects in your
publicly facing installation, i'd do:
- make all public objects GOP (even if they are not effectively showing
anything, this will prevent the abstraction from being opened by "just
clicking")
- use the kiosk-plugin to disable the right-click menu completely
(HidePopup True), so the abstractions cannot be opened via the
context-menu either.

fgmasdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list