On May 16, 2011, at 16:25, Adam R. Maxwell wrote: > > On May 16, 2011, at 06:55 , Themis Matsoukas wrote: > >> On May 15, 2011, at 8:33 PM, Adam M. Goldstein wrote: >> >>> On May 15, 2011, at 1:13 PM, Themis Matsoukas wrote: >>> >>>> >>>> Haven't tried nor plan to try papers -- and just looking at the graphics >>>> of this app makes me nauseate. > > That's funny, since most people compare BibDesk and Papers by saying how ugly > the former is :). > >>>> However, the idea that you can flip through papers in cover flow mode >>>> sound interesting. Can this be implemented in bibdesk? >>> >>> >>> It does look interesting and cool, but how is it different than scrolling >>> through the main table with the down arrow, and having the attached paper >>> show up in the side or bottom pane? Unless you can make the attached file >>> display size really large, it's hard to tell what most will say by looking >>> at them in a preview or cover flow view. I have this problem when I look at >>> PDF's using cover flow in the Finder. Having the record show up in one of >>> the preview panes is most informative,especially when there are abstracts. >> >> True, functionally it is the same, but it is more convenient to flip back >> and forth than it is to scroll with the cursor one pub each time. Also, >> you'll have to be sure that the pdf is always the first item in the pane. > > The closest you can get is to select all in the main table and scroll through > the icon view(s). Then you're not using arrow keys and watching the view > content hop around, but you'll see more than just PDFs. IIRC one of Papers' > new features is that they can attach more than just PDF files (you all know > BibDesk has allowed that forever, right??). > >> For this to be practical, the magnification would have be enough to show the >> top half of the title page of a pdf. Usually that's enough to recognize a >> paper. > > At least with the lower pane, this is easy enough to change with the zoom > slider. I realize it's not as smooth and shiny as cover flow, but I've only > used cover flow in Finder or iTunes as a show-off feature to friends. Every > time I've tried to use it to actually browse my files in order to find > something, it's too slow, and feels like a clumsy use of space. > >> I am not saying that I am missing this functionality in bibdesk. However, >> many people fall for these bells and whistles, and that's one that's not >> entirely useless. > > Too true. One unfortunate thing is that Apple never made cover flow > available to developers, so you have to write all the code yourself, and it's > fairly complicated to get right. I never bothered trying, just because I'd > always found it marginally useful at best. > > -- > Adam
Indeed. I never thought cover flow would have real use other than just looking nicely (except perhaps on iOS). That's also why I never wanted to spend much time on it for Skim (it's an open RFE there), because I never saw the real advantage. I once tried to write something as a test based on sample code (also to see how coverflow works), but it soon ran into some problems with PDFKit drawing quirks and incompatibilities, which made it even slower, and worse. So we're always open for others to contribute, but I personally don't see reason to spend time on it. Christiaan ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
