“JPEG” tile in beagle..
So, a bit more tweaks (I hope you dont get bored by these :-)) - this is indeed a real screenshot and not just a mockup - you can see it from the scrollbars, I would use gtk ones if it was a mockup since that is the goal definitely..
I added some more information to the jpeg tile. I just need to talk with Dave so I really understand how those tags really work - beagle has some smart logic that it can hide parts of the template if the data is not available etc, so I need to study that a bit more.
Anyway, this starts to look nice for my photo search needs - and once Beagle uses the .thumbnail standard it will make my .NEF (Nikon RAW) photos thumbnails work (I have 20 gigs worth of NEFs on this harddisk) - The fun thing is, NEF is a very very weird incarnation of TIFF format (basically just something that is not very TIFF wrapped inside a TIFF container..) - but the cool thing is, the thumbnail is a valid tiff thumbnail. So Nautilus shows them. This rocks.. So, Nikon is clearly better than Canon for Linux geeks 
November 11th, 2004 at 17:41
Somebody just needs to make Canon raw thumbnailing work… I’m sure somebody will (at least I hope); there are so many people in the office who have a Canon DSLR.
…Maybe I can convince rml to do it. (:
November 11th, 2004 at 19:56
I know youre wont be the one to deal with it, but I have a bit of a concern about the size of those tiles. 5 results per page seems constrictive. What would it take to have more results per page, tighter tile spacing and OSX Bar like zooming for the thumbnails (on either mouse over or click). Just a thought.
November 11th, 2004 at 21:00
This looks really nice.
Will we see the image’s dimensions (x,y) and file size show up there, too? That sort of thing is probably more important than shutter speed to non-photographers.
I don’t know if this is your domain, but the word “More” in “Show More Results” might not be ideal. Although it sounds good there, the opposite is “less” or “fewer”, so the left button should really be “Show Fewer Results”. But “Fewer Results” doesn’t really make sense.
If BEST is going to use paging, perhaps it should be “Next Page” and “Previous Page” or “Next Results” and “Previous Results”. Or, like Google, just “Next” and “Previous”. These have the added benefit of being shorter, so the window could be made thinner by the user (it looks like the buttons would prevent it from shrinking much as it is now).
An alternative to paging just occurred to me as I was writing: if the button remained as “More Results” it could literally put more results on the page: up to 10, then 15, then 20. Each time it would auto-scroll down to the first new one. In that case it wouldn’t need a “Less” button at all. If the user wanted to go back to select a previous hit, they could just scroll up instead of paging/scrolling multiple times. Just an idea.
November 11th, 2004 at 23:04
Can you try to add –enable-default-toolkit=gtk2 to your Mozilla build? This should fix the scrollbars issue. I think you can configure this in jhbuild by using something like:
module_autogenargs[’mozilla’] = autogenargs + ‘–enable-default-toolkit=gtk2′
in your ~/.jhbuildrc
Oh and I really like these screenshots. Nice to see this kind of progress since Guadec (the first time I heard about this).