Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...
On Jan 6, 2022, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Wed, 05 Jan 2022 20:19:07 +0100 From: Winfried Ritsch <ritsch@iem.at mailto:ritsch@iem.at> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: 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 mailto: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 <mailto: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...
A very long discussion went on, part of which ended up as a proposal:
https://github.com/pure-data/pure-data/pull/152 https://github.com/pure-data/pure-data/pull/152 <https://github.com/pure-data/pure-data/pull/152 https://github.com/pure-data/pure-data/pull/152>
Thank you for the hint, now I understand... I am too late for respones ;-).
... anyway I thought Pd is gentleware: respectful to environments, not wolvesware which tend to leave their marks everywhere where they can ... but maybe it's only us old hacker generation, the younger generation got used to it.
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:
https://github.com/pure-data/pure-data/blob/master/tcl/pd_docsdir.tcl#L40 https://github.com/pure-data/pure-data/blob/master/tcl/pd_docsdir.tcl#L40
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.
mfg winfried
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at mailto:ritsch@iem.at - http://iem.at/ritsch http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Thank you for the hint, now I understand... I am too late for respones ;-).
... anyway I thought Pd is gentleware: respectful to environments, not wolvesware which tend to leave their marks everywhere where they can ... but maybe it's only us old hacker generation, the younger generation got used to it.
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:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... >
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.
(other stuff deleted from thread)...
Here's a modest idea for an improvement - perhaps when Pd is started from itself, not from the GUI, it should regard a missing docspath as meaning not to ask, but when it's started form the TCL/TK layer we'd stick with the current behavior.
cheers Miller
Am 6. Jänner 2022 18:58:47 MEZ schrieb Miller Puckette via Pd-dev pd-dev@lists.iem.at:
Here's a modest idea for an improvement - perhaps when Pd is started from itself, not from the GUI, it should regard a missing docspath as meaning not to ask, but when it's started form the TCL/TK layer we'd stick with the current behavior.
+1
mfg.sfg.jfd IOhannes
-
Dan Wilcox -
IOhannes m zmölnig -
Miller Puckette