mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Ability to assign more than one label to a torrent #1
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub (Aug 11, 2012).
qBittorrent does not support assigning more than one label to a single torrent.
@cdumez commented on GitHub (Aug 11, 2012):
Would indeed make sense. The issue lies in the "Append label to save path feature". I'm still not sure how to support both features.
@drakkenson commented on GitHub (Aug 12, 2012):
Perhaps making each label become a folderwithin the folder of the preceding label. This would also need a way to change the order of the labels for a given torrent.
@nivensd commented on GitHub (Oct 7, 2012):
With Linux/UNIX systems, at least, a hard or soft link could be utilized to have the torrent files in both folders. Hard link would be preferable, as removing a tag from a torrent would mean just deleting one of multiple pointers to a storage address, versus the soft linking requiring a move of files before the original is deleted.
Example:
Torrent a gets downloaded and tagged with both "StuffILike" and "StuffXLikes". Original files go in folder "StuffILike" and soft link goes in "StuffXLikes". Now if you remove the tag "StuffILike", you must now delete the soft link and move the original files to "StuffXLikes", as the soft link points to location in the directory "StuffILike".
Versus creating a hard link which points to the actual location on the disk.
@Gelmir commented on GitHub (Feb 27, 2013):
Hard links will be pain in the ass to manage on multiplatform.
NTFS supports hard links, not sure about FAT.
Qt has
QFile::link, but it will only create soflinks ( which are.lnkshortcuts on Windows). So this approach will require platform-dependent code; and don't forget about OS/2 port.Using subfolders for each label is not ideal either: we cannot predict what label will be assigned first, second, third, etc. And some users may prefer a strict folder hierarchy for multi-label.
My suggestion: use a master label (which will be appended to path); other labels will not contribute to path expansion.
@GitHub-devel commented on GitHub (Mar 14, 2013):
I used this in uTorrent - it really helps for organizing your torrents.
@Belove0 commented on GitHub (Apr 10, 2013):
I commented on a newer repeat post of this feature request already;
It's very handy -
uTorrents solution is to have a main label (and other labels). The main label is used for the save path feature. The main label can be changed with right-click menu (other labels can too, I forget exactly what the menu structure is).
This also calls for the ability to select multiple labels on the sidebar. uTorrents original behavior was to have "OR" (inclusive) logic when multi selcting with ctrl and shift, but, I understand, recently they added an option to use "AND" logic instead (which is the only logic I find useful for the way I use labels).
Thanks and good day to you :)
@Belove0 commented on GitHub (Apr 10, 2013):
Regarding hard links - yes NTFS supports them, but without Windows GUI features to manage them (at least one third-party plugin is available though).
FAT does not support them. There's no reference counter. You can cross-link files if you're especially clever, but CHKDSK will "fix" your work for you :).
The file system for Windows 8 I believe does away with both hard links AND symbolic links, but adds a new type of ".LNK" like file that behaves similar to symbolic links. This from my vague recollection from reading the release notes some time ago. So basically, forget hard links in Windows.
@jaredmcateer commented on GitHub (Sep 12, 2013):
When implementing this features I would like to recommend having a list of checkboxes rather than a dropdown for both the add torrent dialog as well as the RSS downloader.
It's a bit of a ux pain in the butt to have to choose a single label in the add dialog, then locate the torrent in the list and right click then navigate to labels then select another label (and repeat for all the labels you plan to add.)
It does add a bit more complexity if dealing with the primary label problem but you could always make it clear the first choice is the primary and then give an option for changing it.
@DancingDirty commented on GitHub (Sep 15, 2013):
May I suggest a double labeling-tagging system? so you keep the labeling system AS IT IS, BUT you ADD-CREATE a new system that you call it TAG/TAGGING something like that that you allow for only inner qBittorrent organisation of torrents.
So what I suggest:
1.Label system stays as it is (maybe rename to archive system or Filing system)
2.add a tagging system for inner qBittorrent torrent management
as "AsaRossoff commented 5 months ago"
""This also calls for the ability to select multiple labels on the sidebar. uTorrents original behavior was to have "OR" (inclusive) logic when multi selcting with ctrl and shift, but, I understand, recently they added an option to use "AND" logic instead (which is the only logic I find useful for the way I use labels)."" that should be impemented in my tagging system!
Also I am gonna make a new post about my idea (as it is kinda a new idea on the subject) in order to make it more popular!
@JinxDojo commented on GitHub (Jan 6, 2014):
I would also like to see multiple labels/tags. @cdumez: simply make the first label "primary" and the rest auxiliary. While hard/symbolic links are an interesting idea, I don't think it is realistic for qBT to "force" a tag system into a hierarchal directory system--not without a tag-based filesystem.
Please don't let that issue stop you from adding multiple labels!
@Kervius commented on GitHub (Mar 30, 2014):
Since this is the ticket about multiple labels, and in the context people often express need for hierarchical label tree (aka sublabels), allow me to dump an idea here.
If QBT implements sublabels/label tree, then there is an interesting opportunity: when sorting torrents by label, show the label tree right inside the torrent list. (IIRC Qt's listview supports that right out of the box.) In spirit, that is very similar to how QBT shows the batch torrents with subdirectories.
That would keep the UI still simple, since there is no need to change the UI paradigm to make space for the tree.
Bonus feature: collapsing/folding a label would hide the torrents assigned to it.
FYI.
@buinsky commented on GitHub (Feb 7, 2015):
@qbittorrent/qbittorrent-frequent-contributors
Should the labels system be redesigned in such a way? What do you think?
@buinsky commented on GitHub (Feb 9, 2015):
@sledgehammer999 What if I will redesign labels system to look above? This can close multi-labels per torrent and sublabels feature requests.
@glassez commented on GitHub (Feb 9, 2015):
@buinsky I think you will not be difficult to implement the assignment of the labels to torrents. But what to do with what the labels needed? I mean, sorting, filtering, and effects on the save path. Have you thought about this? Leave the description.
@buinsky commented on GitHub (Feb 9, 2015):
@glassez Will be main label which will be assigned to torrent (like in uTorrent). It will displayed in labels collumn like label1/sublabel1/sublabel2 . Each label will have default save path (
{default save path}/{label path}). Will be ability to assign custom path per label. Selected item of the tree will be used as label filter. Checked state of the tree items will be changed according to selected torrents:@glassez commented on GitHub (Feb 9, 2015):
It is clear (in theory - wait implementation).
But you have mentioned about multi-labels per torrent. What about this?
@buinsky commented on GitHub (Feb 9, 2015):
If you will check several labels they will be assigned to selected torrents.
@glassez commented on GitHub (Feb 9, 2015):
And the sort? It will be only one of them? On the main? Then what the label will be the main one - the first assigned?
@buinsky commented on GitHub (Feb 9, 2015):
Sort will use the main label. By default the main label will be the first assigned label but you will be able to select the main label.
@sledgehammer999 commented on GitHub (Feb 9, 2015):
You should read #917 it has some ideas too.
I had similar thoughts about this just like buinsky.
But a little bit different:
IMO, we can't implement everything. Some of the requested will be dropped.
If I have understood the many users that have complained about the labeling system in the bug tracker and in the forum, their first priority is "I want to assign more labels to a torrent" and not "I want to have multiple labels to construct the save path".
So, IMO, the best solution is category+tags (or main label+ sub labels as buinsky named it). However, the current system of constructing the save path from the label should be dropped. Instead the user can assign a path to each category.
The above isn't a decision on what to do as a project manager. It is observations and proposed solutions at this point.
Now I'll attempt to make a list of what people want with labels. This will make easier the discussion for ANY proposed action.
PS: I re-read buinsky's proposal and I think it is very similar to my conclusion. However about the checkboxes: If we just allow multiselecting in the side pane wouldn't that suffice? -because checkboxes look ugly there-
@buinsky commented on GitHub (Feb 10, 2015):
@sledgehammer999
OK. Then another variant:
It would be nice if the category of selected torrent(s) will stand out (for example with asterisk at the end). It will look like this:
@sledgehammer999 commented on GitHub (Feb 10, 2015):
What is the use of asterisk?
Is your variant the same as mine? (I suggested one category-multiple tags)
@glassez commented on GitHub (Feb 10, 2015):
It is possible, I also try to organize here?
@sledgehammer999 commented on GitHub (Feb 10, 2015):
@glassez I am confused. You say one category per torrent but then you talk about subcategories. In my mind these are mutually exclusive things.
@glassez commented on GitHub (Feb 10, 2015):
I spend a mapping to the directory structure of the file system. When I say "only one category", I mean "only one path". This does not exclude subcategories. For example, the torrent can be either in
Category1, or inCategory2, or inCategory1/Category13, or inCategory2/Category24/Category243, but not in few of them at the same time. As a file in the file system - it can only be in one place (not including links).@sledgehammer999 commented on GitHub (Feb 10, 2015):
I thing I get what you're saying. But in this case, aren't tags useless?
@glassez commented on GitHub (Feb 10, 2015):
Possible.
I would have done so... First I would implement Categories with all their features and have looked at user reviews. If they need something else, it will be possible to consider it then.
@buinsky commented on GitHub (Feb 10, 2015):
@glassez В коде такая мешанина, что капец...
@glassez commented on GitHub (Feb 11, 2015):
@buinsky Please speak English. It may be interesting not only for us.
In answer to your comment... (it's gone for some reason)
Now I redesign QBtSession and QTorrentHandle. Because almost all of the rest of the code depends on this, I'll have to change it. I think that I could not prepare a workable PR sooner than a month. Maybe I will post a partial change earlier for review.
@sledgehammer999 commented on GitHub (Feb 12, 2015):
Guys the past few days I was thinking about all said in here. Here are my conclusions.
Allowing to set a path per label is more preferable than the feature "append label to save path". So the feature "append label to save path" should be dropped in favor of custom paths per label.
Also, allowing sublabels is much more preferable than allowing multiple labels per torrents.
So, unless you have a good objection we should proceed with that. (I suspect that this was the original proposal of buinsky but I didn't understand it completely).
The only question I can think of at the moment is if we should limit the depth of sublabels? eg mainlabel->sublabel1->sublabel2->sublabel3->sublabel4?
@sledgehammer999 commented on GitHub (Feb 12, 2015):
I forgot to mention that in the above scenario we don't need "tags".
@glassez commented on GitHub (Feb 12, 2015):
IMO, Three levels should be enough.
@sledgehammer999 commented on GitHub (Feb 12, 2015):
Just to be on the same page: You mean mainlabel->sublabel->sub-sublabel
@glassez commented on GitHub (Feb 12, 2015):
Yes.
@buinsky commented on GitHub (Feb 12, 2015):
What is the reason to limit the depth of sublabels?
@DancingDirty commented on GitHub (Feb 12, 2015):
please do not drop the tag idea, being able to tag torrents means that two torrents might not be in the same category but share the same tag.
For eg:
you got a category videos and a category mods for which you use a path to save them so they are nicely in your drive, but lets say that the video is about or is a screencapture of a game and the mod is for the same game, you could make a tag in qbittorent so when you want to see what torrents you have about that game it would show the video and the mod!!!
@DancingDirty commented on GitHub (Feb 12, 2015):
heavily edited, sry 😋 So sum up what I believe should be the outcome:
1.a way of putting torrents in organised folders (most here call it categories, I would title it filing and call it folders and subfolders) and no limit to how many to make! why limit them? should windows limit how many subfolders a user can make? NO :D
2.a way of tagging torrents so we can tag similar torrents to find them easily (even if the torrents are filed in different folders!) tagging would work like the torrent filtering that is already being done by selecting paused, active etc
For eg:
you got a category videos and a category mods for which you use a path to save them so they are nicely in your drive, but lets say that the video is about a game or is a screencapture of a game and the mod is for the same game, you could make a tag in qbittorent so when you want to see what torrents you have about that game it would show the video and the mod!!!
~radio buttons for categories/filing/folders
~checkboxes for tags
so user can assign category/filing/folder easily.
and it would look like buinsky previewed just I would propose also tags on top and filing in the bottom!
so here is my preview. 1.when a torrent is selected, green is the folder of the torrent 2.if multiple torrents selected that are in different folders, the folders are orange 3. when one torrent is selected, the tags of the torrent are green 3.when multiple torrents are selected, the tags that both torrents have are green, the other tags that some of the torrents have are orange.
the user for easy assignment of a folder or tag the next would happen 1. Selecting a torrent or torrents and clicking next to a folder in a radio button gray or orange assigns all torrents to that folder. 2. when selecting a torrent or torrents and clicking the gray or orange boxes next to the tags all torrents get assigned those tags, when clicking the green all torrents lose this tag.
@JinxDojo commented on GitHub (Feb 12, 2015):
Yes. As another user stated: please do not drop the tag idea. Personally, I want to be able to assign labels (tags) based on a few parameters (e.g. audio/video/game, source of torrent/magnet, etc.). Then, I could CTRL+Select multiple labels (tags) on the left field to display just those items (no checkboxes or sublabel hierarchy needed).
I have little interest in the save paths, as I set those manually. Allowing a single-assignable category to control the save path is a fine idea. Trying to do so via tags/labels would require each tag/label to have its own properties, which seems beyond the scope of tags/labels (and more akin to "groups").
The number one goal should be the ability to select multiple labels and then apply properties to all of them at once. So, if I really wanted to adjust save paths, I could select tags "audio" and "SomeTorrentSite", then right click to adjust the save path for all selected torrents.
I realize this doesn't help so much with some of the automatic retrieval stuff, but I think that scenario should be secondary to the fundamental UI improvement provided by multiple labels/tags.
@sledgehammer999 commented on GitHub (Feb 12, 2015):
Ok fair enough I see your use cases for tags. They should be included (if buinsky can implement them).
Depth of labels should be limited only if it is difficult codewise to work for infinite levels. (I doubt there is such a problem).
About the asterick: Do we really need it? The selected label will be highlighted anyway. (like it does right now).
@DancingDirty commented on GitHub (Feb 12, 2015):
maybe reserve the "selected" category/folder for filtering perposes only. eg: when you see all torrents and have selected one torrent there should not be a category/folder selected because when a user selects a folder it should filter the torrent list to show only which torrents are in that selected category/folder!
and if you select a category which has subcategories, maybe torrents in the same categories should show up first and then sperated a bit all other torrents in the other subcategories... 🐹
@DancingDirty commented on GitHub (Feb 12, 2015):
also can we split the discussion to a thread for categories/folders and a thread for tags cause are two different things and I want to put forward some ideas for tagging, like cntr+clicking on some tags should show all torrents assigned any of those tags and shift+some tags should show only which torrents have been assigned all selected tags! :D
@Belove0 commented on GitHub (Feb 13, 2015):
It's been a nerve-wracking few days (hehe) as I've followed this discussion... The feature is important to me, and I have limited time and resources right now to add to the discussion as much as I'd like. However, I mostly like where the discussion seems to be going at this point.
Goals?
User Interface & Interface Feature Suggestions
One system
Implicit filepaths
Instead, use our current method for the "Append the label of the torrent to the save path" feature of appending the actual text that constitutes the label to the path. With the labels in a hierarchy as I suggest, we can just separate the labels of the hierarchy with the OS path separator character (slash). The only issue is specifying which single label to use for this feature. uTorrent's solution is to have one label be called the "primary label", and that label is used for the "append to...save path" feature.
Hierarchy
@DancingDirty commented on GitHub (Feb 13, 2015):
the taggging system is not "filing" the torrents, its just a way to interact with torrents in qbt and filter them. the only reason we (me and some others) are talking about tags in this thread is because people ask for a way to assign multiple labels, which is not usefull when you can apend a path to a label that would mean that a torrent would reside in two paths/folders in the file system. So instead of messing with the labels functionality, labels would be an ideal way for "filing" torrents into the file system, and tags for in qbt managment
@JinxDojo commented on GitHub (Feb 13, 2015):
I'm glad tags will still be considered. To avoid confusion, I recommend you follow your original idea and rename the primary/current/save-path-related label to "category" or "group" (especially the latter if you plan to have torrents automatically inherit other properties by being a member of that group).
What we have referred to here as tags (for clarification), G-mail et al call "labels"--so I think it might be confusing to keep calling the category/group a label. True: a rose by any other name would smell as sweet, but if you call it a "stink-bucket" people might not even bother to smell it!
Perhaps after a few versions have passed using only the terms tags and categories/groups, the term "label" can be reintroduced in place of tags.
Also, what AsaRossoff and DancingDirty wrote above regarding inclusive/exclusive filtering could be useful, but how easy would it be to implement in the UI without messy checkboxes? Shift+click often selects a range of items, so perhaps Alt+click could be used instead. Still: how would it be shown whether all tagged torrents are shown (inclusive) or only torrents with all the selected tags (exclusive). Perhaps a different selection color?
As I implied above (and I think most have agreed), we do definitely need two separate systems: one for selection/application and another for inheriting properties (e.g. save-path). I think the only way to avoid this would be to make some labels/tags have properties and some not, as labels/tags are inherently non-hierarchical, so precedence for properties could not be easily determined.
Small edit regarding categories/groups: If tags/labels are implemented, is there still a need to make the categories/groups hierarchical? The selection issues will no longer be relevant, and for setting properties (save-path)--as far as I can tell--users could do that themselves by naming categories "Category1.SubCategory11.SubSubCategory.111" etc. Is it an issue of horizontal display space? Or vertical? If vertical: is anyone really planning to have so many categories that collapsing/expanding sub-categories will be needed? I'm definitely not opposed to the idea, I just think it could be a bit confusing (both for the user and to code). For example: could sub-categories/groups override inherited values from their parent category? Are there plans to make categories/groups inherit any other properties (e.g. ratio/bandwidth limits)?
@buinsky commented on GitHub (Feb 13, 2015):
What about such variant?
Remove tags from the filters widget.
Filtering:
Edit tags of the selected torrents:
Edit tags dialog window:
@DancingDirty commented on GitHub (Feb 15, 2015):
seems good, maybe the location of "edit tags" would be nice if it was in the bottom part as a tab next to "content"? and the dialog window down there? also how will you deal with multitorrent selection that have different tags? will you leave the tags that only some torrents have on the right side with different color?
or maybe like this:
edit: the extra idea I was going to comment here, I posted it as a seperate post #2559 aka [Wishlist] add custom saved search filtering - also advanced search
@sledgehammer999 commented on GitHub (Feb 23, 2015):
Guys I am moving this to v3.3.0. I am a little bit focused on releasing v3.2.0 and I am not able to fully follow this discussion.
I'll try to respond the next few days.
@910nico commented on GitHub (Mar 6, 2015):
@buinsky Thanks for your work :)
I really need this feature to limit download and upload speed, i'm seeding more than 10TB of files with several HDD.
Example for download: allow to limit the use of a HDD to prevent the 100% usage.(very big problem with optic fiber)
Example for upload : allow to limit each tracker for a better equality of seeding .
example :
Parent category ->"HDD 1" limited to 15MB/s
Child tag-> "Tracker 1" limited to 6 MB/s
Child tag-> "Tracker 2" limited to 6 MB/s
Child tag-> "Tracker 3" limited to 6 MB/s
Child tag-> "Tracker 4" limited to 6 MB/s
but the difficulty is other HDD can also contains this trackers
example :
Parent category ->"HDD 2" limited to 20MB/s
Child tag-> "Tracker 1" limited to 6 MB/s
Child tag-> "Tracker 2" limited to 6 MB/s
...
So a category should have a local effect but a tag should have a global effect and a category should have priority over a tag
@EraYaN commented on GitHub (Apr 1, 2015):
The way Tixati (1.99) does it is also pretty great (so you can set different ratio goal for different kind of stuff).
http://imgur.com/F4xiua2
Also they have a setup where every category has it's own paths.
@Namanati commented on GitHub (Oct 4, 2015):
I agree I really like the system Tixati has set up, as you can make a category (label), and for each one set a download location, move location (which can be the same or different), and have them listed in categories of their own. Like in mine I have TV Series (Called a Separator in Tixati), with all my Series listed under it, each one automatically downloads to the correct location. In my case I have the download and move location the same, but those could different if a person needs to download to a faster drive and then move to a slower drive as an example. Clicking on the labels lets you see all the torrents under them. TV Series label list all TV Series, while the individual of course just list that particular series (i.e. Continuum). I have movies, music, software along with the TV Series, all stored on separate drives and/or directories, including network locations if needed.
@sledgehammer999 commented on GitHub (Nov 1, 2015):
@ everyone here: This thread has become huge and now I am lost. Is anybody actively working on this? Speak so I can wait for you for v3.3.0. Otherwise, I won't consider this for fixing for v3.3.0.
@glassez commented on GitHub (Nov 1, 2015):
I think you shouldn't do so. It's a very complex issue and we not come to the understanding of how it should be (not to mention some of the implementation).
@glassez commented on GitHub (Nov 2, 2015):
@sledgehammer999 Moreover, I don't think you should assign any milestone for this now.
@sledgehammer999 commented on GitHub (Nov 2, 2015):
In case someone already has done work behind the scenes... I am not going to wait if he starts now.
@EraYaN commented on GitHub (Nov 2, 2015):
I seem to recall someone had a working implementation and also one working with the webui (I think he used that as a starting point, after it was said someone was building a multiple label/tagging system).
I can try to find it when I'm home if you want? I feel there might have been a PR already.
@sledgehammer999 commented on GitHub (Nov 2, 2015):
The webui PR is already noted and almost ready for merging. The multi-label PR I cannot find. It probably was a proof-of-concept code residing in someone's repo, not as a PR.
@EraYaN commented on GitHub (Nov 2, 2015):
Yes I can't find it either. I think I have imagined it or mixed up fbarriga and/or ngosang (same guy?)
@glassez commented on GitHub (Nov 3, 2015):
@sledgehammer999, @EraYaN, as I said above, we have not yet concluded how this should work. What kind of implementation you are talking now?
Recall the basic problem of multiple labels:
@ngosang commented on GitHub (Nov 7, 2015):
I think this feature is unnecessary for most users and we will have to change too many things to get this correctly implemented in the UI and in the WebUI.
I think a set or list of tags is enough.
I don't know. Maybe we can disable this option if multiple labels feature option is enabled. You can't have all things.
@glassez commented on GitHub (Nov 8, 2015):
+1
+1
IMO, We can't please everyone at once. Moreover, users ' desires are often at odds with each other.
@sledgehammer999 commented on GitHub (Nov 9, 2015):
Well, we can copy what others are doing and don't try to reinvent the wheel. And if we can't (or care) to implement that due to complexity... well there are a ton of other things we can implement in the bug tracker.
@JinxDojo commented on GitHub (Nov 10, 2015):
In case this is something that is being worked on, I'd like to reiterate from my February 12th, 2015 post:
"The number one goal should be the ability to select multiple labels and then apply properties to all of them at once."
This is fundamental to the UI, and it is a use case that does not interfere with the other use cases (namely: the automatic save-path assignment). We have let this issue get muddled for too long, conflating the two major end-goals. It is not nearly as complex as it seems--if you stick with the goal of UI improvement. Labels/Tags are a priority!
By the way, if a tag system is implemented, and someone wants to edit save paths easily, he/she can mass select all members with that tag, and apply a new save path. I admit this isn't "automatic," but it demonstrates why the UI improvement supersedes the auto-save-path assignment, which should really be placed in another issue entirely.
As an aside: I tried in a previous post to articulate the difference between tags/labels and groups/categories, but I'm not sure if it stuck. Tags/labels are properties of a torrent, whereas groups/categories contain a torrent (and thus can apply properties to them). I think this is an important distinction to make when discussing this further.
@Danny3 commented on GitHub (Nov 20, 2015):
I'm curious about one thing,
Will it be possible, without chekckboxes to select mutiple non-consecutive labels only with the mouse?
In every user interface I've seen this is only possible using the other hand to press the CTRL key
Normally I'm using only the mouse to control the torrents and it would be nice not to be forced to use the keyboard if it's not really necessary
@mesvam commented on GitHub (Jan 20, 2016):
If you're worried about complexity, is it possible to solve a simpler version of the problem? Something with just multi-label/tags, and selection by a single label, with no other fancy logic.
There's been a lot of good suggestions, but they're all more complex than necessary to solve the fundamental problem, which is the "ability to assign more than one label to a torrent." You can extend upon that later if you want to add label trees, check boxes, and/or logic, save path, primary/secondary labels, bandwidth limits, etc, but so many tasks would be exponentially easier, even with just a rudimentary multi-label system.
This is literally the oldest and also one of the most discussed issues of qBittorrent, and has been the only thing preventing me from switching to qBittorrent for years. It's pretty important to me (and evidently many others as well) to be able to label and select torrents in terms of both "tracker X" and "music" for example. Also two of the most popular clients uTorrent and Vuze have had this for a while. So I doubt it's an unpopular feature. Please, I'm begging you, just give us something... anything.
@Tsyko commented on GitHub (Jan 20, 2016):
Totally agree with @mesvam
The simplest possible solution would make me happy.
@ghost commented on GitHub (Jan 20, 2016):
@sledgehammer999
Yo have moved my suggestion here but that's a wrong approach. Please read my comments:
"I talk about adding "/" as allowed character in labels so the program creates subfolders when moving downloaded torrents, not mentioned in any way having multiple labels."
No way my request is a duplicate of this thread. In fact is a totally different thing which has nothing to do with the mega-discussing here (even if someone mentioned it).
@FerdinandoLM commented on GitHub (Jan 24, 2016):
as @Isabelxxx i'd really appreciate a way to create subfolders. I don't really need sublabels, but subfolders are a neat and clean way to store files.
@glassez commented on GitHub (Jan 24, 2016):
Guys, now I'm considering the implementation of Advanced Saving Management subsystem. It, in particular, will allow you to specify arbitrary paths (either relative or absolute) for labels.
@FerdinandoLM commented on GitHub (Jan 24, 2016):
@glassez even better! So i don't necessarily have to keep the label name the same as the folder name.
@JinxDojo commented on GitHub (Jan 25, 2016):
@All: Please consider creating a new, separate thread for "save path" issues; this thread was and should be about assigning labels. As I said last November: we have let this get far too muddled in the save path issue--unnecessarily.
All we need is a simple "tag" system for UI selection. That is much more fundamental and is all this thread should be focused on. We do not need a hierarchy of labels. We do not need to worry about advanced saving paths. As has been stated above: if a label really must be associated with a save path, let each torrent have a "primary" label (or call it a "category"--with the distinction that torrents automatically inherit attributes from their "category").
Personally, I don't see why a label should even be associated with a save path in the first place. Each torrent has its own save path stored in memory. Whatever assigns the label could just as well assign the save path, no? Perhaps we could consider just eliminating the label:save-path relationship?
Regardless, discussing ways of handling the save path much further than what's necessary to enable the label system does not seem beneficial/appropriate for this thread, which is about assigning multiple labels ("tags"). We need to clarify this issue if we're ever going to get something implemented.
@mesvam commented on GitHub (Jan 27, 2016):
I would support a dichotomy of labels vs tags, as @JinxDojo has suggested. This would not require any change to existing behavior, so people can still use it for save path management if that's what they really want.
I agree. When you add a torrent, it already prompts you for a save location. Using labels to further modify that path is redundant and makes it more confusing for me. What I would like is a tagging system, because there exists no workaround for this problem.
@EraYaN commented on GitHub (Jan 28, 2016):
The labels and seperate directories can be used for automation (different labels for different post processors)
@mribichich commented on GitHub (Feb 10, 2016):
+1
@dogancelik commented on GitHub (Feb 23, 2016):
👍
@WillfulChild commented on GitHub (May 9, 2016):
After switching from utorrent, I'm finding the lack of multiple labels a significant handicap. Why not have a primary label for save path, and allow multiple secondary labels, like utorrent does?
@mesvam commented on GitHub (Jun 18, 2016):
It seems @glassez was planning on implementing a tagging subsystem as a part of #4696 back in January.
Is that still part of the plan? #4784 shows as merged without the feature.
@mesvam commented on GitHub (Oct 28, 2016):
So are there no current plans for tags? Not even a rudimentary tag system? I've seen a lot of progress for subcategories.
@tgregerson commented on GitHub (Jun 3, 2017):
I've also been putting off switching from uTorrent due to this feature, so I finally broke down and started implementing it myself. I have a working prototype for a Tags system using the main GUI. Compared to Categories, the primary differences are:
Tags are intended to be as flexible as possible, so end users may utilize them for whatever niche use case they have. Personally, I have a hard time remembering whether I've actually listened to that album I downloaded, so I use tags to add a TODO to a torrent that I can remove when it's done.
Aside from that, they should be pretty familiar for users of Categories:
Only simple single-tag filtering is possible right now, but you can get AND filtering in combination with the Category and Torrents filters:
I also played around with a uTorrent-like approach of solving the Category -> Path mapping problem. Instead of having separate Category and Tags systems, you would just have a single "main" Category designated for a torrent and multiple "non-main" Categories, and only the main Category would be used to determine the save path. However I felt like this was more complex and confusing to users than logically separating Categories and Tags.
These features seemed like interesting future extensions, but not necessary for the initial implementation:
Feedback is welcome.
@mesvam commented on GitHub (Jun 3, 2017):
This looks perfect! Just what we've all been waiting for. Are you going to submit a pull request?
@tgregerson commented on GitHub (Jun 5, 2017):
Thanks for the kind words. You can see the PR linked above.