On 22 Sep 2007, at 11:37 PM, Adam R. Maxwell wrote: > > On Sep 22, 2007, at 14:10, Christiaan Hofman wrote: > >> >> On 22 Sep 2007, at 10:34 PM, Adam R. Maxwell wrote: >> >>> I created a new branch TRY_ARM_FILE_INTERFACE for revised file >>> interface experiments. The FileView.framework is added as a binary >>> for now, since it requires the 10.5 SDK to compile. Related to >>> that, >>> don't edit FVPreviewer.nib in IB 2.x, since it uses some IB 3 stuff >>> (but is binary compatible with 10.4). It's not very exciting to >>> look >>> at, anyway. >>> >>> I decided to make it a framework since there are now 7 classes that >>> are specific to the view, and so I won't have to commit source >>> that's >>> under NDA (NSInteger/NSUInteger/CGFloat have been mentioned on >>> Apple's >>> site). It's pretty usable in my testing, but I need to stop adding >>> features to it (adding buttons to change pages in PDF was fun). >>> >> >> So it should compile on Tiger (checked out but haven't tried it yet)? > > Yeah, in theory...the bundle inside the framework links against a > Leopard-only framework, but the framework itself should link okay on > Tiger. > >>> Lots of model work needs to be done. Feel free to discuss or commit >>> changes; I'll be messing with it casually in my not-so-spare time. >>> >>> My plan is/was to add an array of BDSKFile objects to each BibItem. >>> For that, they need to have an initWithBase64String:relativeTo: >>> and - >>> base64String:relativeTo: method added, for init/save from BibItem; >>> OmniFoundation has methods for this, I think, and we can use BDAlias >>> to convert the FSRef to alias data. In code, I'm thinking we have >>> >>> NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys: >>> [self >>> aliasData], @"aliasData", [self pathRelativeTo:rpath], >>> @"relativePath", nil]; >>> // use NSPropertyListSerialization to create NSData >>> // convert NSData to base64 (ascii) string >>> >>> The relative path details need to be worked out; BibItem will >>> supply a >>> base directory to the BDSKFile at init/archive time. >>> >> >> When should the conversion data -> path/URL be done, any time a path >> is needed, or only once? > > I was thinking we'd convert FSRef->AliasHandle->data on save (not sure > how that'll scale yet), and data->AliasHandle->FSRef just once (when > the file is loaded). > >> 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? >> And the base path is either the document or the papers folder? > > Yes. I don't recall if we came to any concrete conclusion on whether > one or both was more appropriate. > Not conclusively. >>> Backwards compatibility for people who want to use paths only needs >>> to >>> be thought through as well. I have some ideas on that. >>> >>> AutoFile support is TBD; I haven't looked at the code in a long >>> time, >>> so my goals may be out of reach. I'd like to have autofile for an >>> arbitrary number of files, which means a unique specifier will be >>> mandatory. >>> >>> later, >>> Adam >> >> Currently it is not possible to check this, it requires some method >> to check whether a unique specifier is present, the code could be >> similar to +requiredFieldsForFormat:. But I'm not sure when this >> should be checked, in particular for the switch over. Perhaps that >> will be automatic in the check at startup when we can include the >> check in the validateFormat:... method. I think it's doable. > > Yeah, checking at startup was my thought, when the format is > validated. We could also offer a one-time conversion of Local-Url- >> aliases when reading a file. > > Adam > So what happens with URL fields? That won't be supported anymore? 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
