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)? > 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 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). And the base path is either the document or the papers folder? > 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. 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
