GNOME Bugzilla – Bug 381332
Visually differentiate photos with versions
Last modified: 2018-07-12 00:04:43 UTC
The attached patch implements a way of visually indicating photos which have some kind of multiple representations. It is used to indicate photos with different versions, but could be used as the base for other 'stacking', such as that mentioned in bug 311550. It also is a more or less direct solution for bug 363634. It's very much a proof of concept patch, so there's still a lot of work wrg usability and presentation issues.
Created attachment 77494 [details] [review] Patch for CVS version You need the PixbufStack.cs file in src/ for this patch to work. That file should be attached to this bug as well.
Created attachment 77495 [details] PixbufStack.cs Implements the stacked thumbnails
will try your patch soon... btw, you can add a new file to a patch like this: cvs diff -upN > mypatch.patch diff -upN /dev/null src/PixbufStack.cs >> mypatch.patch
Created attachment 77511 [details] [review] Patch with extra file included New version of patch, with src/PixbufCache.cs included. Thanks Stephane for the tip on how to do this.
Created attachment 77631 [details] For the screenshots lovers here's a screenshot of the effects of this patch so... yes, it works. some issues and questions - why do you call this a PixbufStack, not a ThumbnailStack or ThumbnailREpresentation or ... ? Also, this class should probably benefit from some inheritance... - when a version use a different cropping ratio than the original, the display looks a bit strange... - I'm not sure what to think about the graphical aspect, the gray border... - I did'nt looked deep yet in the code, so no comment on that
Thanks for the review. Some comments on the comments :) : - I called it a PixbufStack because it might be used for other things than thumbnails, e.g. to stack tag icons. That is also why all of the logic that deals with versions is elsewhere. - What are your ideas wrg to inheritance for this class? Inherit from Gdk.Pixbuf perhaps, so code using PixbufStack can manipulate the resulting image using a familiar interface? - The cropping issue is well spotted. I currently scale the pixbufs according to the top one, but I'll have to do this for W/H ratios as well - The gray border I'm unsure about as well. It's there to differentiate the various images in the stack from each other, but that will probably not be a problem without it. I'll ditch it. Thanks again for the review!
*** Bug 383480 has been marked as a duplicate of this bug. ***
I'm attaching a new version of the patch. Changes are: - PixbufStack is now called ThumbnailStack. My argument above was bogus, as I use the PixbufCache to load the contents of the stack, which works with thumbnails. So ThumbnailStack is indeed a better name. - The border is gone - Versions with different cropping ratio than default version now are shown with the cropping ratio of the default version (this turned out to be remarkably easy - just correct a mistake of mine :) ). This still looks a bit awkward when switching the default version. Nothing has been done wrt to inheritance yet.
Created attachment 78681 [details] [review] Patch version 0.02
Created attachment 78689 [details] [review] Patch version 0.03 Added item in View menu to toggle displaying of version stacks
Any thoughts on this feature request and patch some 18 months on? I would like this feature too. Note though I don't think it is actually necessary to show the actual pictures of the other versions - they are almost completely hidden so all we actually need show is one or two 'shadow' like boxes to give the visual impression of a stack of versions. On my system there is not that much room to play with anyway - just about room for one extra outline. We probably don't need a configuration option - showing that a thumbnail has versions is probably universally good.
Created attachment 117486 [details] [review] New proposed patch - v1 Here is my proposal for a patch to give something of the desired functionality. It is much less invasive compared to the previous suggestions. Currently it just adds a simple box behind (and slightly shifted) the thumbnail, giving a simple impression of a stack. These days there is not much spare space around the thumbnails, so even this extra single box barely fits. However this patch is just to show that some visual indication can be given in just a few lines of code, rather than to make it look really pretty. If people agree this is the way to go, we can then agree on exactly how fancy (or not) to make it look.
Created attachment 117710 [details] Screenshot show how it looks To save people trying the patch, the attached screenshot shows how it would look with my proposed patch. Of course we could tweak how the box looks - but for me the basic idea of a simple box/outline behind the picture is enough to show the picture has multiple versions.
Created attachment 118120 [details] One shadow - square or rounded
Created attachment 118121 [details] Two shadows - square or rounded
Created attachment 118122 [details] One shadow - rounded and filled in
Above are 3 attachments showing mock pictures of how different 'shadows' could possibly look. Which is preferred? Personally I would go with 'Two shadows - square', but I'm concerned that this will take up too much precious space (I think the gap between thumbnails would need to be increased). 'One shadow - square' is next best - I don't see the value in rounded corners (but thats just my opinion).
I think I'd prefer having a rounded corner
Created attachment 118815 [details] Single line with rounded corners This picture shows a set of screenshot fragments, all with f-spot patched to show a simple shadow consisting of a single line with rounded corners. The different fragments show the same thumbnail at different sizes. I coded the shadow to scale its size relative to the thumbnail size. Things to note: 1) I used Gdk.Drawable.DrawArc for the corners. With only a few pixels to play with it of course can't render a perfect arc, but I think thats okay. 2) If we adopt such a shadow, I will adjust the patch to push down the text under the thumbnail so its clear of the shadow line. 3) The box drawn around a selected thumbnail can vary in its size, depending on the thumbnail size. At the moment this sometimes means my shadow is drawn outside the selection box. I would need to make the selection box always big enough to accomodate the shadow for a production-worthy patch. What do you guys think? If you want to go with this, I will try and code the adjustments for 2) & 3). Otherwise feel free to re-direct my efforts.
that's not what I mean by a rounded corner, I was talking about a rounded page corner. I'll try to mock that up s
Created attachment 119468 [details] Mock up with photo corner pulled up Here's a mock - rounding up the photo corner to suggest there are other versions underneath ...
Comment on attachment 117486 [details] [review] New proposed patch - v1 Maintenance update: In the past we've been less than stellar in reviewing patches. As such we have a pile of patches in bugzilla which are outdated and don't apply anymore. Am currently marking all of these as "needs-work". My apologies for this. Since I've become a maintainer of the project, I've set the personal rule of quickly reviewing all patches, to avoid that this happens again. If you (or anyone) wants to go through the trouble of updating this patch, please talk to us to figure out if it fits in the F-Spot long term roadmap. Should you, in the future, notice a patch lingering around for too long, please notify us immediately and we'll look into it, to avoid situations like these from happening again. You can filter these mails by searching for ###F-OLDPATCHCLEANUP###
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.