On 27.08.2007, at 19:20, Adam R. Maxwell wrote: > Many people seem to be unaware of BibDesk's file management > capabilities, which bothers me. I also think the user interface > can be improved, so I've been casually working on a revised file > interface (shown in attached screenshot, poor quality due to the 40 > K message limit). The goals: > > 1) Avoid presenting paths to the user > 2) Clear drag-and-drop interface > 3) Allow an arbitrary number and type of files (we generate the > field names) > 4) Store links as aliases /and/ relative paths (base64 encoded in > BibTeX) > 5) Autofile multiple files > 6) Allow a viewing any (supported) file in a dedicated window > > The attached screenshot shows an editor window. The toolbar isn't > gone, but it's hidden, and the author table is no longer in the > toolbar. Current functionality: drag (multiple) files to the file > view, drag (single) files from the file view to Finder. > > Note: I think current Local-Url functionality would remain for > backwards compatibility. Various users would likely want to avoid > what I'm proposing. So no whining (yet). > > The main window also would have a thumbnail view like this, but you > wouldn't be able to drop files on it. The file view is similar to > iPhoto's view, in that it automatically creates a grid based on a > desired thumbnail size. Any image file (incl. PDF/PS), QuickTime, > and TextEdit-supported file can be displayed. Personally, I don't > think this is terribly useful, but many users want linked files > displayed in the main window; we presently do this only for Local- > Url, but my suggestion here is a compromise, with 6) above. We'd > likely use Quick Look for 6) on Leopard, which would give us even > more viewable file types. > > Any suggestions from the user community? Should remote URLs be > displayed in this view as well (as icons...previewing would be > heinous)? It would also be cool if you could open up an > @proceedings and see all of its child items' files immediately...
Hi everybody, generally speaking, I find this a very, very useful direction for BibTeX to take. It would bring BibDesk one step closer to being a central manager for scientific information, which I would like to see very much. In fact, I would have a number of ideas for what my "dream app" for this purpose should be able to do, but this would definitely be beyond the scope of the proposed changes, and probably also the BibDesk project in general ... As for the concrete implementation ... I guess I would have to actually see and use it to be able to make suggestions. Concerning the "path" discussion, I must admit that I do not really understand what it is about (in detail). Regards Holger ------------------------------------------------------------------------- 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
