I am not convinced that a new field type is necessary here for several reasons: What happens if you should have both fields in a record? Why supporting files to be anywhere in case of relative paths? I believe that most use cases interested in a relative path need only a common root path to which to concatenate the relative path. Thus one could enforce such a common root (for this new hidden pref) and always extract the wanted relative path from an absolute path as contained in the existing field type. Following some rules, e.g. using the global pdf repository path as that common root, would already suffice to define what part of the absolute path is to be ignored.
Regards, Andreas ETH Zurich, Prof. Dr. Andreas Fischlin, Systems Ecology CHN E 21.1, Universitaetstrasse 16, 8092 Zurich, SWITZERLAND Tel: +41 44 633-6090 - Mobile: +41 79 595-4050 - mailto:[email protected] www.sysecol.ethz.ch/people/afischli > On 19 Nov 2015, at 18:01, Maxwell, Adam R <[email protected]> wrote: > > >> On Nov 19, 2015, at 02:44, Christiaan Hofman <[email protected]> wrote: >> >> For now this is just for testing purposes. I am not sure what to do with >> this, whether to advertise this on the Wiki, integrate this as an actual >> pref (that could be dangerous), or remove it later. > > Just spitballing, but the only safe way I see to make it an actual pref is by > adding a new field type (like Bdsk-Path-n) and doing a conversion process > when opening and saving. > > -- > Adam > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bibdesk-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bibdesk-users ------------------------------------------------------------------------------ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
