On 20 Dec 2007, at 6:52 PM, Adam R. Maxwell wrote: > > On Thursday, December 20, 2007, at 09:35AM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> On 20 Dec 2007, at 6:30 PM, Adam R. Maxwell wrote: >> >>> >>> On Thursday, December 20, 2007, at 08:31AM, "Christiaan Hofman" >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> On 20 Dec 2007, at 4:58 PM, Adam R. Maxwell wrote: >>>> >>>>> >>>>> On Dec 20, 2007, at 5:11 AM, James Harrison wrote: >>>>> >>>>>> Also, Simon raised the minor issue previously of the amount of >>>>>> padding >>>>>> around the PDF previews in the right pane. The padding >>>>>> increases as >>>>>> the preview size increases, which eats up a good bit of screen >>>>>> space >>>>>> at the larger preview sizes. If it's not a good idea to fix the >>>>>> left >>>>>> side padding at a relatively narrow value, a reasonable >>>>>> alternative >>>>>> might be to save the scroll position of the right pane to the >>>>>> library >>>>>> file along with the icon size (which is currently saved). That >>>>>> would >>>>>> allow folks to position their preview display to the size, width >>>>>> and >>>>>> extent of padding desired. >>>>> >>>>> The padding is a value used in layout of the entire grid, so >>>>> having it >>>>> smaller on the edges isn't really an option. If you select an >>>>> icon, >>>>> you'll see that it's actually drawn in a square, and there's very >>>>> little padding on the left (and the title extends into the padded >>>>> area). Some of those layout choices were based on the assumption >>>>> that >>>>> it would be in the bottom preview pane in BD, so you'd see them >>>>> laid >>>>> out horizontally and vertically. >>>>> >>>> >>>> As a remark on James's remarks, the padding is actually smaller >>>> when >>>> the icon size is smaller, though percentually it is bigger (it is >>>> calculated as 32 + iconwidth / 14). >>>> >>>> I guess we could make it a bit smaller. What about 5 * round(2 + >>>> iconwidth / 50) ? >>> >>> I don't think it can really shrink below 32 because the text is >>> drawn in the (vertical) padding. If there were no labels, it could >>> be a lot tighter. >>> >>> -- adam >> >> We could differentiate between vertical and horizontal padding. I >> think the horizontal padding should be a multiple of 5 because of the >> insertion marker calculation. > > A square grid and uniform padding was a fundamental assumption, so > I'm afraid of a rewrite if vertical and horizontal spacing are > different; I'm not even sure where that's assumed in the code at > this point, and it would require a fair amount of testing. > > I think the real problem is that it's stuck in a narrow view, so we > really don't get the benefit (visually or practically) of the > dynamic layout. Subclassing it to create a single column view > might be better. > > adam
I actually just did it, and I don't see the assumption for a square grid anywhere. All calculations I could find were either vertical or horizontal. And it does give a tighter view horizontally now. 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
