I just completely changed the BDSKAliasFile stuff, combining local files and remote URLs in the file view. It is URL based (as that is the common denominator for both) and uses a new class cluster. See how you like it.
Could the label be written over more than one line, so the remote URLs have a more informative label? Or otherwise truncate the head rather than the middle. Christiaan On 12 Nov 2007, at 6:33 AM, Adam R. Maxwell wrote: > > On Nov 11, 2007, at 11:08 AM, Christiaan Hofman wrote: > >> >> On 11 Nov 2007, at 7:20 PM, Adam R. Maxwell wrote: >> >>> I actually added that basePathForAliasFile: method just to avoid >>> another temporary URL conversion in the save loop. >>> >>> Which brings up another point. NSDocument converted everything to >>> use >>> NSURL instead of paths in 10.4, but the rest of Cocoa seems to use >>> paths (NSFileManager, the new NSWorkspace stuff for UTIs). I >>> complained to Apple about this and never heard back. >>> >>> Given that, I'm not convinced that we should use NSURL as a path >>> replacement. It would be nice to pick one and stick with it, so we >>> avoid the URL<->path conversions as much as possible. >>> >>> What should we do? The only good thing about URLs is that they're >>> easy to convert to/from FSRefs, as far as I'm concerned. However, >>> you >>> can't use a ~ in a URL, and paths are easier to work with for >>> relative >>> paths. >>> >> >> That's the reason I used a URL for the delegate method. > > Could base64StringRelativeToPath: use an absolute URL as well? I > haven't looked at the file code for a couple of weeks. >> >> >>> Currently we support paths or string URLs in BibItem, and that code >>> drives me crazy (some uses paths, some uses NSURL, some returns URLs >>> as -absoluteString...). >>> >>> My present thinking is that we should >>> >>> - use NSString paths in BibItem >> >> Like where? > > Everywhere we use NSURL* or -[NSURL absoluteString] to refer to a > file... > >> >> >>> - create the file objects with paths >> >> I'm not sure, if we (ever) want to use both local and remote URLs in >> the file view I think it's better to use just URLs. > > The only place I think it can be useful is in the main window view, > since you can do a quick look at the URL or drag/drop it. > >> >> >>> - use NSURL for remote URL >>> - only allow a one-time upgrade of a current file (i.e. ditch the >>> current path and URL handling setup) >>> >>> That last point is likely to be unpopular. I'm not sure if I >>> like it >>> myself, but the more legacy code we support, the harder it will >>> be to >>> make file objects work properly. >>> >> >> Moreover it would be fragile not to do it. Files would be re-added >> all the time, in particular if there are files that could not be >> resolved. > > Fragile to keep the legacy support in there? I concur with that. The > only real loss is human-editability with a text editor, as long as the > alias file preserves the original path when the file isn't resolved. > >>> I originally used paths for FileView, but switched to URLs to allow >>> representing non-file URLs. This isn't a big deal, since >>> returning a >>> URL from a file object is easy, so doesn't need to drive any BD >>> internal changes. >>> >> >> I think it's better to use URLs, as it also can represent remote >> URLs. > > Okay, I don't have a real problem with that. Right now we have a > bunch of methods that are variations on local[File|URL]Path... and I > can imagine some future developer looking at that and wondering what > we were thinking. We also have suggestedLocalUrl which returns an > NSString, so if we can unify all of this stuff, I think we'll be > happier in the long run. > > -- > adam > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bibdesk-develop mailing list > Bibdesk-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
