On 10 Nov 2007, at 1:47 AM, Hendrik wrote: > On Nov 9, 2007 2:28 PM, Christiaan Hofman cmhofman-at-gmail.com > |Sourceforge| <...> wrote: >> >> >> On 9 Nov 2007, at 11:00 PM, Hendrik wrote: >> >>> >>> On 9-Nov-07, at 12:54 PM, Christiaan Hofman cmhofman-at-gmail.com | >>> Sourceforge| wrote: >>> >>>> >>>> On 9 Nov 2007, at 9:26 PM, Hendrik wrote: >>>>> >>>>> To get all entries changed from absolute to relative paths take >>>>> these >>>>> steps: >>>>> 1) Change the auto-file preference settings to relative. >>>>> 2) Select all papers and choose Publication->Consolidate Linked >>>>> Files >>>>> If the path for some or all papers would stay the same (that >>>>> is, the >>>>> location of the files on >>>>> disk does not need to change to match the new Auto-file settings) >>>>> you >>>>> will have to >>>>> temporarily change the auto-file settings (for example by >>>>> prepending a >>>>> 'temp' to all file >>>>> names), select 'Consolidate Linked Files', change the auto-file >>>>> setting back, consolidate again. >>>>> That will ensure that all absolute links actually get converted to >>>>> relative links. >>>>> >>>>> Actually, since the developers are reading here too: It would be >>>>> nice >>>>> to change this behaviour >>>>> and automatically convert all links to relative or absolute >>>>> depending >>>>> on the preference setting. >>>>> >>>>> Hendrik >>>>> >>> >>>> No, that's bad behavior. We should never just automatically change >>>> things like that. >>>> >>>> Christiaan >>>> >>> >>> I think you probably misunderstood. What I meant is the following: >>> If you change your auto-filing preferences from absolute to relative >>> paths and then afterwards >>> select one (or all) paper(s) and choose 'Consolidate Linked Files', >>> then the Local-Url path should IMO >>> be changed from an absolute to a relative one. Even when the >>> location >>> of the file on disk remains >>> the same. Currently the path only gets converted to relative when >>> the >>> location of the file on disk changes. >>> >>> Hendrik >> >> Yes, I understood you correctly. However we check the path for >> autofile, not the value of the Local-Url field. There are many >> reasons for this, and the code is far to complex to easily be more >> intelligent. We could of course change the local-url anyway, but it >> would mean we'd change the local-url anytime even when it is not >> necessary. That is bad, IMHO worse. >> >> Christiaan > > Okay, so it is difficult for the code to be more intelligent because > of how things are implemented internally. But this is different from > 'bad behaviour', no? > My interpretation of 'Consolidate linked files ...' from a users > perspective is the following: > "Make the location of my files and the Local-Url links match the > content of the entries in the database and the settings for Auto-File. > " > This involves moving things around if necessary and changing the > Local-Url if necessary. If I specify I want relative links I would > expect to get relative links. > I also don't quite see how overwriting the local-url with the > identical value when the user selects 'Consolidate linked files ...' > is a bad thing. > It's not like unnecessarily changing a few strings in memory when the > user invokes the 'Consolidate' function would be a big performance > bottleneck. > > Hendrik
The point is that we need to do the best thing we can in many possible situations handling errors. I'm not just talking about overwriting the local url in this particular way, but more generally. The point of Consolidate is more a matter of saving the files in a particular location than to setting the local-url to a particular value. That's already more than complex enough. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
