OK... committing a new version of deken... can deken experts please check to make sure I haven't broken something (or let me know if there's any reason this should be done differently :)
thanks Miller
On Wed, May 04, 2016 at 09:52:49AM -0700, Miller Puckette wrote:
Oops, I was looking at the wrong of pd_deken ... I still would like to fix it to always confirm - will now try to code that.
cheers M On Wed, May 04, 2016 at 09:46:04AM -0700, Miller Puckette wrote:
I agree this is a problem. On my machine, selecting (for instance) freeverb~ from the deken plug-in creates a directory ~/pd/extra/freeverb~ which would be a good place to put it except for the fact that that is my git repo (I then have to move it or else I'd end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install into the directory it's planning to install to. Indeed, in the function ::deken::clicked_link I see an appropriate line: set ::deken::installpath [tk_chooseDirectory
(etc) but this never got called when I downloaded freeverb~. I can't figure out why this isn't getting called. Can anyone suggest a way I can get deken to always confirm where it will install?thanks Miller
On Wed, May 04, 2016 at 03:27:27PM +0200, Winfried Ritsch wrote:
Hello,
Deken is really great, but spams my linux home, everytime I load an external.
I suggest since it is now official in vanilla, we should refine now were to store/load externals in linux/debian for future compatibility.
I know it is not deken, but Pd which delivers the paths, but on Standard Linux system which respects
https://specifications.freedesktop.org/basedir-spec/latest/
it should go under .local/share/puredata or .local/lib/pd/ or for old style .pd/ but not on $(Home)/pd-<something>.
So two solution:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
b) Pd suggest as first writeable pathes among others non user-writeable: /var/lib/pd (group puredata set) /usr/local/share/pd, (group puredata set) $(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
so if no ./local it would not take it, but the next suggestion and if in the puredata group which can write to /var/lib/pd take this or
c) deken at least ask where to write it
mfG Winfried
Am Mittwoch, 4. Mai 2016, 13:30:56 schrieb IOhannes m zmoelnig:
On 2016-05-04 10:56, Antonio Roberts wrote:
Now that Pd vanilla + deken is the preferred way to have a Pd-Extended-like experience I was just wondering if there are any best practices or preferred way for loading objects from externals.
Should we reference the external i.e. [mrpeach/binfile] or just load it in our startup path and use [binfile]. The former has the advantage of giving a hint to what externals are needed but results in long objects.
Any suggestions?
*my* suggsetion is to use [declare]
fgamsdrt IOhannes
--
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik 8010 Graz, Inffeldgasse 10/III E-Mail ritsch@iem.at Homepage http://iem.at/ritsch Mobil ++436642439369
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list