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

[Alexandre Torres Porres]

Em sex., 10 de mar. de 2023 às 04:42, IOhannes m zmölnig <zmoelnig at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20230310/e18c1cd5/attachment-0001.htm>