Hi everyone, I made a prototype of a GUI addition that I would really like to have included in the Pd-Vanilla distribution. I don't don;t think it is worth or plan to provide it as a tcl/tk plugin and I'll get to that soon. Nonetheless, as a prototype for anyone to easily test, I did upload object-browser-test-plugin to deken and you can get it. You can also check https://github.com/porres/object-browser-test-plugin
And what does it do? When you right click anywhere on a patch canvas you can go to 'add object' which gives you a menu of all Pd objects that you can then choose from and it'll add the element exactly where you right clicked at. This is possible regardless if you're in edit or run mode. See screenshot below.
[image: Screen Shot 2023-03-10 at 02.32.26.png]
I got the idea and basis from Pd-ceammc, by the way. But PlugData is also working on something similar, why not offer an official one upstream?
As someone who uses Pd to teach newbies all the time, I believe something like this would help them much more in the learning curve. The general consensus from users when I mentioned this on the facebook group (and other places) was quite positive. I understand though that there might be concerns in maintaining this and keeping the core light.
Well, if it gets included, I plan to take care of it and do things like insert a new object whenever it comes up as long as I live. I am relatively young and don't have plans to die soon. This would be part of my documentation engagement. And once it is in, I guess the load won't be relevant.
I think this is problematic to keep as a plugin as it'll mostly be missed by users. Another problem is that I think it is hard to maintain this out of the core and I say this because while my plugin works now, it is already broken for the current master on github, so it won't work on the next update. It really makes sense to keep this in the core then.
By the way, it already includes the not yet released [snake~ in]/[snake~ out] objects, and when I wanted to test this with the latest current version is when I found out it breaks. But it works up to 0.53-2 (at least with its test version that you can find).
And yes, I added options for objects that have a function defined by the 1st argument (such as [array random]), [snake~ in/out], ect). I also added options to add GUIs, message boxes, list box, etc...
Is anyone bummed out and would have some sort of issue with this functionality? Worst case scenario I guess would be to allow some configuration in preferences to disable this, but I can't see this as an annoying addition. I think that even for me (someone who revised and wrote references for ALL objects) this is useful, as even I can forget the name of an object sometimes...
what are your thoughts?
cheers
On 3/10/23 06:57, Alexandre Torres Porres wrote:
Hi everyone, I made a prototype of a GUI addition
thanks for working on this.
that I would really like to have included in the Pd-Vanilla distribution.
however, i wonder what makes your plugin different from any other plugin, that warrants its inclusion into main Pd?
I think this is problematic to keep as a plugin as it'll mostly be missed by users.
yes, that is how it is. but it is true for virtually all gui-plugins and externals. (heck, it is even true for Pd itself). so what makes your plugin different from e.g. the "dnd-plugin"?
i think (but here i am heavily biased), that a plugin like my tip-of-the-day plugin could solve this general problem (by creating tips that announce especially useful plugins). but even tip-of-the-day is not included with Pd itself :-) (but then, i do have plans to change that.. exactly because it is supposed to solve the problem of pushing new information to the users).
Well, if it gets included, I plan to take care of it and do things like insert a new object whenever it comes up as long as I live. I am relatively young and don't have plans to die soon.
while i think your engagement is great (and amazing, regarding the amount of work you invest), i think this is really a bad proposal from the "Bus factor" [1] point of view.
priorities in life are constantly shifting. we had super-engaged maintainers (of entire Pd-distributions!) who have ceased their Pd-related activity completely (without having "died" or anything similarily drastic; just their life has changed).
personally, I do not know what will happen in my life (i'm marginally older than you; and have no intention to die soon either), do you? (sidenote: yes, i do consider the bus-factor with my Pd-involvement an unpleasant problem)
Another problem is that I think it is hard to maintain this out of the core and I say this because while my plugin works now, it is already broken for the current master on github,
then i think the architecture is broken and it should definitely *not* be included with Pd itself.
i think it is really crucial that the structured information on objects (that is: their existence, and the categories they belong to), is not encoded/stored in any *other* place (like your object_tree.tcl file).
i think the only maintainable option is really to extract this information from the available objects themselves.
consider the "search-plugin". it dynamically gathers all information it needs at startup. why can the object-browser not do the same?
consider the "completion-plugin". it dynamically gathers all information it needs at startup. why can the object-browser not do the same?
consider my "tip-of-the-day" plugin, which can fetch its data from some online resources (because it's impossible to come up with a tip about plugins that haven't been written yet.)
Is anyone bummed out and would have some sort of issue with this functionality?
i don't have any objections regarding the functionality. but as long as it requires manually maintaining a database of any change in the objects, i strongly believe that the architecture ought to be reconsidered.
gmds IOhannes
Great idea Alexandre
Loads of wisdom, IOhannes
The one bit that stick with me is this:
but as long as it requires manually maintaining a database of any change in the objects, i strongly believe that the architecture ought to be reconsidered.
Even if it stays as a plugin/extension/whatever, having a call to the pd api to list all content of registered/loaded/downloaded externals would be great. Then adding a category to the Decken distribution and there is a taxonomy that is programmatic and everyone can join in…
My 2c
Am 10. März 2023 10:34:52 MEZ schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
Great idea Alexandre
Loads of wisdom, IOhannes
The one bit that stick with me is this:
but as long as it requires manually maintaining a database of any change in the objects, i strongly believe that the architecture ought to be reconsidered.
Even if it stays as a plugin/extension/whatever, having a call to the pd api to list all content of registered/loaded/downloaded externals would be great. Then adding a category to the Decken distribution and there is a taxonomy that is programmatic and everyone can join in…
Actually there is (was?) such parsable information embedded in help-patches and the <library>-meta.pd files (btw this parsable info is the raison d'etre for the meta files). That was proposed about 15 years ago...
mfg.sfg.jfd IOhannes
But is there a way to read programmatically the state of ‘installs’ ? If so then this new addition of a menu would tap into it and voilà, low/no maintenance and custom, situated content!
On 10 Mar 2023, at 09:46, IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 10. März 2023 10:34:52 MEZ schrieb Pierre Alexandre Tremblay tremblap@gmail.com:
Great idea Alexandre
Loads of wisdom, IOhannes
The one bit that stick with me is this:
but as long as it requires manually maintaining a database of any change in the objects, i strongly believe that the architecture ought to be reconsidered.
Even if it stays as a plugin/extension/whatever, having a call to the pd api to list all content of registered/loaded/downloaded externals would be great. Then adding a category to the Decken distribution and there is a taxonomy that is programmatic and everyone can join in…
Actually there is (was?) such parsable information embedded in help-patches and the <library>-meta.pd files (btw this parsable info is the raison d'etre for the meta files). That was proposed about 15 years ago...
mfg.sfg.jfd IOhannes
On 3/10/23 11:06, Pierre Alexandre Tremblay wrote:
But is there a way to read programmatically the state of ‘installs’ ? If so then this new addition of a menu would tap into it and voilà, low/no maintenance and custom, situated content!
how does the search-plugin do it? the Pd-GUI knows which paths are searched by Pd, and can use this action.
what it does not know is, when a new library is actually *loaded*¹ and which new objects are now known (e.g. after Gem, you suddenly have a [square] object).
newly added objects cannot be deduced from the search-paths. so it would indeed require a way to query the list of objects known to Pd. E.g. the GUI could be given a list of all known objectclasses and their corresponding help-patches (and this list would need to be updated whenever a new objectclass is loaded). the help-patches can be parsed to get the categories for a given object.
you probably also need a bit of context, as some objects are not available in all canvases (think abstractions and [declare -path]; future versions of Pd might also extend this patch-locality to libraries and [declare -lib]) - so when designing such an API, one should keep this in mind.
of course it is much easier, if you only take built-in objects into account (as is currently the case).
gfmdsar IOhannes
¹ this is not a problem for the search-plugin, as this will only give you patches, that are hopefully useable on their own.
Em sex., 10 de mar. de 2023 às 04:42, IOhannes m zmölnig zmoelnig@iem.at escreveu:
however, i wonder what makes your plugin different from any other plugin, that warrants its inclusion into main Pd?
It may be subjective, but my case is, this is very very simple and an addition that is aimed at improving the functionality of Vanilla. I take plugins to be more complex and that require much more maintenance, development. We can debate this in detail and compare to other plugins.
so what makes your plugin different from e.g. the "dnd-plugin"?
This one for instance, a quite particular example and this is one that I think it's very problematic. I would like if Pd could have an 'actual' drag and drop feature, but this is just bad and doesn't work well if you ask me. It is a bit complex and has a good number of features, it allows one to throw a Pd patch into the console so it opens, which you can also do by simply double clicking on the object, what's the advantage? It can drag and drop texts from a website into the canvas and create a comment, not something you do a lot and not that much more convenient than doing "control c/v" (which also works for other cases that this plugin doesn't work). It can include an abstraction into the patch, but drag and drop seems more useful for files. For adding an external abstraction object, seems to make more sense to me an autocomplete function or something exactly like my thing, where you see a menu of options and easily include. This plugin also comes with some externals, so I wouldn't call it a plug in but a library. It actually needs new or a change in the objects, and I just can't seem to make some of them work... what I wanted from a drag and drop feature is just throw any file into something like [openpanel] and make it output its path, and yeah, there's one object in that does it, but it does so much more and the "receive" has more than 10 different information. To sum it up, I would love a native drag and drop thing, for sure, not this one though as it is kinda overcomplicated and rather feature creep. Instead, it could be a simple addition to openpanel. As this is something that I'd like to see in the core, I could try and do it, but it doesn't seem like something simple and it requires quite a load of code for something that is not that crucial... banging on openpanel and browsing files is not that worse... in this case, I also wonder if just a simpler and better designed single external with this extra sugar could do it and I'm thinking of adding such an external into else :)
There are not that much other plugins out there to compare, but I would compare this to 'triggerize', that is still downloadable as a plugin (maybe we should delete it?) but was incorporated into Pd because it seemed like a useful and simple addition (much more than 'dnd').
So I can return the question, what makes this addition I'm proposing different from triggerize?
then i think the architecture is broken and it should definitely *not* be included with Pd itself.
We'd have to get into the details. The fact is that the core tcl/tk code got some changes I'd like to know more about the needed reasons. I could be wrong, but it could just be some API change that breaks things and this would not be the first time this happened. I don't understand the code well either and I'm just starting to try and actually learn tcl/tk. I'm amazed I could already learn a few things and do some stuff with this plugin. Not being able to deal with tcl/tk has been a major blockage in my development and I finally intend to work on it because now I wanna focus more on GUI externals and stuff.
i think it is really crucial that the structured information on objects
(that is: their existence, and the categories they belong to), is not encoded/stored in any *other* place (like your object_tree.tcl file).
i think the only maintainable option is really to extract this information from the available objects themselves.
yeah, I thought about something like this.
i don't have any objections regarding the functionality. but as long as it requires manually maintaining a database of any change in the objects, i strongly believe that the architecture ought to be reconsidered.
Cool, good point. Thanks
gmds IOhannes
[1] https://en.wikipedia.org/wiki/Bus_factor
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Well, I made a PR, see https://github.com/pure-data/pure-data/pull/1917
The current PR code now works with the current master but not in older versions. You can still use my test plugin which is online for tests and feedback.
Em sex., 10 de mar. de 2023 às 14:16, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 10 de mar. de 2023 às 04:42, IOhannes m zmölnig zmoelnig@iem.at escreveu:
then i think the architecture is broken (...)
(...) the core tcl/tk code got some changes I'd like to know more about the needed reasons. I could be wrong, but it could just be some API change that breaks things and this would not be the first time this happened.
I still believe so. By the way, I also opened an issue for the patcherize plugin that seems to have some bugs with the current 0.53 releases, so I think it's kind of the same deal and not a prior architecture problem. Or maybe I don't get what this means.
as long as it requires manually maintaining a database of any change
in the objects, i strongly believe that the architecture ought to be reconsidered.
I understand this concern, like I said before, but since this would require lots of discussion and other intrusive core changes, I just went ahead and made this PR as it is (and I discuss this in the PR description).
I guess we can further discuss this here and/or over there (maybe there is better?)
cheers
Em seg., 13 de mar. de 2023 às 23:36, Alexandre Torres Porres < porres@gmail.com> escreveu:
Well, I made a PR, see https://github.com/pure-data/pure-data/pull/1917
The current PR code now works with the current master but not in older versions. You can still use my test plugin which is online for tests and feedback.
Well, the test plugin doesn't work with the newly released 0.54 and was already outdated, so I just removed it. I mentioned I don't have plans or wishes to maintain this as a plugin anyway. The PR has been updated and includes the new additions to 0.54 on the other hand.
I'm doing something similar for ELSE's objects and I've been testing it in class and everything and it all works pretty great.
I'd like to ask other people testing this PR anyway, for general feedback and just in case.
One easy way to test it though is just getting the tcl file, rename it as a plugin and put it in your externals folder.
here's a renamed file for it attached.
as long as it requires manually maintaining a database of any change
in the objects, i strongly believe that the architecture ought to be reconsidered.
I understand the concern, but we discussed it in the PR and no easy and or simple solution came up. So I hope this is considered as is, but further changes can be made later when and if we have the framework for it.
Nonetheless, having to manually edit and keep track of things is already needed for "help-intro.pd" and I've been already taking care of that for the last 6 releases or so, I don't mind the minimal work load addition and taking care of this in my usual documentation branch. This is literally nothing compared to the work I'm having adding 'references' and maintaining them.
cheers
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Pierre Alexandre Tremblay