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 525690 - Support arbitrary tagging (aka labeling) of items
Support arbitrary tagging (aka labeling) of items
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: general
git master
Other Linux
: Normal enhancement
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
: 542999 638202 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-02 03:31 UTC by Gabriel Burt
Modified: 2020-03-17 08:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gabriel Burt 2008-04-02 03:31:35 UTC
Useful on its own, and lets us interact with Last.fm's tags etc.
Comment 1 lcid-fire 2008-05-15 10:21:48 UTC
The real question is - how do the following systems interact?
There is
NEPOMUK
Beagle
Tracker
Thunderbird
F-Spot
...
who all allow tagging.

At least for music files the following are interesting:
NEPOMUK
Beagle
Tracker
Lastfm
...

To this date I have not seen a unified data store/query system for these things - perhaps the first step should be to write a unified system for all these systems.
Comment 2 Andrew Conkling 2008-07-15 00:03:01 UTC
*** Bug 542999 has been marked as a duplicate of this bug. ***
Comment 3 Chenthill 2009-03-05 12:02:37 UTC
I would like to add the support for tags similar to f-spot. Should it be done as an extension  or can it remain in the core piece ?
Comment 4 Gabriel Burt 2009-03-10 17:22:45 UTC
I'm not sure.  It could probably be done as an extension, which is always good b/c then the Core code is kept cleaner/simpler.  We don't currently have any QueryFields or ListView columns added to sources not defined by that extension, but we can definitely make whatever Core changes are needed for that.

It would also be cool if as much as possible was generic so it could be used for not just tracks, but artists, albums, or anything (eg photos if f-spot switched to using our libraries).  To that end, perhaps a lot of the non-Banshee/Track spedcific work could go in Hyena, and then your extension would be a very simple instantiation of that/tying it to our specific database/classes.

Anybody have ideas for the best way to implement this, in terms of the database layout and queries?  Having a table of tags and then a join table is the obvious way.  But if we were to allow searching on tags (which of course we should), I think we'd have to use subqueries normally.  Unless we stored the TagIDs for a given track in the CoreTracks table in a TagIDs string column and then did "where INDEX_OF(TagIds, ',22,') > 0" (or use LIKE), but that sounds gross/probably slow as well.

CCing John to get his thoughts.
Comment 5 Shaun McCance 2009-03-10 17:36:35 UTC
http://bugzilla.gnome.org/show_bug.cgi?id=487281

Possibly something to keep in mind when thinking of how to put a list of attributes on a track.
Comment 6 Chenthill P 2009-03-20 09:39:38 UTC
Gabriel, thanks for the information! Starting to look into Hyena.
Comment 7 Sebastian Krämer 2010-05-12 10:48:09 UTC
That feature would be great. It's something that almost qualifies as a killer feature of that other once-popular linux media player.
Could have been a GSOC project maybe..
Comment 8 Gabriel Burt 2011-01-11 21:43:15 UTC
*** Bug 638202 has been marked as a duplicate of this bug. ***
Comment 9 Agustín Dall'Alba 2011-01-16 16:09:55 UTC
( I'm the reporter of Bug 638202 )
I knew that someone must had to think about this before.

I made a somewhat useful mockup (there is a LOT of room for improvement though)

"
http://b.imagehost.org/0306/banshee.png 
As you can see, the genre column is replaced by a 'tags' column (Replacing is
not necessary, but the genre becomes redundant one you start tagging the
music). Adding, deleting and editing tags must be as easy and fast as possible.
In the top of the windows, next to the search box the list of tags is
displayed. In the mockup, you click on a "Add tag..." tag on a italicized gray
font and type to set a new tag, and click a x button next to any tag name (like
x buttons next to tabs in many apps) to remove one. (I used 16x16 gtk_close)
The "Tags" column should have the same behavior if possible, if not, at least
is should be possible to edit a comma-separated list of tags with one click.

There should be an easy way to add or delete a tag to more than one track
without deleting the tags that it already has or adding more. Maybe an extra
tab in the track editor (something like this:
http://d.imagehost.org/0275/banshee-track-editor.png ) would do, but its
inconsistent with the rest of the track editor.
"

I love that this idea is getting implemented :D
Comment 10 Andrés G. Aragoneses (IRC: knocte) 2011-01-16 23:24:26 UTC
(In reply to comment #9)
> I love that this idea is getting implemented :D

Mmmm, I don't see the bug being in ASSIGNED/INPROGRESS status. Are you volunteering? ;)
Comment 11 Agustín Dall'Alba 2011-01-18 21:39:39 UTC
(In reply to comment #10)
> Mmmm, I don't see the bug being in ASSIGNED/INPROGRESS status. Are you
> volunteering? ;)

Oh, I wish I could do something useful... But nope, I'm just optimistic. This IS getting attention though, look at all these comments
Comment 12 Sean Wedig 2011-01-25 17:27:45 UTC
I also wanna throw my hat in and say that this would be a killer feature for me as well.  Arbitrary tagging / labeling of music files is, in my opinion, essential for managing a large collection.  Most people that disagree just haven't tried it yet. ;)  (kidding, kidding)
Comment 13 André Klapper 2020-03-17 08:19:13 UTC
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.