On 23 Sep 2007, at 12:41 AM, Adam R. Maxwell wrote: > > On Sep 22, 2007, at 14:51, Christiaan Hofman wrote: > >> >> On 22 Sep 2007, at 11:37 PM, Adam R. Maxwell wrote: >> >>> >>> On Sep 22, 2007, at 14:10, Christiaan Hofman wrote: >>> >>>> I think the resolution of the alias+relative >>>> path should be done only when needed, as the base path could change >>>> during the run. So perhaps instead of BDSKFile objects we could >>>> also >>>> keep a wrappers of alias + relative path (which could be another >>>> BDSKFile subclass). >>> >>> I'm not sure exactly what this would look like? I definitely agree >>> that relative paths should be resolved only when needed (reading the >>> file or saving), but I was thinking we should avoid using aliases >>> for >>> anything but serialization, since resolving them can be slow and >>> take >>> up a fair bit of memory. >>> >> >> What I mean with"when needed" is when the URL is actually requested >> anywhere, not once at load time. Just as we do now (i.e. relative >> paths are resolved at any time, not at load time). >> >> >>> FSRefs are lightweight (80 bytes) and fast, so I think that's >>> what we >>> want to keep in-memory, since they still handle file renaming/ >>> moving. >>> The owner BibItem would then pass the relative path when creating/ >>> saving, so base directory could change after file loading, and the >>> relative path would still be okay. Keeping the alias data might >>> still >>> be necessary for performance reasons, but I've no idea yet. >>> >> >> So this means we won't support changes in the base directory while >> BibDesk is running, and the path is essentially equivalent to a fixed >> absolute path during a run? > > No, that would be a definite step backwards. We wouldn't even have a > path or URL anywhere, so files could be moved/renamed/whatever while > the document was open, and things wouldn't break. If a path or URL is > needed for opening a file or displaying an icon, we'd ask a BDSKFile > for it, and it would be created dynamically. So you could say in > BibItem > > NSString *absolutePath = [[[files objectAtIndex:0] fileURL] path]; > > or maybe for saving > > NSString *relPath = [[files objectAtIndex:0] pathRelativeToDirectory: > [[self document] filePath]]; > > where files is an array of BDSKFile objects (the FSRef subclass). >
OK, forgot that FSRef follows the file. And what about broken links (very important for sharing between different computers). An FSRef cannot be created in that case. Or can that be handled with BDSKFile? >> So what happens with URL fields? That won't be supported anymore? > > Nothing would change for remote URLs. I'm not sure what to do about > the current file support. Removing support for local-file fields > would upset people, I'm sure, and break cross-platform > compatibility...so that's not an option. > But I don't see at the moment how to combine things. > One idea is to have the new UI for both types (FSRef and path), using > file objects internally. When saving, though, the BibItem would > ignore the FSRefs and just save the paths from pubFields, as we do now > (depending on a pref). Or we could just create the relative paths > from the BDSKFile and save those, which is probably what you meant by > creating them when needed? > No, I really meant *any* time the URL is needed (for a UI or whatever). > Other ideas: I'd like to eliminate special-case handling of Local- > Url. The editor toolbar buttons, for instance, rely on Local-Url or > Url exclusively, and those names aren't compatible with JabRef IIRC. > So if cross-platform support is a motivator for keeping paths, we > might be able to improve it so other path types are no longer second- > class citizens. I think the new Quick Look context menu might replace > the editor drawer, for instance. > > adam But then there is not something like a primary linked file? Or would that always be the first one? Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
