On 05/27/2011 05:37 PM, Hans-Christoph Steiner wrote:
It wouldn't be hard to code this in C, the question for me is what would
the interface be, both in terms of coding in Tcl and the GUI itself.
I wouldn't spend too much time on this but rather move on and completely
separate pd and its GUI so all these kind of GUI goodies would be a snap
to add (my 0.02€).
This plugin is really looking quite amazing. I am curious about the
send/receive symbols in it. Does it use all s/r symbols that are active?
That list could get quite long, but I guess that's what it is supposed
to do.
alas no, I thought this would be the way to go until I realized that you
can't access subpatches/abstractions objects (or can you?). therefore I
decided to add to completion list any *new* s/r symbols (and same for
table, throw~, etc). I designed this with a livecoding approach in mind.
One little deployment suggestion: the 'extra_objects' folder is a good
idea with auto-loading the text files, etc. I think it would be easiest
if it just loaded any .txt file that was in 'extra_objects', then people
could just drop their own custom ones in there without having to edit
the completion-plugin.tcl. Then the add_libraries_externals loading
logic could try loading a standard filename like completion.cfg from
each of the loaded libraries. So anyone can add a 'completion.cfg' to
their library, and it'll be loaded. Perhaps that's a bigger problem than
should be tackled now, but I'm thinking it would be very nice, and not
too hard to make the completion context aware, so that the completion
list would be per-patch. I.e. taking into account [import mylib], etc.
the *.txt solution would be better indeed, but I won't have much time soon.
pull requests on my github are of course welcome ;)
being aware of [import] might be a bit too much as this plugin is rather
hacky already.
cheers,
_y
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
