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