After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 326561 - Rating Photos and Filter on Rating
Rating Photos and Filter on Rating
Status: RESOLVED FIXED
Product: f-spot
Classification: Other
Component: Browsing
CVS
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
: 324421 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-11 06:26 UTC by Bengt Thuree
Modified: 2008-01-15 16:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Rating patch (39.09 KB, patch)
2006-09-28 19:22 UTC, Stephane Delcroix
none Details | Review
new icons (10.00 KB, application/x-compressed-tar)
2006-09-28 19:24 UTC, Stephane Delcroix
  Details
updated patch (44.91 KB, patch)
2006-09-28 20:05 UTC, Stephane Delcroix
none Details | Review
new icons, again (10.00 KB, application/x-compressed-tar)
2006-09-29 09:14 UTC, Stephane Delcroix
  Details
updated version (44.52 KB, patch)
2006-09-29 09:18 UTC, Stephane Delcroix
none Details | Review
icons, one more time (10.00 KB, application/x-compressed-tar)
2006-09-29 13:11 UTC, Stephane Delcroix
  Details
with a reworked widget (45.86 KB, patch)
2006-09-29 13:17 UTC, Stephane Delcroix
none Details | Review
with rating in all modes (49.92 KB, patch)
2006-10-02 11:09 UTC, Stephane Delcroix
none Details | Review
Same patch, but now you can view photos sorted by rating (52.46 KB, patch)
2006-10-03 20:16 UTC, Thomas Van Machelen
needs-work Details | Review
updated version (49.99 KB, patch)
2006-10-05 12:43 UTC, Stephane Delcroix
none Details | Review
Rating Patch - Updated version (56.34 KB, patch)
2006-10-06 05:50 UTC, Bengt Thuree
needs-work Details | Review
Rating Patch - Updated version (68.65 KB, patch)
2006-10-06 12:57 UTC, Bengt Thuree
none Details | Review
New version that supports sorting and filtering (74.28 KB, patch)
2006-10-11 19:02 UTC, Thomas Van Machelen
none Details | Review
latest patch from bengt (68.95 KB, patch)
2006-10-18 13:01 UTC, Stephane Delcroix
none Details | Review
Rating path (68.28 KB, patch)
2006-10-21 09:43 UTC, Bengt Thuree
none Details | Review
Updated to svn as of 2007-02-13 (75.07 KB, patch)
2007-02-14 02:02 UTC, Bradford Powell
none Details | Review
rating-2008.patch (62.42 KB, patch)
2008-01-06 20:50 UTC, Maxxer
none Details | Review

Description Bengt Thuree 2006-01-11 06:26:39 UTC
Would be nice if F-Spot would have a Rating with stars/digits or something.
For instance
- Un-rated, 
- 0 (throw), 
- 1 (need touchup), 
- 2 (ok), 
- 3 (good), 
- 4 (very good), 
- 5 (excellent)

And on the main browser/edit screen we have a slider to select photos with at
least a rating of the sliders value, on top of the tags.

Example
Select tags Beach, Person 1, Australia --> 200 pictures
Use the Rating slider to filter out only those with a rating of 2 and above --> 100
Rating 4 and above --> 10

Of course, you should also be able to select ONLY those with a specific rating.
Like "Touch Up needed", or "To be Deleted" etc.
Comment 1 Jonas Bergler 2006-01-11 10:14:33 UTC
If something like this were to be introduced I would say it just needs to be a special type of tag that with the advanced tag filtering suggested in #139796 would make a nice way of doing this.

but i agree rating functionality of some sort would be nice.
Comment 2 Bengt Thuree 2006-01-11 12:20:52 UTC
The Ranking could be stored as a 1 digit field in the IPTC tag URGENCY, or/and in XMP.

A lot of other software is using the Urgency tag as a ranking (1-5)

I do think that we should keep the Ranking filter separate from the tag filter. At lest visually. The Ranking filter belongs more with the Date Range, than the Tag specification I belive.
Comment 3 Jonas Bergler 2006-01-11 12:34:13 UTC
yes, visually keeping rating separate is a must, and i have seen the urgency tag being used before, so maybe thats the place to put it,

I would like to see an itunes like rating system, so that the tags go below images on one row, and on another directly below it goes 5 grayed stars to 5 highlighted starts depending on the rating, and simply by clicking on the 3rd star one could change the rating to three.
Comment 4 Fabian Kneissl 2006-01-15 23:45:26 UTC
*** Bug 324421 has been marked as a duplicate of this bug. ***
Comment 5 wjbaird 2006-04-03 02:41:10 UTC
Here are a series of use cases describing how I think this would be used:

1.  Setting rankings from the Photo View

   - User selects one or more photos in the main photo view
   - User presses Control and one of the '0'-> '5' keys
   - The appropriate ranking is assigned to the photos, and the appropriate number of stars appears below the photo


2.  Setting rankings from slide-show or full-screen view

   - User is looking at a photo in full-screen mode (either in a slide-show or in full-screen mode)
   - User presses Control and one of the '0'-> '5' keys
   - The appropriate ranking is assigned to the photos, and the appropriate number of stars appears briefly in a semi-transparent form at the bottom of the photo

3. Searching based on rankings

   - User opens up the search dialogue 
   - One of the options is to constrain the search by the ranking of photos - matching based on equality, less then, greater than, etc. 

4. Filtering based on rankings

   - User can select from a menu a constraint similar to what was described for searching
   - all photos currently displayed that do not match the constraint disappear.  This is cumulative with the "Find by tag" functionality, so it's easy to quickly see all photos that match a certain tag and have a certain ranking.

5. Quick filtering

  - User can use a drop-down or slider on the main panel to select the minimum rating shown.
  - all photos with a rating below the specified rating are removed from the view.

Questions:

 - should we provide a mechanism to protect against a user accidently wiping out all of their existing rankings by pressing a Ranking key while all photos are selected?   Maybe a popup if more than N photos are selected?
Comment 6 Bengt Thuree 2006-04-03 03:44:14 UTC
Good use cases :)
And Yes, would be nice if there is a warning popping up if you try to modify to many pictures in one go. Just in case.

I think the Quick Filtering would replace both the Searching as well as Filtering based on rankings in the above use cases.
Similar to what I described in the original note to this bug.
Comment 7 Fabian Kneissl 2006-07-28 21:03:22 UTC
Just wanted to note, that something's going on:
Gabriel Burt has written a rating plugin for Banshee and Cosme Sevestre has tested it:
http://mail.gnome.org/archives/f-spot-list/2006-July/msg00103.html


Cosme Sevestre wrote in http://mail.gnome.org/archives/f-spot-list/2006-July/msg00105.html
> Well there are still a few things that need to be addressed :-)
> 
> 1. Saving/retrieving rating in/from XMP
> 2. Storing the rating within F-Spot (changes in the DB?)
> 3. UI stuff
> 4. Filtering
> 
> 1. The XMP patch will definitely help for that one.  The where
> (Urgency or Rating tag?) and how (unrated + refused (0) + 1-5?) are
> still undecided yet.
> 
> 2. Todo I guess :-) but that's an important one.
> 
> 3. At least we have a cool widget in C# thanks to Gabriel.  It handles
> click, slide, mouse scroll, keyboard shortcuts - very, very cool.
> 
> 4. -
> 
> Once 1 and 2 are done, 3 is probably the biggest task.  Well 4 too but
> I will let other people focus on that one :-).
Comment 8 Bengt Thuree 2006-09-28 04:33:59 UTC
This bug is now Goal #6

http://mail.gnome.org/archives/f-spot-list/2006-September/msg00231.html
Comment 9 Jean-Christophe Dubacq 2006-09-28 17:01:02 UTC
Just wanted to say that shortcuts using numbers have to work with French keyboards (where numbers are Shift+& for 1, Shift+é for 2, etc.). Or numpad. See http://en.wikipedia.org/wiki/Image:Computer_keyboard_layout_AZERTY_French.jpg
Comment 10 Stephane Delcroix 2006-09-28 19:22:02 UTC
Created attachment 73579 [details] [review]
Rating patch

Here's the patch from Bengt, Cosme and I to implement Rating on F-Spot. The Filter on rating is not implemented yet.
Don't forget to add the new icons (check the next attachment) in the icons folder.

Please review, test and comment.

usual warning:
THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA. DON'T USE IT ON YOUR REAL LIBRARY. USE THE --basedir INSTEAD.
Comment 11 Stephane Delcroix 2006-09-28 19:24:39 UTC
Created attachment 73581 [details]
new icons

some new icons
Comment 12 Stephane Delcroix 2006-09-28 19:34:53 UTC
err, some minor bug in this version: test it with 'Display Dates' disabled
Comment 13 Stephane Delcroix 2006-09-28 20:05:43 UTC
Created attachment 73589 [details] [review]
updated patch

this one fix the issue in comment #12 and add a menu item to toggle the display of ratings

Don't forget to add the new icons (check comment #11) in the icons
folder.

Please review, test and comment.

usual warning:
THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA. DON'T USE IT ON YOUR REAL LIBRARY.
USE THE --basedir INSTEAD.
Comment 14 Fabian Kneissl 2006-09-29 01:48:08 UTC
I have another suggestion for how the rating could be shown. As a star with the number in it. Like here:
http://img142.imageshack.us/my.php?image=ratingothermethodfq6.jpg

Do keyboard shortcuts already work?
Comment 15 Bengt Thuree 2006-09-29 01:58:23 UTC
keyboard shortcuts do not work yet.

I prefere to see the number of stars, much easier and quicker to check the rating.

But, there could be an option 
* Short display (star with a number)
* Long display (one star per rating - default)

Not to sure of how often you want to display the stars though, since you would use the filter/slidebar that is scheduled to come soon, to filter the images with rating over a value, or between values (can then find all unrated photos for instance). This of course is on top of the other filters (date, tags, and upcoming last rolls)
Comment 16 Stephane Delcroix 2006-09-29 09:14:09 UTC
Created attachment 73617 [details]
new icons, again

Cosme sent me his bolder version of junk-bold
Comment 17 Stephane Delcroix 2006-09-29 09:18:45 UTC
Created attachment 73619 [details] [review]
updated version

This include the latest changes from Bengt and apply to latest CVS.

<warnings on>
Don't forget to add the new icons (check comment #16) in the icons folder.

THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA. DON'T USE IT ON YOUR REAL LIBRARY.
USE THE --basedir INSTEAD.
<warnings off>
Comment 18 Stephane Delcroix 2006-09-29 13:11:07 UTC
Created attachment 73631 [details]
icons, one more time

add an icon for the new widget, see below
Comment 19 Stephane Delcroix 2006-09-29 13:17:23 UTC
Created attachment 73633 [details] [review]
with a reworked widget

Introduce a new widget, with the ability to unrate image without scrolling.

Also no longer try to display rating on --view mode

To respond to some questions...
* Je pense connaître le problème des claviers azerty
* rating with only one star and a number (aside with the tags) could be an option, but my top priority is having everyting working first.

<warnings on>
Don't forget to add the new icons (check comment #18) in the icons folder.

THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA. DON'T USE IT ON YOUR REAL LIBRARY.
USE THE --basedir INSTEAD.
<warnings off>
Comment 20 Bradford Powell 2006-10-01 20:03:59 UTC
It would also be nice to be able to set/see the ratings in full-screen view. This would allow the user to easily go through a set of photos and rate them while seeing the highest-possible resolution on his/her monitor. Preferably, for speed purposes, the rating could be set using only the keyboard.

One use-case for this would be going through recently-imported photos, looking at them at full screen and rating as "junk" those which will be deleted.
Comment 21 Bengt Thuree 2006-10-02 01:06:47 UTC
Latest patch (not released yet) has an addition to the popup menu where you can set a rating. This one works in browse, edit and full screen mode. Works the same as for Tagging.

A keyboard shortcut is beeing planned as well.
Comment 22 Stephane Delcroix 2006-10-02 11:09:49 UTC
Created attachment 73840 [details] [review]
with rating in all modes

This new version supports now the rating in all modes (icons, photoview, fullscreen) using the popup menu (right click).
This additional feature was added by Bengt.

<warnings on>
Don't forget to add the new icons (check comment #18) in the icons folder.

THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA AND YOUR PICTURE. DON'T USE IT ON YOUR REAL LIBRARY. USE THE --basedir AND THE --photodir SWITCHS INSTEAD.
<warnings off>
Comment 23 Thomas Van Machelen 2006-10-03 20:16:19 UTC
Created attachment 73969 [details] [review]
Same patch, but now you can view photos sorted by rating

This patch adds the ability to sort your photos by rating.  From the Timeline widget you can now right click and select "arrange by rating".  Same goes for the view -> arrange by -> rating.

If people like it, maybe it's a good option to allow limiting the range through the widget also.
Comment 24 Stephane Delcroix 2006-10-04 08:28:11 UTC
bad luck thomas,

I wanted to try your patch but it's incomplet, the RatingAdaptor.cs is missing...
Comment 25 Stephane Delcroix 2006-10-05 12:43:26 UTC
Created attachment 74050 [details] [review]
updated version

Updated version...

<warnings on>
Don't forget to add the new icons (check comment #18) in the icons folder.

THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA AND YOUR PICTURE. DON'T USE IT ON
YOUR REAL LIBRARY. USE THE --basedir AND THE --photodir SWITCHS INSTEAD.
<warnings off>
Comment 26 Bengt Thuree 2006-10-06 05:50:23 UTC
Created attachment 74113 [details] [review]
Rating Patch - Updated version

An updated version that applies cleanly against cvs with Query.

This version, also includes a rudimentory GUI for filtering based on rating.
It is based on the DateRange filter, so it should be enough for first committ, but should be changed sometime to a nice slider.

Please review, and comment. We have next meeting on Monday....

<warnings on>
Don't forget to add the new icons (check comment #18) in the icons folder.

THIS PATCH WILL UPDATE YOUR DATABASE SCHEMA AND YOUR PICTURE. DON'T USE IT ON
YOUR REAL LIBRARY. USE THE --basedir AND THE --photodir SWITCHS INSTEAD.
<warnings off>
Comment 27 Stephane Delcroix 2006-10-06 12:01:36 UTC
RatingFilter.cs missing in the latest patch
Comment 28 Bengt Thuree 2006-10-06 12:57:39 UTC
Created attachment 74131 [details] [review]
Rating Patch - Updated version

Ok, same as before, but with some missing files :(
Comment 29 Dotan Cohen 2006-10-07 09:03:49 UTC
Applied patch from post 28 and the icons. The patch applied cleanly, and the feature works perfectly. I could not get it to crash. My only complaint is that there seems to be no way of hiding the stars in the Browse View. If I'm not adding a Rating, then I'd prefer to not even see it. I'd use it only to sort photos.

Good work.
Comment 30 Bengt Thuree 2006-10-07 14:24:31 UTC
Dotan: 
Check Menu -> View -> Display Ratings
Comment 31 Dotan Cohen 2006-10-07 15:00:32 UTC
I'm embarrased. I should familiarize myself more with the standard F-Spot program, in order to more carefully evalutate something new. Sorry.
Comment 32 Fabian Kneissl 2006-10-07 22:07:44 UTC
Wow. Nice work! I just tested it and it works flawlessly.
The only thing that I would need now are keyboard shortcuts.

The following keys would make sense:
1. Ctrl+0, Ctrl+1, ... Ctrl+5
2. "r0" (first press the "r", then the "0".."5"), similar to tagging, but without pressing "Return" afterwards
3. 0, 1, ... 5 (perhaps not so good)

Other opinions?
Comment 33 Kevin Sheehan 2006-10-09 21:05:11 UTC
Very Nice patch. I have just applied against CVS with no problems, compiled and installed fine (Ubuntu 64 bit). 

Worked fine with no crashes so far. Only issue is the rating seems to apply to all versions of an image. Just if I import an image it might only be a 3 but once I have fixed the levels etc it could become a 4 and it would be nice to ensure the original does not accidentaly get used at the higher rating.

I agree a keyboard shortcut would be usefull, either Ctrl or r are fine in normal use but perhaps a ratings mode which once activated just used the numeric keypad for when you have a group to do?

Thanks
 Kevin
Comment 34 Thomas Van Machelen 2006-10-11 19:02:58 UTC
Created attachment 74507 [details] [review]
New version that supports sorting and filtering

This new patch allows you to sort your photos by rating (right-click the timeline and select "arrange by rating") and also it allows you to filter on rating by dragging the limits of the rating line.  The limits are also in sync with the Rating Range you can set with the filter widget.

ChangeLog:
* src/Makefile.am: add RatingAdaptor.cs
* src/GroupSelector.cs: add new dropdown item and add method to set rating limits
* src/MainWindow.cs: added rating radio button
* src/RatingAdaptor.cs: added to support sorting by rating.

There is still space for improvement, that's for the coming week ;-)
Comment 35 Bengt Thuree 2006-10-17 10:10:25 UTC
Comment #33 Kevin, I am not sure I am supporting the idea of a rating field per every version. I understand why you are asking for it, if a photo looks great in b&w, but only so-so in color for instance.

But, if you have 5 people (5 tags) in a photo, and then you crop it down to 2 people. Should you only have two tags on this version, but 5 tags on the other versions then?

Right now, F-Spot stores tags per photo, and not per versions unfortunately.
So, I think rating should follow the same path as tags.

Comment #34 Thomas, I would definitely prefere to be able to see the date line at the same time as I see the rating slider. So I think we need a new slider for rating.
Sorting based on rating is also a nice feature. Not sure how it should be activated though. From the meny system is ok to start with, but probably need an indication (and toggle) in the gui.

Comments?
Comment 36 wjbaird 2006-10-17 13:48:10 UTC
I tried applying patch 74507 this morning, and it didn't apply cleanly - I had to tweak the glade file and PhotoStore.cs - I'm pretty sure I had a clean copy of head...

I was able to manually patch those two files and get it working.   I haven't had much time to play with it yet, but it looks like a very good start.  My one comment so far is that if we're going to show the 'dots' for inactive stars on the thumbnail overlay, they need to be active ---  I should be able to click on one of the dots to increase the rating or click on a star to decrease the rating.    If we aren't going to make it active, then we should just show the stars, not the dots...

I take it short-cuts for doing ratings in full screen mode aren't there yet?  Is anyone else working on that?  If not, I could take a look at it, I've mucked aroudnd in the full screen code a bit...
Comment 37 Stephane Delcroix 2006-10-18 13:01:45 UTC
Created attachment 74946 [details] [review]
latest patch from bengt

should apply cleanly.

don't forget to backup your db first and include the icons
Comment 38 Kevin Sheehan 2006-10-18 21:23:45 UTC
I have just tried the new patch against CVS and have had a problem, doing make all fails with an error. I think this is the relevant part but if you need anything else let me know.

./MainWindow.cs(1511,22): error CS0234: The type or namespace name `ImageDisplay' does not exist in the namespace `FSpot.Widgets'. Are you missing an assembly reference?
Compilation failed: 1 error(s), 3 warnings
make[2]: *** [f-spot.exe] Error 1
make[2]: Leaving directory `/home/kevin/development/f-spot/cvs/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kevin/development/f-spot/cvs'
make: *** [all] Error 2
kevin@harmony:~/development/f-spot/cvs$
Comment 39 Bengt Thuree 2006-10-19 00:23:13 UTC
Kevin, try again, the make problem has been fixed in CVS.
Comment 40 Kevin Sheehan 2006-10-19 21:01:22 UTC
Hi Bengt,

I am afraid it is not so good with this one either. The make goes OK now but the install fails.I believe the lines below cover the error(Is it the // in /home/kevin/unstable/f-spot//lib/f-spot ?)

make[3]: Nothing to be done for `install-exec-am'.
test -z "/home/kevin/unstable/f-spot/lib/f-spot" || mkdir -p -- "/home/kevin/unstable/f-spot/lib/f-spot"
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'libfspot.la' '/home/kevin/unstable/f-spot/lib/f-spot/libfspot.la'
libtool: install: error: cannot install `libfspot.la' to a directory not ending in /home/kevin/unstable/f-spot//lib/f-spot
make[3]: *** [install-fspotlibLTLIBRARIES] Error 1
make[3]: Leaving directory `/home/kevin/development/f-spot/cvs/libfspot'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/kevin/development/f-spot/cvs/libfspot'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/kevin/development/f-spot/cvs/libfspot'
make: *** [install-recursive] Error 1
kevin@harmony:~/development/f-spot/cvs$

Comment 41 Kevin Sheehan 2006-10-19 21:15:22 UTC
Sorry my fault I had a trailing / on the autogen command, sorry. It now seems to be installing and running fine.
Comment 42 Fabian Kneissl 2006-10-21 00:16:32 UTC
I just tested Bengt's latest patch. Patch works with several offsets and one error (but this one is no real error, one line is changed in CVS like it is in the patch).

I encountered no problems, rating and rating filter work fine for me.

Two things:
1. When I rate a picture in one-photo-view or in fullscreen, the image redraws. Can/Should we avoid that somehow?
2. In fullscreen mode you don't know what the rating of the image is. Is it possible to mark the active rating in the context-menu (set rating) somehow? That would be a nice feature.

Last but not least: Keyboard shortcuts would be nice ;)
Comment 43 John Stowers 2006-10-21 08:12:57 UTC
While I really like this patch from a UI perspective, would it not be better to store the ratings as (special...) tags?

We already have a fantastic tag system in F-spot and special casing the ratings in a different DB format seems silly to me. Any advancements made to the tag system from the perspective of searching or organising are lost if the ratings stuff is maintained too seperately.

A while ago I raised a conversation on the mailing list about how albums might be implemented. While no consensus was reached regarding the UI side of things, storing them as tags (under a top level Albums tag) seemed like a good idea.

I would advocate doing that in this case also. Store the ratings as child under a  top top level Ratings category.

Tags within the ratings category would then be hidden from display in most UI views, however the power of searching and querying and filtering them would be ratained, using the same code paths as other tag based searches.

What do you think?

p.s. I did find a few minor redraw and flickr issues when using the patch, but nothing that hasnt already been mentioned on this page

Comment 44 Bengt Thuree 2006-10-21 09:43:33 UTC
Created attachment 75124 [details] [review]
Rating path

Updated the the patch (without the gui filter part) to apply cleanly against cvs.

don't forget to backup your db first and include the icons
Comment 45 Bengt Thuree 2006-10-21 11:30:32 UTC
For comment #43 there is a perfect tag/field in XMP called Rating which we are supposed to use. If we use tags, then quite suddenly the same photo can have rating : Unrated, 3 Stars and 5 stars. Just by adding a few Rating tags to the photo. In this case we would need a special code to handle the tag GUI.

Currently F-Spot has two criteria when it builds it search query.
1) Date Range
2) Tags

With this rating, it will be expanded with a Rating Range, and in the future (if the patch is not changed drastically) expanded again with Roll Range as well.

Perhaps this could be refactored and simplified a bit. But I do think we need to keep them separate, one reason beeing that rating / range / rolls are not a tag.

I am seeing a small veritical slide to the right of the daterange which indicates Rating filter. Movable top and bottom, to narrow/expand the rating range. (Of course the location can be somewhere else on the gui)
Comment 46 John Stowers 2006-10-21 11:58:07 UTC
(In reply to comment #45)
> For comment #43 there is a perfect tag/field in XMP called Rating which we are
> supposed to use. If we use tags, then quite suddenly the same photo can have
> rating : Unrated, 3 Stars and 5 stars. Just by adding a few Rating tags to the
> photo. In this case we would need a special code to handle the tag GUI.

Fair enough, but doesnt this argument still apply when the ratings are stored in the DB (as in this patch) - there is equal possibility for descrepancy with the information in the XMP field in either case?

> Perhaps this could be refactored and simplified a bit. But I do think we need
> to keep them separate, one reason beeing that rating / range / rolls are not a
> tag.

Well that depends on what you classify as a tag. If I have been previously adding a "good" tag to good photos is this not the same as the rating? - by induction are ratings then just tags?

I agree with the roll range patch as that sort of (chronologica) grouping is furthur from what tags are for, however I fail to see a great distinction between tags and ratings...

If you think this discussion should take place on the mailing list then let me know..
Comment 47 Bengt Thuree 2006-10-21 12:32:14 UTC
Rating in XMP are stored as a integer. A value between null, 0, 1, 2, 3, 4, and 5 in this case. So it can only have one value per photo.

Before we did not have any rating features in F-Spot, so tags would solve the problem nicely. And yes, creating a few tags would fairly easily give the same experience as a Rating field.

Rating filter would be for instance >= 3 stars, or >= 0 AND <= 2 (to find and delete/touch up photos) or whatever. That do not really work with tags which is more of has or has not. I know, since rating is only 0 - 5, you could do it with tags.

But much easier to avoid complicating the tag handling (moving a rating tag around for instance) to implement it separately. Tags has to be unique also, and f-spot do not want to come up with special tags preferably.

(Location, Country, Copyright etc needs to be solved, since they should also be stored as separate XMP fields (not tags).)
Comment 48 John Stowers 2006-10-21 21:23:32 UTC
> But much easier to avoid complicating the tag handling (moving a rating tag
> around for instance) to implement it separately. Tags has to be unique also,
> and f-spot do not want to come up with special tags preferably.

In some ways the "hidden" tag is already a special case, so there is precidence there.

It will not complicate Tag handling from the applying a tag perspective because I think the UI that has been designed in this patch is perfect. The ratings tags will not appear in the tag sidebar, they will only be applied through the new ratings widget so we dont need to worry about a photo being rated twice, because it is not possible for the user to do so.

The special casing will only be in the display. Just add a "invisible" field to the Ratings tags and do not show it in other tag views. Or something.

But we will get all the tag searching stuff for free. Sure you will not be able to say >= 0 and <= 2 but isnt it more intuative for a new user to think of it as "phots which need work"?
 
> (Location, Country, Copyright etc needs to be solved, since they should also be
> stored as separate XMP fields (not tags).)

I hope you are not suggesting that because a field is present in the XMP field list it cannot be stored as a tag. This is backwards. Are you suggesting special casing the search code instead of special casing the tag handling?

There is nothing that prevents writing the Ratings (and location for example) tags back to the XMP data (if supported) when changed. The code path will be very similar to what is in the patch.

Comment 49 Bengt Thuree 2006-10-21 23:42:57 UTC
Just to ensure we are on the same track:
If we store a Rating (as well as Country, State, City, Location, and Copyright to mention a few) as a tag, we will break the standard, and no other applications (which do follow the standard) will be able to interpret a photo with F-Spot embedded meta data by default.

Why I state this, is that tags (including the hidden tag) are stored as a Subject bag, which is according to standard. Yes, all the above can be considered a tag, but then you break the standard. Location (Location field) Paris is not the same a Paris the Person (subject bag, or perhaps a People bag)  for instance

So, this special meaning "tags" and some others will have to be stored at the appropriate place in the XMP tree, and not as a general Subject Tag (where F-Spot should (and does) store tags).

Code wise, we could choose to do whatever, either have everything in the Tag tree, and separate them when we store it. Perhaps the Places related tags will be handled that way. Right now, there is no information in the tag handling for a special (and software predictable) tag name. User can rename the tags to whatever he wants, and then we will be unable to store the tag in the correct place.

This subject has come up a bit before with special tags, and it was decided (at that time anyway) to not have any special meaning tags which would (somewhat) restrict the user when he creates a new tag.

As for filtering goes, I can definitely see the following use cases:
1) Search for all photos between date 1 and Date 2, with Person P and a Rating of 5 stars.
2) Search for all photos between date 1 and Date 2, with Person P and a Rating of above 4 stars.
3) Search for all photos between date 1 and Date 2, and a Rating between 0 to 2 stars (delete candidates perhaps)
4) Search for all photos between date 1 and Date 2, which have not been rated yet.

Of the above use cases, 2 and 3 would not be possible with current Tag searching. Possible that the rating slider could returning a set of Rating tags that should be included in the query. Then the display query needs to be modified also, to not display the rating part etc. To me it sounds also complicated, or?

Currently I think it all boils down to we do not have any special tags that have a hidden purpose (which CAN NOT be changed/modified by user).

For the moment, I see Places as a tag (but should be stored at the correct place in XMP), but rating and date comes with a slider filter.

The Query logic currently has three-four components which it build the query from.
1) The tags
2) The rating range
3) Untagged photos
4) Extended query (related to tags)

Rating (and roll id) would add one or two components to this, in the current design.

Larry is also working on a new version of the gui, so perhaps he has some extra thoughts on how to do the visual thing.

Comments anyone ?
Comment 50 John Stowers 2006-10-22 00:38:12 UTC
(In reply to comment #49)
> Just to ensure we are on the same track:
> If we store a Rating (as well as Country, State, City, Location, and Copyright
> to mention a few) as a tag, we will break the standard, and no other
> applications (which do follow the standard) will be able to interpret a photo
> with F-Spot embedded meta data by default.

As I suggested before and you elude to in your reply, I would special case those categories of tags which also have direct equivilents in XMP and handle them seperately, i.e. write them back to the file.

> 
> Why I state this, is that tags (including the hidden tag) are stored as a
> Subject bag, which is according to standard. Yes, all the above can be
> considered a tag, but then you break the standard. Location (Location field)
> Paris is not the same a Paris the Person (subject bag, or perhaps a People bag)
>  for instance
> 
> So, this special meaning "tags" and some others will have to be stored at the
> appropriate place in the XMP tree, and not as a general Subject Tag (where
> F-Spot should (and does) store tags).

As above, I think it is reasonable to special case Tags under certain categories and write these to the appropriate place in the XMP fields (i.e. not the subject bag)

> 
> Code wise, we could choose to do whatever, either have everything in the Tag
> tree, and separate them when we store it. Perhaps the Places related tags will
> be handled that way. Right now, there is no information in the tag handling for
> a special (and software predictable) tag name. User can rename the tags to
> whatever he wants, and then we will be unable to store the tag in the correct
> place.

True. As an implementation detail, if we store a "invisile=true" field in certain tags/categories it would not be too difficult to also store a "editable=false" field for these special (XMP equivilent) tags.

> 
> This subject has come up a bit before with special tags, and it was decided (at
> that time anyway) to not have any special meaning tags which would (somewhat)
> restrict the user when he creates a new tag.
> 
> As for filtering goes, I can definitely see the following use cases:
> 1) Search for all photos between date 1 and Date 2, with Person P and a Rating
> of 5 stars.
> 2) Search for all photos between date 1 and Date 2, with Person P and a Rating
> of above 4 stars.
> 3) Search for all photos between date 1 and Date 2, and a Rating between 0 to 2
> stars (delete candidates perhaps)
> 4) Search for all photos between date 1 and Date 2, which have not been rated
> yet.
> 
> Of the above use cases, 2 and 3 would not be possible with current Tag
> searching. Possible that the rating slider could returning a set of Rating tags
> that should be included in the query. 

That is what I am suggesting should be done.

Then the display query needs to be
> modified also, to not display the rating part etc. 

That is what I am suggesting.

> To me it sounds also complicated, or?
> 
> Currently I think it all boils down to we do not have any special tags that
> have a hidden purpose (which CAN NOT be changed/modified by user).
> 
> For the moment, I see Places as a tag (but should be stored at the correct
> place in XMP), but rating and date comes with a slider filter.

I think that if its OK to (potentally in future) special case the places tag and write this back to a XMP field it makes sense to do so with the Ratings tag.

> 
> The Query logic currently has three-four components which it build the query
> from.
> 1) The tags
> 2) The rating range
> 3) Untagged photos
> 4) Extended query (related to tags)
> 
> Rating (and roll id) would add one or two components to this, in the current
> design.
> 
> Larry is also working on a new version of the gui, so perhaps he has some extra
> thoughts on how to do the visual thing.
> 
> Comments anyone ?
> 

Disagreements aside, I am glad we are on the same page now!
Comment 51 Jean-Christophe Dubacq 2006-10-22 10:17:37 UTC
(In reply to comment #45)

> Currently F-Spot has two criteria when it builds it search query.
> 1) Date Range
> 2) Tags
> 
> With this rating, it will be expanded with a Rating Range, and in the future
> (if the patch is not changed drastically) expanded again with Roll Range as
> well.
> 
> Perhaps this could be refactored and simplified a bit. But I do think we need
> to keep them separate, one reason beeing that rating / range / rolls are not a
> tag.
> 
> I am seeing a small veritical slide to the right of the daterange which
> indicates Rating filter. Movable top and bottom, to narrow/expand the rating
> range. (Of course the location can be somewhere else on the gui)

As I see it, we have now three kinds of search criteria:
- unordered criteria (tags) that can be combined with ORs and ANDs
- ordered criteria (date range, rating range)
- rolls (which, I think, can be considered as special cases of tags, maybe tags that do not map to any XMP data).

What I see is to use the date range slide on the top of the window as a place to put all ordered data searches. So I could set the date (narrow it or expand it), click on some button, and switch the date range slide to the rating slide.

My ASCII art is a bit rusty, but it could be like that
             |                     #       #     ###  #
             | (1) Date (+) ###____#_____####___#######_  (-)(2) Rating
--------+-----------------------------------------------------------------
Tags    | Paris AND Mother OR Mother AND London (3)
`-People|-----------------------------------------------------------------
`-Places|
`-...(4)| 

So in the normal operation, you proceed as you do right now for tags.
Clicking on (+) or (-) expands/narrows the date range shown, clicking in the date range slider sets a new point of the search (explanation: if you want to limit January 2006 -- April 2006, first click on january then april. If you click one more time on february, you will get february 2006 -- April 2006. If you click once more on january, you will get January -- february 2006).

If you click on the (2) Rating button, the date range slide collapses (showing only the (1) Date button), and the Rating slide appears (the button (2) moves just right to the Date button (1), the slide appears to the right of the Rating button (2) as follows).

             |                        ## __    ##
             | (1) Date (2) Rating ## ## ## == ## ## __
--------+-----------------------------------------------------------------
Tags    | Paris AND Mother OR Mother AND London (3)
`-People|-----------------------------------------------------------------
`-Places|
`-...(4)| 

If you click first on the *** column then on the **** column, you get all the 
*** - **** pictures of your mother taken either in London or Paris in the January - February 2006 range. Being able to set ordered ranges at the same time does not mean we have to be able to see the two slides at the same time. This way, we can also provide visual feedback of the quantity of pictures unrated, or rated at some specific level (as we do for the month bars).

Well, I do not know if I am clear enough. Please ask if you want more detail. I can even try to do PNG mockups.
Comment 52 Peter 2006-11-08 18:10:38 UTC
The initial suggestion was:

- Un-rated, 
- 0 (throw), 
- 1 (need touchup), 
- 2 (ok), 
- 3 (good), 
- 4 (very good), 
- 5 (excellent)

Personally I think including "zero stars" as well as "unrated" is asking for confusion.

One way to distinguish "unrated" and "zero stars" in the GUI this might then be:

?????
.....
*....
**...
***..
****.
*****

where "*" is a star, "." is a star place holder and "?" is intended to show the photo is unrated.

See also bug 345866 in rythmbox where the GUI does not (currently) make it clear if a track is unrated/zero stars.

Have you considered how "unrated" would be treated in searches?  One suggestion is as a null...
Comment 53 Bradford Powell 2007-02-14 02:02:56 UTC
Created attachment 82508 [details] [review]
Updated to svn as of 2007-02-13

This bug has not seen any activity for a while. Since I was still using an aging version of f-spot so that I could use the rating feature, I decided to finally scratch my own itch and bring the patch up to date.

The attached patch can be applied to svn as of 2007-02-13. It is mostly the rating-11.patch with updates mainly to PhotoStore.cs. PhotoStore.Query had a somewhat clumsy way of chaining together the parts of the WHERE clause, so I changed this to keeping an ArrayList and using String.Join at the end.
Comment 54 Alex Ruddick 2007-03-10 01:19:19 UTC
Is there a good reason this patch is using a custom XMP field instead of the semi-standard IPTC urgency field?  IMHO, using the IPTC field would be much better for increasing interoperability with other programs.
Comment 55 Dotan Cohen 2007-03-10 10:03:09 UTC
Alex,
XMP supersedes IPTC. Also, the F-Spot tagging system already uses XMP.
Comment 56 Alex Ruddick 2007-03-10 16:14:18 UTC
I realize XMP supersedes IPTC, but it's not really widespread yet.  I also realize F-Spot already uses XMP, but an option to use IPTC (while having XMP as default) to work with other programs would be great.
Comment 57 Dotan Cohen 2007-03-10 21:26:32 UTC
F-spot can read and import IPTC tags. It would be more productive to update the 'other programs' to be more current (ie, they should support XMP) than to update F-Spot to work with outdated software. I'm not a developer, so that viewpoint does not represent the F-Spot community at large.
Comment 58 Bengt Thuree 2007-03-14 13:02:20 UTC
Any thoughts of how to go forward with this one?
Has been some months since last work, so hopefully there has been time to decide the best way to implement this one. Since it demands database changes...
Comment 59 Dotan Cohen 2007-03-16 15:34:46 UTC
Use both IPTC and XMP in my opinion, so ensure compatibility with other apps. In case of descrepancy (XMP and IPTC don't match), XMP gets prioroty.
Comment 60 Roel Groeneveld 2007-07-15 13:45:29 UTC
Is this feature request still being considered? The reason I am asking this is that I would love to have a rating fnctionality and filtering based on that. 

This functionality would nicely complement the workflow of all F-spot users that process large amounts of photos. Especially if it will work in full-screen mode, and with keyboard shortcuts for rating (alt+1 for 1 start, alt+4 for 4 starts).  
Comment 61 Stephane Delcroix 2007-07-15 18:25:27 UTC
Roel (comment #60),

this feature will be committed quite soon, but don't ask for delays ;)
Comment 62 Maxxer 2008-01-06 20:50:41 UTC
Created attachment 102286 [details] [review]
rating-2008.patch

Updated the patch to work on latest SVN. There are still TWO bugs:
1. Icons are not loaded. This needs to get fixed to comply to latest themed icons.
2. When a rating is performed, the drawn pixbuf is displayed in iconview on the upper left corner.

Sorry couldn't fix them. But I've fixed some others :-)
Comment 63 Stephane Delcroix 2008-01-15 16:07:48 UTC
committed in r3541