goodmind / sunflower-fm

Automatically exported from code.google.com/p/sunflower-fm
GNU General Public License v3.0
1 stars 0 forks source link

Adding the conception of 'labels' or 'tags' #297

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
IMHO it is useful to add the conceptions of 'labels' or 'tags' to sunflower.

Here I collect some rough ideas:

* Labels/Tags are an optional grouping and filter mechanism for
  line items (file, directory, link, ...) of the file list.
* Every line item can be linked to none, one or more 'labels'.
* A new label is created when it is encoded on the first use.
* An existing label can be choosen from a list.
* A label is deleted, when it is no longer used to tag an item.
* It is possible to search for labeled line items system wide.
* A directory can be filtered by labels. None, one or more labels can be
  choosen as a filter.
* Maybe show and link labels in a tagcloud.
* Maybe plugin to other existing applications like Reggata[1], tagstore[2] or
  adapting existing tags from other file managers.
* Maybe adding pictures to a label which act like an emblem on the file icon
  (see issue 48). It provides a visual representation of the label.

[1]https://github.com/vlkv/reggata
[2]http://tagstore.ist.tugraz.at is IMHO a nice idea, but it is limited to
   six tags per file, creating symlinks in a reasonable time. Big benefit
   would be having everywhere the same tag feature.

Original issue reported on code.google.com by udo.spallek@googlemail.com on 23 May 2013 at 1:39

GoogleCodeExporter commented 9 years ago
[2]... there seems to be many solutions to solve the problem: 

http://www.tagsistant.net/ http://dbfs.sourceforge.net/ 
http://labels-project.blogspot.de/ 
http://stackoverflow.com/questions/3263036/filesystem-that-uses-tags-rather-than
-folders http://projects.gnome.org/tracker/features.html. It seems 
http://en.wikipedia.org/wiki/Zeitgeist_%28framework%29 is the actual storage 
for this kind of data. I am not experienced with this conceptions and a little 
confused about the many solutions.

Maybe the best is to have a simple internal solution, which can plug-in a 
different data storage if needed.

Original comment by udo.spallek@googlemail.com on 23 May 2013 at 3:17

GoogleCodeExporter commented 9 years ago
Question about Zeitgeist and tagging:
http://bloc.eurion.net/archives/2012/zeitgeist-python-api-tutorial/comment-page-
1/#comment-210891

Original comment by udo.spallek@googlemail.com on 23 May 2013 at 3:55

GoogleCodeExporter commented 9 years ago

Original comment by MeanEYE.rcf on 23 May 2013 at 4:04

GoogleCodeExporter commented 9 years ago
Issue 48 has been merged into this issue.

Original comment by MeanEYE.rcf on 23 May 2013 at 4:05

GoogleCodeExporter commented 9 years ago
Emblems are really useful for working down a TODO list (e.g. process contents 
of folders) etc. Already supporting one emblem / a limited number of emblems 
would be great added value! Btw, we can currently easily add and remove emblems 
by defining custom commands, as per:
http://askubuntu.com/questions/3403/get-a-files-emblem-from-command-line?rq=1
...but the problem is that the added emblems do not show in sunflower (they do 
in nautilus). Anyway, in case showing the emblems was supported, the above 
command and support for custom key bindings for commands (Enhancement Request 
#99) would almost get us there.

Thanks for considering

Original comment by nig...@gmail.com on 28 Sep 2013 at 10:42

GoogleCodeExporter commented 9 years ago
Thank you for posting this solution. It will help me solve this issue a lot 
faster. :) I will soon make Sunflower edit and display emblems, it's a useful 
feature for all users. Thanks!

Original comment by MeanEYE.rcf on 29 Sep 2013 at 10:26

GoogleCodeExporter commented 9 years ago
I've been looking into this solution and here's what I've came up with. 
Nautilus has abandoned the whole emblem thing. All the emblem information was 
stored in GVFS "metadata::*" namespace. 

In this namespace anyone can add anything they want. There's no predefined list 
of parameters of specified format. Since Nautilus abandoned this feature, 
there's no reason for us to make support for Nautilus emblems as they are 
Nautilus specific. Now the real question is if other file managers are using 
the same way of assigning emblems. If they are, then we will do as well. 
Otherwise I think we are better off writing our own support for emblems as we 
can probably offer better flexibility, for example support emblems in archives, 
remote drives etc.

I need more information about other file managers before proceeding to 
implement this feature. Any help is welcome.

Original comment by MeanEYE.rcf on 18 Feb 2014 at 9:54