To be fair, Deken puts things in ~/pd-externals because it was there and working already without requiring *yet another patch*. Having a base place to install externals fixes the need to install directly to extra on platforms where that doesn’t make sense aka within OSX app bundles.
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2015, at 1:00 PM, pd-dev-request@lists.iem.at wrote:
here are a couple more (perhaps more minor) ones: Searching a fixed directory like "~/pd-externals" is a rotten idea - I don't know why I ever accepted it as an idea. And now the "deken" engine puts patches there!
"." in a path means "the current directory" when it should have meant "the
directory this patch right here is in". Actually, I'm mostly concerned with the common case, which is the userwho doesn't do anything at all-- no [declare], no clue what a "path" is, justmodularity from dropping an abstraction in "the directory this patch right hereis in". We can't even assume that this class of user knows what "/" or "./"means. They may only be familiar with the file system from a native dialog.(And even that may be secondary to just auto-saving junk in the cloud.) This is the user targeted by your tutorial #12: "There is a separate file in this directory named 'sendnumber.pd' which is loaded every time you type 'sendnumber' in an object box."
This is the logic that allows a user to ship a zip-file of their patch and its"helpers", and be sure that it works as they intend on any other user'scomputer. The closer we can get to guaranteeing the quoted sentence to always be true, the better.
As I understand it, IOhannes' change to the loader search order gets uscloser to this. I asked about user control of the loader order because there may be caseswhere the user really wants abstractions first, and binaries second. But thecases I can think of have to do with overriding internal classes, so that'sprobably outside the scope of this patch set. -Jonathan
On Thursday, September 24, 2015 3:23 PM, Dan Wilcox danomatika@gmail.com wrote:
To be fair, Deken puts things in ~/pd-externals because it was there and working already without requiring *yet another patch*. Having a base place to install externals fixes the need to install directly to extra on platforms where that doesn’t make sense aka within OSX app bundles. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Sep 24, 2015, at 1:00 PM, pd-dev-request@lists.iem.at wrote: here are a couple more (perhaps more minor) ones: Searching a fixed directory like "~/pd-externals" is a rotten idea - I don't know why I ever accepted it as an idea. And now the "deken" engine puts patches there!
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
-
Dan Wilcox -
Jonathan Wilkes