Ok, Thanx for the detalis. Anyway before concluding this thread I must said that this year I've been connecting the pref.file to 2 things:
Purr-Data : https://lists.puredata.info/pipermail/pd-list/2017-01/117407.html Deken : If necessary the pref.file can hold the deken path.for.externals. And most importantly I connected the pref.file cuz Miller announced it this year for Win & Mac. Do you think there's need to add a couple of things to the actual prefs? Font metrics? Deken path? Salutti, Lucarda. Mensaje telepatico asistido por maquinas. ________________________________ From: Pd-list <pd-list-boun...@lists.iem.at> on behalf of IOhannes m zmoelnig <zmoel...@iem.at> Sent: Monday, February 20, 2017 10:15 AM To: pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file. On 2017-02-20 03:08, Lucas Cordiviola wrote: >> What are the practical problems with using the current >> format for the Pd preferences file under Linux? > > I don't know, so you would like to replace tried-and-tested code with something else that is known to be hard to implement correctly. for no appararent reason (apart from breaking compatibility). i would say, this is a strinct "nono" apart from that, XML is a buzzword of the 90ies, and has been superceded by various better formats. nobody in their right mind would jump on the XML train these days (OSX's plist is an XML file; but it has been like that for ever; they also haven't changed it to json or whatever, probably because they also prefer to not replace tried-and-tested code with new buggy code for no apparaent reasons.) > I'm a windows user, and think that the linux .pdsettings will be a better > substitute for the actual windows method of writing in the registry. how so? the differences between the .pdsettings stored on the filesystem resp. in the w32 registry are really small. the registry entry is really just the .pdsettings, but with the data stored on a "virtual filesystem" (the registry), that already provides a parser for the key/value mapping required by .pdsettings. i think part of the hate for the registry stems from the repeated mantra that "you can kill your system if you don't know what you do when editing the registry". in principle, i think the mantra is correct. but the problem does not come from the registry itself, but because you can shoot your system if fuck your system configuration. moving the system configuration to the filesystem would only change the mantra to "you can kill your system if you don't know what you do when editing files". (which is correct as well). > And think that it should live on the pd/bin dir & not in a user dir. hmm, no. in general, the pd/bin dir is a read-only directory. this is a good thing, as it helps ensuring that some random malware you just clicked on in InternetExplorer10 won't be capable of changing Pd itself (if you can write to pd\bin to create your preferences file, then you can also replace pd\bin\pd.exe) things might be different on *your* personal setup, e.g. because you run Pd from a FAT32 formatted USB-stick (which doesn't allow any access control); or because you are running all applications as Administrator (which bypasses a lot of access control). but that doesn't change the general principle¹. some things have changed since the 80ies... also, there is a very good reason that virtually all OSs have agreed on central storage locations for configuration *besides* the application-folders. > to disallow sharing prefs. on multiple installations. (Pd, Purr-Data, PsVST) hmm, no. the proper way to disallow sharing prefs, is by using different namespaces for all these projects. if Pd-vanilla uses ~/.pdsettings and ~/.config/pure-data/ for its configuration, then other programs simply should not (if they don't want to share prefs, that is). instead they should use ~/.config/pd-l2ork/ or whatever. problem solved. if you do want to have multiple configurations for the same flavour of Pd (e.g. pd-vanilla), you can already simply use batch-files. all the things settable via the config are also settable via cmdline args (if they are not, you should file a bugreport). "pd -noprefs -jack -channels 16". fgadr IOhannes ¹ having said this, there *is* already a way to embed preferences on OSX and linux alongside your binary. just put a default.pdsettings file into your PD directory (on linux) or a plist-file with the name of "org.puredata.pd" into your App-bundle (on OSX). this seems to be somewhat broken, at least on linux (it get's ignored if you also have a ~/.pdsettings file), and might be worth fixing.
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
