(In reply to comment #0)
> Would be nice to have the Screenshots separate from everything else. In the
> Album view there should be a specific group created automatically.
> 
> I am pondering if we should also hide screenshots in teh Photos view.

I wouldn't hide them, I would either categorise them (nice button at the top 'Photos' | 'Screenshots' | 'Porn') :) or have them in a set album as you say.

How are you currently separating albums, by directory?

You could do this a number of ways, e.g. by directory (i.e. nothing special in Tracker), by tag (stored in each file and Tracker), by adding something to the existing ontology/DB Schema in Tracker (stored only in Tracker).

In Tracker right now there is nmm:category (a property), but it seems used for Videos more. We could fix that. It seems like it's not part of the official standard anyway and an extension we've added. I think it should be more generic too. There is nothing else in the standards about grouping (images) AFAICS.

(In reply to comment #1)
> (In reply to comment #0)
> How are you currently separating albums, by directory?

Each album is a nfo:DataContainer

> You could do this a number of ways, e.g. by directory (i.e. nothing special in
> Tracker), by tag (stored in each file and Tracker), by adding something to the
> existing ontology/DB Schema in Tracker (stored only in Tracker).
> 
> In Tracker right now there is nmm:category (a property), but it seems used for
> Videos more. We could fix that. It seems like it's not part of the official
> standard anyway and an extension we've added. I think it should be more generic
> too. There is nothing else in the standards about grouping (images) AFAICS.

You could figure out that an image is a screenshot by checking GdkPixbuf's tEXt::Software option for 'gnome-screenshot'. This is what the Background panel in Settings does to detect screenshots.

(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > How are you currently separating albums, by directory?
> 
> Each album is a nfo:DataContainer

I quite like this. Philip has also commented on the Tracker mailing list about an approach that could work.
 
> You could figure out that an image is a screenshot by checking GdkPixbuf's
> tEXt::Software option for 'gnome-screenshot'. This is what the Background panel
> in Settings does to detect screenshots.

I see. Yea, very GNOME specific.

Please review:

https://git.gnome.org/browse/tracker/log/?h=gnome-screenshot

Example:

pvanhoof@sput-debian:~/repos/gnome/tracker$ gnome-screenshot -f /home/pvanhoof/screenshot.png
** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting to fallback X11.
pvanhoof@sput-debian:~/repos/gnome/tracker$ tracker-control -f /home/pvanhoof/screenshot.png
(Re)indexing file was successful
pvanhoof@sput-debian:~/repos/gnome/tracker$ tracker-sparql -q "SELECT ?u { ?f nie:isPartOf nfo:image-category-screenshot; nie:url ?u }"
Results:
  file:///home/pvanhoof/screenshot.png
  file:///home/pvanhoof/Pictures/Screenshot%20from%202013-10-08%2010:05:25.png


I also think that GNOME softwares that make screenshots should upfront creation of the file set the same metadata:

INSERT { GRAPH <urn:uuid:ba513750-2ff3-11e3-aa6e-0800200c9a66> { _:f a nfo:Image ; nie:url 'file:///home/pvanhoof/screenshot.png'; nie:isPartOf nfo:image-category-screenshot } }


I have made a uuid for GNOME's screenshot softwares, but you can create or (re)use your own of course. Just DON'T use Tracker's miner-fs UUID. ONLY Tracker's FS miner can use this one. You can generate a UUID for your own software for example here: http://www.famkruithof.net/uuid/uuidgen (or just use UUID tools for this).

(In reply to comment #4)
> Please review:
> 
> https://git.gnome.org/browse/tracker/log/?h=gnome-screenshot

Looking at this part:
+# Philip's proposal for image categories (ie. 'screenshot')
+
+nfo:ImageCategory a rdfs:Class ;
+        rdfs:label "Image category" ;
+        rdfs:comment "A image category" ;
+        rdfs:subClassOf nfo:DataContainer, nie:InformationElement .

Isn't  nfo:DataContainer already a subclass of nie:InformationElement? If it is, then wouldn't it be enough to mention that nfo:ImageCategory is a subclass of only nfo:DataContainer?

(In reply to comment #4)
> Example:
> 
> pvanhoof@sput-debian:~/repos/gnome/tracker$ gnome-screenshot -f
> /home/pvanhoof/screenshot.png
> ** Message: Unable to use GNOME Shell's builtin screenshot interface, resorting
> to fallback X11.
> pvanhoof@sput-debian:~/repos/gnome/tracker$ tracker-control -f
> /home/pvanhoof/screenshot.png
> (Re)indexing file was successful
> pvanhoof@sput-debian:~/repos/gnome/tracker$ tracker-sparql -q "SELECT ?u { ?f
> nie:isPartOf nfo:image-category-screenshot; nie:url ?u }"
> Results:
>   file:///home/pvanhoof/screenshot.png
>   file:///home/pvanhoof/Pictures/Screenshot%20from%202013-10-08%2010:05:25.png

Thanks a lot Philip. This is exactly what I had in mind.

I just built your branch, did a tracker-control -r && tracker-control -s and stuff is getting correctly put into the new screenshot category as expected.

> I also think that GNOME softwares that make screenshots should upfront creation
> of the file set the same metadata:
> 
> INSERT { GRAPH <urn:uuid:ba513750-2ff3-11e3-aa6e-0800200c9a66> { _:f a
> nfo:Image ; nie:url 'file:///home/pvanhoof/screenshot.png'; nie:isPartOf
> nfo:image-category-screenshot } }

I will ask the gnome-shell guys whether they will be willing to do this because it is gnome-shell that does the screenshotting these days (even gnome-screenshot calls out to it).

Hmm, I wonder how much conflict we will get here. If the miner-fs picks up the file before or after. It won't have the nie:isPartOf property but the file will exist (and in a different graph).

The graph really helps GNOME shell or GNOME screenshot/photos software maintain the metadata they write to Tracker.

Philip, can you remember what happens if the the file is stored in two different graphs? When querying, which one is presented? Is it a combination of all data from all graphs, is one presumed if not specified? Presumably, there are 2 different URNs for the same nie:url (file).

(In reply to comment #7)
> Hmm, I wonder how much conflict we will get here. If the miner-fs picks up the
> file before or after. It won't have the nie:isPartOf property but the file will
> exist (and in a different graph).
> 
> The graph really helps GNOME shell or GNOME screenshot/photos software maintain
> the metadata they write to Tracker.
> 
> Philip, can you remember what happens if the the file is stored in two
> different graphs? When querying, which one is presented? Is it a combination of
> all data from all graphs, is one presumed if not specified? Presumably, there
> are 2 different URNs for the same nie:url (file).

Hi Martyn,

We did the exercise for the MTP daemon of the N9 who also writes metadata about content upfront the file existing. If nothing in relation to that technique changed then the Miner FS will not overwrite data written about a nie:InformationElement that isn't in its own graph. Meaning that if the GNOME Screenshot application writes a nie:isPartOf for a nie:InformationElement (the nfo:Image) outside of the Miner FS graph, and it finds the same file as pointed to by nie:url, then Miner FS won't overwrite that metadata (as was done to support the N9's MTP daemon -- msyncd is the process if I recall correctly).

This is why I explicitly mentioned in my comment that you 'DON'T use Tracker's miner-fs UUID'.

(In reply to comment #5)
> (In reply to comment #4)
> > Please review:
> > 
> > https://git.gnome.org/browse/tracker/log/?h=gnome-screenshot
> 
> Looking at this part:
> +# Philip's proposal for image categories (ie. 'screenshot')
> +
> +nfo:ImageCategory a rdfs:Class ;
> +        rdfs:label "Image category" ;
> +        rdfs:comment "A image category" ;
> +        rdfs:subClassOf nfo:DataContainer, nie:InformationElement .
> 
> Isn't  nfo:DataContainer already a subclass of nie:InformationElement? If it
> is, then wouldn't it be enough to mention that nfo:ImageCategory is a subclass
> of only nfo:DataContainer?


I think that nfo:DataContainer was once a nie:DataObject, not a nie:InformationElement. Because indeed the way it is now, nfo:DataContainer is already a nie:InformationElement.

I took this (copypasted) from nfo:SoftwareCategory. I guess we should ask the person who added nfo:SoftwareCategory why he added the rdf:type nie:InformationElement explicitly.

Adding Jürg in CC:

git blame on 33-nfo.ontology:

d559f7be (Jürg Billeter        2009-04-09 11:19:24 +0200  854) nfo:SoftwareCategory a rdfs:Class ;
d559f7be (Jürg Billeter        2009-04-09 11:19:24 +0200  855)  rdfs:label "Software" ;
d559f7be (Jürg Billeter        2009-04-09 11:19:24 +0200  856)  rdfs:comment "A software category" ;
d559f7be (Jürg Billeter        2009-04-09 11:19:24 +0200  857)  rdfs:subClassOf nfo:DataContainer, nie:InformationElement .


Jürg, do you remember why nie:InformationElement got added explicitly as rdf:type in the rdfs:subClassOf of nfo:SoftwareCategory?

That was initial import of NFO, a long time ago, so no, I don't remember this. As it should be functionally equivalent, I don't see why it would matter now.

(In reply to comment #11)
> That was initial import of NFO, a long time ago, so no, I don't remember this.
> As it should be functionally equivalent, I don't see why it would matter now.

Thanks. I'll remove it from my commit. Since ontology change coping doesn't support changing rdfs:subClassOf:


(tracker-store:31181): Tracker-WARNING **: Unknown: Unsupported ontology change for http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#SoftwareCategory: can't change rdfs:subClassOf (old=-, attempted new=-)


I will keep the line for nfo:SoftwareCategory but I won't add nie:InformationElement for nfo:ImageCategory.

Are there any other review comments? Martyn? Jürg? If not I will proceed with push to master.

Updated commit:

https://git.gnome.org/browse/tracker/commit/?h=gnome-screenshot&id=c61cd1b914e64f564ada60b270edd503beffe9c3

Created attachment 256825 [details] [review]
Use a separate collection for screenshots

Requires Philip's Tracker patch.

Comment on attachment 256825 [details] [review]
Use a separate collection for screenshots

Now that Philip's patch has made it into Tracker master, we can commit this to Photos master too.

(In reply to comment #0)
> Would be nice to have the Screenshots separate from everything else. In the
> Album view there should be a specific group created automatically.
> 
> I am pondering if we should also hide screenshots in teh Photos view.

Note that we are only creating a special album for screenshots. Ungrouped screenshots will still show up in the Photos view.

Maybe we should not let the user set a screenshot as the background from the app? It would be consistent with the Background panel in Settings.

(In reply to comment #16)
> (In reply to comment #0)
> > Would be nice to have the Screenshots separate from everything else. In the
> > Album view there should be a specific group created automatically.
> > 
> > I am pondering if we should also hide screenshots in teh Photos view.
> 
> Note that we are only creating a special album for screenshots. Ungrouped
> screenshots will still show up in the Photos view.

Without having to write to the .png file you can get them in the group with a simple sparql insert query. Add a button 'this is a screenshot' to allow the user to execute that query?

(In reply to comment #17)
>> Note that we are only creating a special album for screenshots. Ungrouped
>> screenshots will still show up in the Photos view.
> 
> Without having to write to the .png file you can get them in the group with a
> simple sparql insert query. Add a button 'this is a screenshot' to allow the
> user to execute that query?

It is merely an application level thing that I am talking about.

The application has three tabs: Albums | Photos | Favorites

With these patches an album called "Screenshots" appear under the Albums tab, and all the other photos (including screenshots) appear without any grouping in the Photos tab.

I think what Jakub was pondering on was whether we should hide the screenshots from the Photos tab because they are a bit different from the rest, and let them only be accessed from the album. If we that is what we want, we can easily filter out the screenshots from Photos by tweaking our SPARQL query.

Please reopen if you want to further hide the screenshots from the Photos mode.