On 25 Sep 2007, at 5:29 AM, Adam R. Maxwell wrote: > > 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 do think that people expect that when you replace a file (by deleting one and adding another one in the same place), for example using a script, keeps the linked file. I think the FSRef becomes invalid in that case (though I'm not sure). If you look at NSDocument (which uses FSRef) you see that when you delete the file, the proxy icon is lost, while if you move the file the proxy icon is changed. > 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). > That's possible. I'm not sure if it should be an alias+relative path or alias+URL(absolute path). >> 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. > But how does BibItem know the filename? >> 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. > I don't think we should interpret relative paths as HOME. If we would do that we should use ~ instead. I do think relative paths to the document are useful. We can use an ivar that stores the URL to save to during save operations, while normally it would just return fileURL. >> 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... > I mean between documents (copy/paste, drag/drop). The document folder is different for the two documents. But I think it would go OK, because copying actually uses NSCoding, and BDSKFile encodes the (absolute) URL. >> 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? Yes. Otherwise deleting the file will give a BDSKFile object with absolutely no information. >> 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. > Also a possibility. 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
