include "add object" menu for canvas' right click popup

[porres]

This adds an object menu for inserting Vanilla objects into the patch when right clicking anywhere on the patch (either in edit or run mode). The object is then inserted at the very same position where the right click occured.

See screenshot. For reference

the screenshot is from an experimental tcl/tk plugin prototype. For the code, I have simplified it and inserted a single file and called it just like 'deken' is called.

The older plugin works for Pd 0.53-2 but not in the current master. This Pull Request has been adapted to the current code but does not work in previous versions.

For reference for the older experimental prototype implementation, see https://github.com/porres/object-browser-test-plugin

The change for the current code is that we can't modify the .popup menu at loadtime anymore, since now each menu has its own popup.

I understand that there are other ways to do this by including this into the core so we can discuss implementation details. For now I chose this less intrusive form.

I also understand we can discuss gathering object information from somewhere else instead of this hard coded list. This could be reference .md files, for instance. But since nothing like that is present yet, I believe this can be included as is and further changes be made later when we have the framework for it.

The organization of object categories is a bit different than what we currently have in the current help-intro.pd file, but I am using revision changes that are proposed in my documentation branch PR, see #1897

Cheers

[umlaeute]

I also understand we can discuss gathering object information from somewhere else instead of this hard coded list. This could be reference .md files, for instance.

i don't see any .md files in the Pd repository (and I'm not overly enthusiastic about duplicating documentation in multiple files).
I do see quite a lot of -help.pd files though, which would be a prime target for getting information about an object.

[porres]

i don't see any .md files in the Pd repository

I meant those we're planning to use for an online reference at https://pd.iem.sh/objects/

but I get it's part of this repo, and maybe it should be kept that way, right?

[umlaeute]

but I get it's part of this repo, and maybe it should be kept that way, right?

my idea was mainly to parse the section information at runtime from within Pd.

for this to work, the information ought to be available when Pd is running, so it should be included in the Pd-distribution (and therefore in the main Pd-repository).
also, i think that parsing Pd-files for such information is much simpler than parsing markdown files (ideally we need to extract the front-matter from the .md files, determine whether it's TOML or YAML and then parse that structured data; in practice we might get away with just a simple grep for ^pdcategory, but still...).

[porres]

my idea was mainly to parse the section information at runtime from within Pd.

for this to work, the information ought to be available when Pd is running, so it should be included in the Pd-distribution (and therefore in the main Pd-repository).
also, i think that parsing Pd-files for such information is much simpler than parsing markdown files (ideally we need to extract the front-matter from the .md files, determine whether it's TOML or YAML and then parse that structured data; in practice we might get away with just a simple grep for ^pdcategory, but still...).

Ok, have information about listed objects and their category. The problem with doing this for the help files is that we have multiple objects calling the same help file, so I don't know. In the case of [array] and [file], a single help file also branch up to multiple help files and reference subpatches, so it seems a bit complicated.

So, I'm thinking about it and got the idea to use [help-intro.pd] for such a thing, since now it is actually the only place where the category is explicitly given right now and it's the file that needs to be edited when new objects get in or get deprecated.

But I still don't really know what is the best thing and what needs to be done or how one can parse such information. It just seems like a good place to do it. What do you think?

[porres]

Here's a rough idea, add a [pd meta] under each category. Does this make sense?

[sebshader]

imo at that point it's just as good to have a yaml or json or xml file or something.
I like the idea of the objects in the menu being stored in some files, that way they could be more easily customized/extended by the user.
Also how would category information for a class be determined at runtime? Imo using some object format makes more sense (maybe even tcl arrays in .tcl files)

[umlaeute]

imo at that point it's just as good to have a yaml or json or xml file or something.

until you start parsing yaml/json/xml in Tcl.

Also how would category information for a class be determined at runtime? Imo using some object format makes more sense (maybe even tcl arrays in .tcl files)

???
well, the search-plugin parses the -*.help.pd files for [pd META] (at least in theory), and therein looks for the KEYWORDS identifer, which is just a comment like so:

KEYWORDS control filesystem

it then adds that help-file to the given categories (control and filesystem), and you can get the patch by selecting the filesystem category in the search-browser.

what would the advantage be of putting the category data into a separate file?

[umlaeute]

@porres wrote

Here's a rough idea, add a [pd meta] under each category. Does this make sense?

in practice i think this would complicate things.
suddenly you have to take care of multiple subpatches containing similar data. so you really have to properly handle the subpatches (IIRC the search-plugin actually just ignores the [pd META] and does a search for "KEYWORDS" regardless of actual location for simplicity...)

(I'm aware that I have quite specific ideas how this might work, and I'm talking all other ideas down; sorry for that; feel free to come up with more ideas and implementations...)

[porres]

(I'm aware that I have quite specific ideas how this might work, and I'm talking all other ideas down; sorry for that; feel free to come up with more ideas and implementations...)

I don't really have any ideas and I'm actually pretty fine in manually handling this, the work load is pretty minimal and is already a reality for me when handling documentation issues. Having to add a new object or method to an object is kinda rare and I already have to update it manually by including it into the 'help-intro.pd" file. And I've been the one who'd been keeping track of changes for 'help-intro.pd" for quite a while now...

By the way, I just had to update it and include the new [file] methods to that file, see this last commit 01c56fa

I then did the same revision and added them here as well, see c36c9a2

by the way, I noticed I missed including the tcl file to "Makefile.am" (not 'makefilename', hahaha), so this PR is really ready to go and tested with the source updated to the newly released Pd 0.54!

I don't think it makes sense to keep this as a "draft", please consider making this ready for consideration and we can keep discussing if it's ok for me to just handle thing like I'm already doing.

pinging @millerpuckette

cheers

[danomatika]

I'd say that:

IOhannes is right in that a runtime option would be nicer and probably better in the long run...however this solution works fine, even if it's less flexible.

My 2 cents would be a hybrid solution: a script to generate the object list when building Pd into the plugin tcl, an object meta info tcl or separate txt, etc file. Since the object list is focused on built-in objects so far then this would probably be fine for now.

Then extending to a run-time solution (which could be optional... who knows it might be slow on some platforms, people don't want it, etc) could be done later.

[danomatika]

Ah, I see your original plugin works this way -> object browser is a separate file.

[porres]

I updated my original plugin here https://github.com/porres/object-browser-test-plugin/releases/tag/v0.0.1-aplha

I haven't uploaded to deken, I think it is sufficient to have it here for now or attached as a zip file right here.

object-browser-test-plugin-0.0.1-aplha.zip

It is now a single tcl file.

[porres]

so I accidentally made some undesired commits that were supposed to go to my doc branch, and that I reverted and for me to delete them from history it involves me doing some 'git rebase' and force push that I just can't do as it requires some incredible bureaucracy with creating 'tokens' and passwords and I've hit this wall before... I can reboot the PR or someone can just delete them maybe?

[Spacechild1]

and for me to delete them from history it involves me doing some 'git rebase'

To roll back the last two commits: git reset --hard HEAD~2.

NOTE: this will throw away all local changes!! If you have any uncomitted changes that you want to keep, you first need to stash them.

Then you can force push with git push -f

I just can't do as it requires some incredible bureaucracy with creating 'tokens' and passwords and I've hit this wall before...

??? If you have write access to your branch, you can also force push. This shouldn't require any "bureaucracy". What exactly is your problem?

[danomatika]

It's not complicated, it's this: GitHub removed sending simple passwords as it was a security problem. Instead, you have to generate a token and use that as the password when using the HTTPS git url for the repo. There is no bureaucracy as you can generate one in your account settings but... ...it's much simpler to place a copy of your public SSH key on the GitHub server (again in account settings) and use the SSH git url for the repo. Setting up SSH: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account Changing Git repo urls (on your machine): https://www.howtogeek.com/devops/how-to-switch-a-github-repository-to-ssh-authentication/ Note: newer version of git allow for setting the repo url without having to add/remove via "set-url" git remote set-url origin git://new-repo-url-for-ssh... Also, in the future, I suggest getting into the habit of *always* checking with git status *before* making any commits. This has saved me much trouble in the past.

…

On Jul 6, 2023, at 9:10 AM, umläute ***@***.***> wrote: for a very complicated 'token' mechanism that doesn't really work out for me... that's a bummer, as it means you cannot properly contribute to Pd any more. (you might be able to do it for a while; and you might be able to use the webinterface for changing stuff, but since this means that the code you submit is practically untested, it means that it also generates noise and work for others ;-(). it would be fantastic if you could manage to handle that bit of bureaucracy (for all of us) — Reply to this email directly, view it on GitHub <#1917 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADVK7J5K7DL6L7YZEM5MPLXOZQHJANCNFSM6AAAAAAVZ3A4KM>. You are receiving this because you commented.

-------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

[Spacechild1]

Was going to suggest the same thing as @danomatika: use SSH!