Message: 2Date: Wed, 05 Jan 2022 20:19:07 +0100From: Winfried Ritsch <ritsch@iem.at>To: pd-dev@lists.iem.atSubject: Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...Message-ID: <1975418.ThMadnPRZM@ras>Content-Type: text/plain; charset="iso-8859-1"Thank you for the response.Am Mittwoch, 5. J?nner 2022, 13:07:38 CET schrieb Dan Wilcox:On Jan 5, 2022, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 1
Date: Tue, 04 Jan 2022 20:58:02 +0100
From: Winfried Ritsch <ritsch@iem.at <mailto:ritsch@iem.at>>
[1] Error response:
That perhaps looks like a problem with deken itself.
It happens if Pd Document path is disabled and system path cleared.Not really a problem, but previous behaviour starting a file dialog did set the external path, so we have to change this settings before using find externals... anyway an error shouldnt happen.
Sounds like a bug yes. Please open an issue, if there isn't one already.
[2] Also I do not like the recent behaviour to be forced to choose default
folders for externals installation, since also on headless computers when
setup automatically, it cannot answer an file dialog on first startup, I
do not know who had this idea or missed the discussion, to ask for one on
first start of Pd and not as an option to add it later...
Thanks, and one correction to above, not headless but mouseless and keyboardless, on headless it does not ask for default folder.
Ok good. I would be very remiss if Pd hung on a GUI plugin when running -nogui...
I'm not going to rehash the whole thing but I tried to find a compromise for both, even if it's not perfect.
There is a key in the GUI settings for the Documents path which can be set
to "DISABLED" to avoid triggering the initial dialog. This is what is set
when you select No.
ok, so I can do on remote command: $ mkdir -p ~/.config/Pd/org.puredata.pd.pd-gui $ echo DISABLED > .config/Pd/org.puredata.pd.pd-gui/docspath.conf
I don't know the details of the Linux conf handling, but that looks correct.
For macOS, this would be the equivalent:
$ defaults write org.puredata.pd.pd-gui docspath "DISABLED"
Also, the documents directory handling is implemented as a plugin, so it
could be deleted or renamed to avoid it entirely.
I will take a look in this, but better dont touch the pd distributions packages..
Maybe we need to add a plugin override in general (-noplugin "docsdir") or a docspath override specifically, ala -nodocsdir? I tried to make sure if doesn't ask if the home directory is not available or not writable (ala readonly setups), but maybe there can be another hacker-friendly check? Logic is in the plugin init proc:
My original thinking was that if you didn't want the docspath handling, you'd just press No once and never see it again, however if you are working with more than a couple normal desktop installs, this can of course not be the case.