On 05/04/2016 03:27 PM, Winfried Ritsch wrote:
a) Deken should not take just pathes from pd but try preferred ones and add pathes to pd on startup
i strongly oppose. it's Pd's job to use sensible default search paths, and deken should follow the lead. put otherwise: there should only be a single central place where the default search paths are defined, and this ought to be within Pd-core (since deken is just a GUI addon, that won't unfold it's power if there was no gui)
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)
i don't think that either of those places is the correct place.
continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files." - this is definitely *not* addon libraries.
(shared) data." and most Pd-libraries (installed via deken or otherwise) are architecture dependent binaries.
$(HOME)/.local/lib/pd $(HOME)/pd-external
and deken decides: if the parent dir is writeable it create it and uses it.
deken did this in the past. it ended up creating ${HOME}/pd-externals (which we all hate), because ${HOME} is the only place of all your proposals that is (almost always) guaranteed to exist *and* writable by the user.
so now deken does something similar: if the directory itself exists and is writeable, it uses it. else it asks the user.
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
well, you can already do this:
apart from the last bit, nothing is related to Pd; i therefore think that it is *not* Pd's task to do anything of it (*maybe* this can be added to a puredata.deb or .rpm)
c) deken at least ask where to write it
which is what it does.
gasmr IOhannes