[PD] Prototype for adding an object browser into Pd Vanilla's core

IOhannes m zmölnig zmoelnig at iem.at
Fri Mar 10 08:41:24 CET 2023


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


[1] https://en.wikipedia.org/wiki/Bus_factor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230310/093dd76e/attachment.sig>


More information about the Pd-list mailing list