Re: [Tracker] Tagging and Nautilus

[Jamie McCracken <jamiemcc blueyonder co uk>]

John Stowers wrote:
>     Uh, this would be sweet. Fx. Firefox stores base64 encoded favicons
>     in its search engine description files. Tracker could do something
>     similar for tags... Great idea. 
>
>
> Actually i remember now. I hacked on a patch to leaftag that actally did 
> this, but after some discussion the devs decided that storing embedded 
> images for the tags was a bad idea because for tags which exist in the 
> icon-theme the user would expect that the images for these tags should 
> change when the icon theme changes.
>
> Me, im not so sure. I think there are more practical uses where the user 
> may want to apply their own image for a tag (see f-spot) and in this 
> case there are two options;
> 1) embed the tag image
>   + Survives the case where the tag image is deleted
>   - Takes space in the DB
> 2) embed the full path to the tag image
>  + Does not take much DB space
>  - Does not survive when tag images are removed (but at least we can 
> fail gracefully)
>
> So I propose;
>
> 1) new libtracker method
> tracker_keywords_get_list_with_images
> returns both images and either stock-id (only icon-theme spec compatible 
> stock icons allowed) OR the path to a file to be used as the tag image
> 2) corresponding new DBus method/s
> org_freedesktop_Tracker_Keywords_get_list_with_images
> tracker_dbus_method_keywords_get_list_with_images
> 3) new db method
> tracker_db_get_keyword_list_with_images
> 4) new stored procedure
> GetKeywordListWithImages
> which also returns the appropriate MetaDataValue from the appropriate 
> ServiceBlobMetadata corresponding to the keyword in question
>
> So this also requres the storage of a ServiceBlobMetaData for each 
> keyword. Use blob metatdata so its not indexed, and within that store 
> either the stock icon id or the filename to the icon.
>
> Obviously reverse functions would need to be implemented like
> tracker_keyword_add_image(keyowordID, stock_id_or_path)
>
> I am just checking that the more invasive changes regarding getting the 
> keywords and images are really necessary. I presume simpler methods 
> could be implemented, like tracker_keyword_get_image() but this would 
> involve 2x the DB calls which may be ugly if you want to get the images 
> for lots of tags
>
> Thoughts? I am really keen to hack on this so it would be good to get 
> perspective of the best direction to go in

my thoughts are we need a freedesktop based dir to get tag images from 
with image name = "tag name".png

we could use nautilus emblems for starters so keywords would need to 
match the emblem name

--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/