On Sep 24, 2007, at 07:50, Christiaan Hofman wrote: > I see many problems with the file references. > - Files may not exist (especially when shared between different > computers). > - Files may be deleted/moved to trash/replaced > > So certainly the current BDSKFile objects are not sufficient. Somehow > a non-existing file should remember the aliasdata for saving, and an > existing file should remember a (relative?) path in case it's > removed. I think we need a subclass of BDSKFSRefFile and BDSKURLFile.
I think a broken alias is expected behavior if the file is deleted, and I'm not convinced that accounting for it with a path is necessarily an improvement...I wonder what happens with the FSRef in that case, though? Watching it with the FSEvent stuff in Leopard would be the most useful approach, but again it's a lot of work for an edge case. I definitely agree that if the file isn't present when the file object is instantiated, the alias/path that was used to instantiate it should be preserved. I thought that could be handled with a subclass of BDSKFile that's similar to BDSKURLFile (or replace it). > Also the base path is a problem. For new databases there may not be a > filename. And what is the base path for export/save as? And how is it > passed to the file objects? It would have to be passed by the BibItem when saving, since it's the only object that connects the document and files. > I think when saving the base path should > be the absoluteURL passed to the savetoURL:... method, not the > current fileName. So somehow this needs to be remembered in an ivar > (as writeToURL:... does not know it). That's part of the reason I was thinking of using NSHomeDirectory() for relative paths. There's only one save method that's documented as getting the actual document URL, IIRC; they may point to temporary files, so that's also a definite problem. > Also copying items may be a problem. I think this could be solved by > archiving file objects using an absolute path (as two files do not > agree on the base path). Copying what items? BDSKFile should be copyable... > But what about initially adding items to a new database? I think they > should be represented by an FSRef and an absolute path (so the path > in the new BDSKFile subclass should be absolute, or both relative and > absolute). Why a path as well as FSRef? For the trashing case? > Another problem is dragging in the fileview. Is it possible to handle > this through the datasource (as in NSTableView) rather than in > FileView? Possible, yes...I've thought of doing just that. I was trying to keep the delegate's task as simple as possible, since the FileView is far less generic than NSTableView. There are also some annoying problems with pasteboards that might mess up passing the drag to another object. I'm using Carbon pasteboard manager functions for better Finder compatibility, and NSPasteboard doesn't seem to like that. > The problem is that reordering should reorder the BDSKFile > objects, rather than replacing them with new objects (particularly > important for broken links). FileView only knows about the URL, not > the BDSKFile objects. Also reordering should not trigger autofile, > but currently it is impossible to see the difference between delete > +add and move. Good point; it's implemented as delete+add internally, but a rearrange could just be a separate message passing the indexes to move and their destination. Something like - (BOOL)fileView:(FileView *)aView moveObjectsAtIndexes:(NSIndexSet *)selectedIndexes toIndexes:(NSIndexSet *)newIndexes; and then the delegate could do whatever it wants with its storage, and then reload the view. ------------------------------------------------------------------------- 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
