>> On Nov 13, 2015, at 23:23, Christiaan Hofman <cmhof...@gmail.com>
>> wrote:
>>
>>>
>>> On Nov 13, 2015, at 20:52, Adam R. Maxwell <amaxw...@me.com
>>> <mailto:amaxw...@me.com>> wrote:
>>>
>>>
>>>> On Nov 13, 2015, at 04:05 , macula <ir...@me.com
>>>> <mailto:ir...@me.com>> wrote:
>>>>
>>>> Regarding the huge diffs, I am fully in agreement with Michael.
>>>> Autofile
>>>> is a great feature, and so is the preview side panel, and it would
>>>> be a
>>>> pity to view this as an either/or proposition.
>>>
>>> The underlying code for files is pretty complicated, and some if it
>>> has been there since the editor window had a drawer where you could
>>> view a single attached PDF :).
>>>
>>> The fileview and alias code was a massive rewrite, and it's just
>>> not really compatible with the older attachment code. Maybe it could
>>> be changed at the serialization level to only save a path, but
>>> reading
>>> it would then be tricky…
>>>
>>>> I just feel that the new
>>>> BibDesk is somehow rubbing against the aesthetic and openness of
>>>> the
>>>> Bib(La)TeX format.
>>>
>>> I disagree with this; we namespace our private fields with a bdsk-
>>> prefix, to avoid clobbering anyone else's data. By comparison,
>>> I think BibLaTeX is not compatible with BibTeX as it's been defined
>>> for years (notably having changed the semantics of a field or two).
>>> This makes it impossible for BibDesk to support both.
>>>
>>> BibDesk's Date-Modified, Date-Added, Annote, Abstract are exceptions
>>> that predate our notion of private fields.
>>>
>>>> Many if not all of us are scholars and share our
>>>> materials with students and colleagues. Part of the appeal of this
>>>> format is that its plain-text elegance and standardization liberate
>>>> the
>>>> data from any particular software. The very fact that BibDesk now
>>>> presumes to "own" the database is a bit contrary to the philosophy
>>>> of
>>>> BibTeX, I think.
>>>
>>> To be clear, we "own" the bdsk-fields, and other well-behaved
>>> software
>>> should just ignore those. Sharing a .bib and set of attached files
>>> on
>>> a fileserver or cloud is an extremely complicated case, especially
>>> when
>>> multiple users can access it. Apple screws it up regularly, so I
>>> just
>>> prefer not to even try :).
>>>
>>>> More practically, wouldn't this issue be solved if there was a
>>>> scheme
>>>> for storing the links locally in a separate file? I am thinking of
>>>> a
>>>> simple one-to-one index assigning each bibliographic entry
>>>> (identified
>>>> either by its BibTeX key or by a BibDesk-generate UUID) to a list
>>>> of
>>>> links to the entry's attachments?
>>>
>>> Two separate files would be a disaster with Finder copies and
>>> moving/renaming/sharing. I suppose one could store it in the
>>> resource
>>> fork or extended attributes, but that's a different ball of hurt.
>>>
>>> We considered doing this in a number of ways (a new data file
>>> format,
>>> a package-based format). The former died on the vine, and the
>>> latter makes it hard to get to the .bib file for TeX usage, and
>>> isn't
>>> really compatible with version control systems.
>>>
>>>> For the time being, Michael, I am thinking to move my BibDesk-owned
>>>> bib
>>>> file out of the git repo and into dropbox, then use bibtool to
>>>> produce a
>>>> git-friendly version stripped of all links.
>>>
>>> You can probably do this with a template also, or use the minimal
>>> BibTeX export (but that might remove too much).
>>>
>>> I'm not entirely unsympathetic to the problems here, but they're not
>>> trivial to solve in a way that is robust, user-friendly, and
>>> backwards
>>> compatible.
>>>
>>> Adam
>>>
>>
>>
>> Optionally leaving out the alias data would lead to somewhat fragile
>> data, so the link could easily be lost. And it would make it very
>> hard to move the database in your file system. It would certainly
>> lead to data that is not backwards compatible, because currently the
>> link is simply discarded when the alias data is missing. Also, using
>> a full path instead of the alias would generally not solve anything
>> because in general the directory structure on different file system
>> will not match, so such a partial solution would be greatly reduced
>> in value. So though I am also sympathetic to the problem, I am very
>> much ambivalent to whether we should really try to solve this.
>>
>> Christiaan
>
>
> To test some of this out I have added a hidden (boolean) preference in
> the latest nightly build to only save the relative path of the linked
> files. It’s a boolean pref with key
> BDSKSaveLinkedFilesAsRelativePathOnly (see the Wiki on how to set
> this). Be careful though. The data will be much more fragile, and the
> saved data will not be compatible with older versions of BibDesk (i.e.
> before 1.6.4 (3701)). (When you’d open a file saved with this option
> in an older version of BD the linked files will be gone).
>
> 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.
>
> Christiaan
Christiaan, this is wonderful news, many thanks for your work. I will
test as soon as I can take a break one of these days, and will report
back in case I face any problems.
--
View this message in context:
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578390.html
Sent from the bibdesk users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
