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 alreadybroken 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 thisfunctionality?
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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
