Move plugins to another folder?

deekerman commented

2026-02-21 17:28:31 -05:00

Owner

Originally created by @sledgehammer999 on GitHub (Sep 23, 2016).

Originally assigned to: @sledgehammer999 on GitHub.

Hey now that I pushed github.com/qbittorrent/qBittorrent@b3a7954363 we can move the plugin folder around in the repo starting with 3.4.0.

Starting with 3.3.8 all version till 3.4.0 will include the new URL, so hopefully we will break very few older clients.

Originally created by @sledgehammer999 on GitHub (Sep 23, 2016). Originally assigned to: @sledgehammer999 on GitHub. Hey now that I pushed https://github.com/qbittorrent/qBittorrent/commit/b3a79543637b3660e6c9b2d38c6aea763e6de8be we can move the plugin folder around in the repo starting with 3.4.0. Starting with 3.3.8 all version till 3.4.0 will include the new URL, so hopefully we will break very few older clients.

deekerman

2026-02-21 17:28:31 -05:00

closed this issue
added the
Search engine
label

deekerman commented

2026-02-21 17:28:37 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Sep 23, 2016):

@qbittorrent/qbittorrent-frequent-contributors is there any place to move in the folder structure?
I vaguely remember that @glassez wanted to move it around in the past.

PS: This is a discussion. If the current position is ok, I don't have a problem closing this issue without modification.

@sledgehammer999 commented on GitHub (Sep 23, 2016): @qbittorrent/qbittorrent-frequent-contributors is there any place to move in the folder structure? I vaguely remember that @glassez wanted to move it around in the past. PS: This is a discussion. If the current position is ok, I don't have a problem closing this issue without modification.

deekerman commented

2026-02-21 17:28:37 -05:00

Author

Owner

@Chocobo1 commented on GitHub (Sep 24, 2016):

maybe host it in another git repo?
then its possible to promote others to have write access.

@Chocobo1 commented on GitHub (Sep 24, 2016): maybe host it in another git repo? then its possible to promote others to have write access.

deekerman commented

2026-02-21 17:28:37 -05:00

Author

Owner

@ngosang commented on GitHub (Oct 3, 2016):

maybe host it in another git repo?
then its possible to promote others to have write access.

+1

@ngosang commented on GitHub (Oct 3, 2016): > maybe host it in another git repo? > then its possible to promote others to have write access. +1

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@glassez commented on GitHub (May 9, 2017):

IMO, leaving only plugin engine in qBittorrent is good idea. We should get rid from "official" plugins. Someone can manages separate plugins repo.

@glassez commented on GitHub (May 9, 2017): IMO, leaving only plugin engine in qBittorrent is good idea. We should get rid from "official" plugins. Someone can manages separate plugins repo.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@glassez commented on GitHub (May 9, 2017):

I would also replace nova3 based plugin engine with some common plugin interface that allow call any compatible executable.

@glassez commented on GitHub (May 9, 2017): I would also replace nova3 based plugin engine with some common plugin interface that allow call any compatible executable.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@zeule commented on GitHub (May 9, 2017):

I would also replace nova3 based plugin engine with some common plugin interface that allow call any compatible executable.

Makes sense, +1. Any script language can be used then.

@zeule commented on GitHub (May 9, 2017): > I would also replace nova3 based plugin engine with some common plugin interface that allow call any compatible executable. Makes sense, +1. Any script language can be used then.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 9, 2017):

OK, I leave this open in tab. I'll create a repo later. Do you guys have name sugggestions? eg search-plugins ?

@sledgehammer999 commented on GitHub (May 9, 2017): OK, I leave this open in tab. I'll create a repo later. Do you guys have name sugggestions? eg `search-plugins` ?

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@zeule commented on GitHub (May 9, 2017):

qBittorrent-search-plugins to be in line with the web-site repo.

@zeule commented on GitHub (May 9, 2017): `qBittorrent-search-plugins` to be in line with the web-site repo.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@Chocobo1 commented on GitHub (May 9, 2017):

qBittorrent-search-plugins to be in line with the web-site repo.

I was hoping @ngosang could adopt the current plugins in his own repo... if this is not too much to ask.

@Chocobo1 commented on GitHub (May 9, 2017): >qBittorrent-search-plugins to be in line with the web-site repo. I was hoping @ngosang could adopt the current plugins in his own repo... if this is not too much to ask.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 9, 2017):

qBittorrent-search-plugins

Some reason this looks ugly in my eyes.

I was hoping @ngosang could adopt the current plugins in his own repo

I could make him admin in the new repo...

@sledgehammer999 commented on GitHub (May 9, 2017): `qBittorrent-search-plugins` Some reason this looks ugly in my eyes. >I was hoping @ngosang could adopt the current plugins in his own repo I could make him admin in the new repo...

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@Chocobo1 commented on GitHub (May 9, 2017):

I was hoping @ngosang could adopt the current plugins in his own repo

I could make him admin in the new repo...

I mean moving to an unoffical repo

@Chocobo1 commented on GitHub (May 9, 2017): >>I was hoping @ngosang could adopt the current plugins in his own repo > >I could make him admin in the new repo... I mean moving to an unoffical repo

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@glassez commented on GitHub (May 9, 2017):

Some reason this looks ugly in my eyes

+1

@glassez commented on GitHub (May 9, 2017): >Some reason this looks ugly in my eyes +1

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@glassez commented on GitHub (May 9, 2017):

We shouldn't distribute any plugins with qBittorrent.

@glassez commented on GitHub (May 9, 2017): We shouldn't distribute any plugins with qBittorrent.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@glassez commented on GitHub (May 9, 2017):

And we shouldn't have official plugins repo, of course.

@glassez commented on GitHub (May 9, 2017): And we shouldn't have official plugins repo, of course.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 9, 2017):

I am not being negative, just curious. Why shouldn't we distribute plugins or have official repo?
The reviews I have read in the past indicated that his was the biggest advantage of this client.

@sledgehammer999 commented on GitHub (May 9, 2017): I am not being negative, just curious. Why shouldn't we distribute plugins or have official repo? The reviews I have read in the past indicated that his was the biggest advantage of this client.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@thalieht commented on GitHub (May 9, 2017):

Plausible deniability i guess.

@thalieht commented on GitHub (May 9, 2017): Plausible deniability i guess.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@Chocobo1 commented on GitHub (May 9, 2017):

Plausible deniability i guess.

spot on.

Personally, I don't want anyone to think we are affiliated with any of those tracker operations.

@Chocobo1 commented on GitHub (May 9, 2017): >Plausible deniability i guess. spot on. Personally, I don't want anyone to think we are affiliated with any of those tracker operations.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@glassez commented on GitHub (May 9, 2017):

I don't think that it will greatly reduce the advantage, if plugins are distributed separately.

@glassez commented on GitHub (May 9, 2017): I don't think that it will greatly reduce the advantage, if plugins are distributed separately.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@Chocobo1 commented on GitHub (May 9, 2017):

The reviews I have read in the past indicated that his was the biggest advantage of this client.

I understand, we won't drop any of its functionality, we just let users install it manually, that's all.

@Chocobo1 commented on GitHub (May 9, 2017): >The reviews I have read in the past indicated that his was the biggest advantage of this client. I understand, we won't drop any of its functionality, we just let users install it manually, that's all.

deekerman commented

2026-02-21 17:28:38 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 9, 2017):

I had missed https://github.com/qbittorrent/qBittorrent/pull/6762#issuecomment-300154738

Personally, I find it dubious legally that we are responsible on what ours users do. Google isn't held responsible for their search results. But in any case, I won't oppose this. It is less work for me and probably others.
And on the other hand it will allow the propagation of plugin fixes and inclusion to be more rapid.

Question is how far should we go?

Remove plugins from repo
Don't distribute plugins with releases (binary/source)
Don't use http://searchplugins.qbittorrent.org to redirect to plugins. Alternatively make the URL user configurable. User inputs URL of repo/site/service that has the expected layout by the search engine to find/update plugins. Also a link to wiki explaining stuff and having links to such repos/sites/services.
Also remove most of the categories. And refactor to allow the plugins to "install" their categories, which in turn will populate the GUI list.

Finally, even if we agree to any of the above, should we first wait for someone to explicitly adopt the plugin repo or just delete them from our repo?

@sledgehammer999 commented on GitHub (May 9, 2017): I had missed https://github.com/qbittorrent/qBittorrent/pull/6762#issuecomment-300154738 Personally, I find it dubious legally that we are responsible on what ours users do. Google isn't held responsible for their search results. But in any case, I won't oppose this. It is less work for me and probably others. And on the other hand it will allow the propagation of plugin fixes and inclusion to be more rapid. Question is how far should we go? 1. Remove plugins from repo 2. Don't distribute plugins with releases (binary/source) 3. Don't use `http://searchplugins.qbittorrent.org` to redirect to plugins. Alternatively make the URL user configurable. User inputs URL of repo/site/service that has the expected layout by the search engine to find/update plugins. Also a link to wiki explaining stuff and having links to such repos/sites/services. 4. Also remove most of the categories. And refactor to allow the plugins to "install" their categories, which in turn will populate the GUI list. Finally, even if we agree to any of the above, should we first wait for someone to explicitly adopt the plugin repo or just delete them from our repo?

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@Chocobo1 commented on GitHub (May 10, 2017):

Question is how far should we go?

Yes
Yes
Don't use http://searchplugins.qbittorrent.org to redirect to plugins.

Yes

Alternatively make the URL user configurable. User inputs URL of repo/site/service that has the expected layout by the search engine to find/update plugins.

This is too much work for little gain, IMO the installed plugins should give qbt an URL to update/check version (maybe in the future).
Maybe not... too much freedom in this case, could bring up issues like: i18n translations, different term for the same categories (e.g. books, ebooks).
We should maintain a predefined set.

should we first wait for someone to explicitly adopt the plugin repo or just delete them from our repo?

Either way will work, the new maintainer can checkout an older version of the master branch and get the plugins.

@Chocobo1 commented on GitHub (May 10, 2017): >Question is how far should we go? 1. Yes 2. Yes 3. >Don't use http://searchplugins.qbittorrent.org to redirect to plugins.<br> Yes >Alternatively make the URL user configurable. User inputs URL of repo/site/service that has the expected layout by the search engine to find/update plugins. This is too much work for little gain, IMO the installed plugins should give qbt an URL to update/check version (maybe in the future). 4. Maybe not... too much freedom in this case, could bring up issues like: i18n translations, different term for the same categories (e.g. books, ebooks). We should maintain a predefined set. >should we first wait for someone to explicitly adopt the plugin repo or just delete them from our repo? Either way will work, the new maintainer can checkout an older version of the master branch and get the plugins.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@glassez commented on GitHub (May 10, 2017):

Maybe not... too much freedom in this case, could bring up issues like: i18n translations, different term for the same categories (e.g. books, ebooks).

You're right... So I've updated my answers.

Agree
Agree
Agree
Disagree. We should maintain a predefined set.

should we first wait for someone to explicitly adopt the plugin repo or just delete them from our repo?

We should delete them from our repo/distributions first. I don't think that creating a repository of plugins is too difficult and long. Moreover, we have someone who is willing to do it. @ngosang, isn't it? I hope he even make it to 3.4 final release.

@glassez commented on GitHub (May 10, 2017): >Maybe not... too much freedom in this case, could bring up issues like: i18n translations, different term for the same categories (e.g. books, ebooks). You're right... So I've updated my answers. 1. Agree 2. Agree 3. Agree 4. Disagree. We should maintain a predefined set. >should we first wait for someone to explicitly adopt the plugin repo or just delete them from our repo? We should delete them from our repo/distributions first. I don't think that creating a repository of plugins is too difficult and long. Moreover, we have someone who is willing to do it. @ngosang, isn't it? I hope he even make it to 3.4 final release.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 13, 2017):

Sorry, I'm late..

I would also replace nova3 based plugin engine with some common plugin interface that allow call any compatible executable.

I don't care about the core, but the plugins should be in powerful scripting language like Python, Lua... I can combine nova2 & nova3 code to make it compatible with Python2 and Python3 so we don't need to duplicate code...

I was hoping @ngosang could adopt the current plugins in his own repo... if this is not too much to ask.
I could make him admin in the new repo...

I prefer an official repo with admin permissions. That will make plugins more trustworthy..

We shouldn't distribute any plugins with qBittorrent.
And we shouldn't have official plugins repo, of course.

I'm strongly opposed, as sledgehammer said, this is the only feature that makes qBittorrent unique. Things should work out the box, without manual installing. Today the search feature is already disabled by default, if you ask the user to manually install plugins this won't be used by anyone...

We should delete them from our repo/distributions first. I don't think that creating a repository of plugins is too difficult and long. Moreover, wAe have someone who is willing to do it. @ngosang, isn't it?

I'm not going to maintain plugins if they are so hidden that no body uses it. I can make my own scripts for that...

We aren't having legal throubles because we are not supporting piracy, just using some public sites to find legit torrents. We are not liable for the content of these sites and we are not making any profit with that.

@ngosang commented on GitHub (May 13, 2017): Sorry, I'm late.. > I would also replace nova3 based plugin engine with some common plugin interface that allow call any compatible executable. I don't care about the core, but the plugins should be in powerful scripting language like Python, Lua... I can combine nova2 & nova3 code to make it compatible with Python2 and Python3 so we don't need to duplicate code... > I was hoping @ngosang could adopt the current plugins in his own repo... if this is not too much to ask. I could make him admin in the new repo... I prefer an official repo with admin permissions. That will make plugins more trustworthy.. > We shouldn't distribute any plugins with qBittorrent. And we shouldn't have official plugins repo, of course. I'm strongly opposed, as sledgehammer said, this is the only feature that makes qBittorrent unique. Things should work out the box, without manual installing. Today the search feature is already disabled by default, if you ask the user to manually install plugins this won't be used by anyone... > We should delete them from our repo/distributions first. I don't think that creating a repository of plugins is too difficult and long. Moreover, wAe have someone who is willing to do it. @ngosang, isn't it? I'm not going to maintain plugins if they are so hidden that no body uses it. I can make my own scripts for that... We aren't having legal throubles because we are not supporting piracy, just using some public sites to find legit torrents. We are not liable for the content of these sites and we are not making any profit with that.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ArionMiles commented on GitHub (May 17, 2017):

We aren't having legal throubles because we are not supporting piracy, just using some public sites to find legit torrents. We are not liable for the content of these sites and we are not making any profit with that.

This is worth discussing over. @Chocobo1 initially wanted to remove the plugins because of what happened to PopCorn Time, but those guys were directly promoting piracy through their tool. It isn't the same for qBit.

OTOH, While we do not have legal troubles now, there may be a time in future, though.

@ArionMiles commented on GitHub (May 17, 2017): >We aren't having legal throubles because we are not supporting piracy, just using some public sites to find legit torrents. We are not liable for the content of these sites and we are not making any profit with that. This is worth discussing over. @Chocobo1 initially wanted to remove the plugins because of what happened to PopCorn Time, but those guys were directly promoting piracy through their tool. It isn't the same for qBit. OTOH, While we do not have legal troubles now, there may be a time in future, though.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 21, 2017):

OTOH, While we do not have legal troubles now, there may be a time in future, though.

The must send you a DCMA requesting the removal of torrents/features before legal actions. If you comply and won't be any trial.

@ngosang commented on GitHub (May 21, 2017): > OTOH, While we do not have legal troubles now, there may be a time in future, though. The must send you a DCMA requesting the removal of torrents/features before legal actions. If you comply and won't be any trial.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 21, 2017):

@qbittorrent/frequent-contributors any more thoughts about this topic? The development of 2 plugins is hold on until we have an agreement on that.

@ngosang commented on GitHub (May 21, 2017): @qbittorrent/frequent-contributors any more thoughts about this topic? The development of 2 plugins is hold on until we have an agreement on that.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@Chocobo1 commented on GitHub (May 21, 2017):

I can agree we move to another repo (official one or not) as a first step.

@Chocobo1 commented on GitHub (May 21, 2017): I can agree we move to another repo (official one or not) as a first step.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@glassez commented on GitHub (May 21, 2017):

At least I would manage all plugins the same way (i.e. I wouldn't distribute official plugins inside app binaries) and I would move it outside the main app sources tree.

@glassez commented on GitHub (May 21, 2017): At least I would manage all plugins the same way (i.e. I wouldn't distribute official plugins inside app binaries) and I would move it outside the main app sources tree.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@glassez commented on GitHub (May 21, 2017):

I wouldn't distribute official plugins inside app binaries

I mean, they should be installed by app installer (if we choose to distribute it with app) or by app itself from repo.

@glassez commented on GitHub (May 21, 2017): >I wouldn't distribute official plugins inside app binaries I mean, they should be installed by app installer (if we choose to distribute it with app) or by app itself from repo.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 21, 2017):

At least I would manage all plugins the same way (i.e. I wouldn't distribute official plugins inside app binaries) and I would move it outside the main app sources tree.

What about a build-in downloader in qBittorrent? The installer wouldn't contains any plugin. The Search plugins list will show all "official" plugins and let you install with one click.

@ngosang commented on GitHub (May 21, 2017): > At least I would manage all plugins the same way (i.e. I wouldn't distribute official plugins inside app binaries) and I would move it outside the main app sources tree. What about a build-in downloader in qBittorrent? The installer wouldn't contains any plugin. The Search plugins list will show all "official" plugins and let you install with one click.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@MadeOfMagicAndWires commented on GitHub (May 21, 2017):

Sorry to chime in as a unofficial plugin creator but I agree with @ngosang that making installing plugins a completely manual process or hiding them makes it more or less useless. People will at that point just switch to searching on the sites instead.

The problem with Popcorn Time and others is that it's software tailored towards TV Series and Films. There are no legit downloads for TV series or films (save like 5).
qBittorrent doesn't have that same focus and even if some of the sites these plugins are made for also host torrent files to copyrighted material, they can still be solely used searching for legit content.
Have a repostory; just don't add any plugins that are tailored towards copyrighted material like you've always done.

I would also replace nova3 based plugin engine with some common plugin interface that allow call any
compatible executable.

I may misinterpret what you're going for, but as far as nova is concerned, I'm not opposed to moving away from it on principle; but it's been nice having the prettyPrinter and helper functions.

I think it'd be hard to provide that same utility with anything that is still also fully compatible with all sort of calls, apart from saving and reading search results from files in some universal format like json.

By not having those helper functions, you then make things less accessible to less experienced users from contributing by making new search engines themselves.

(edited for better reading)

@MadeOfMagicAndWires commented on GitHub (May 21, 2017): Sorry to chime in as a unofficial plugin creator but I agree with @ngosang that making installing plugins a completely manual process or hiding them makes it more or less useless. People will at that point just switch to searching on the sites instead. The problem with Popcorn Time and others is that it's software tailored towards TV Series and Films. There are no legit downloads for TV series or films (save like 5). qBittorrent doesn't have that same focus and even if some of the sites these plugins are made for also host torrent files to copyrighted material, they can still be solely used searching for legit content. Have a repostory; just don't add any plugins that are tailored towards copyrighted material like you've always done. > I would also replace nova3 based plugin engine with some common plugin interface that allow call any > compatible executable. I may misinterpret what you're going for, but as far as nova is concerned, I'm not opposed to moving away from it on principle; but it's been nice having the prettyPrinter and helper functions. I think it'd be hard to provide that same utility with anything that is still also fully compatible with *all* sort of calls, apart from saving and reading search results from files in some universal format like json. By not having those helper functions, you then make things less accessible to less experienced users from contributing by making new search engines themselves. (edited for better reading)

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@glassez commented on GitHub (May 22, 2017):

I may misinterpret what you're going for, but as far as nova is concerned, I'm not opposed to moving away from it on principle; but it's been nice having the prettyPrinter and helper functions.

I meant to give up the current 3 tier architecture (qBittorrent manages plugins via nova3), but leave it (nova3) as a helper library. But this far-reaching plans...
Now I propose to do the following (assuming we still have the official plug-ins):

Remove plugins from qBittorrent sources tree (and move to another repo)
Don't distribute it as part of qBittorrent binaries
When user use Search feature first time download and install the official plug-ins (or only offer to do it)
Continue to manage the official plugins as any other (eg. allow to delete them)

@glassez commented on GitHub (May 22, 2017): >I may misinterpret what you're going for, but as far as nova is concerned, I'm not opposed to moving away from it on principle; but it's been nice having the prettyPrinter and helper functions. I meant to give up the current 3 tier architecture (qBittorrent manages plugins via nova3), but leave it (nova3) as a helper library. But this far-reaching plans... Now I propose to do the following (assuming we still have the official plug-ins): 1. Remove plugins from qBittorrent sources tree (and move to another repo) 2. Don't distribute it as part of qBittorrent binaries 3. When user use Search feature first time download and install the official plug-ins (or only offer to do it) 4. Continue to manage the official plugins as any other (eg. allow to delete them)

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ArionMiles commented on GitHub (May 22, 2017):

When user use Search feature first time download and install the official plug-ins (or only offer to do it)

If we're doing this, can we at least have the Search tab enabled by default? There's no way newer users will know about the feature, much less use it, if they don't see it.

@ArionMiles commented on GitHub (May 22, 2017): >When user use Search feature first time download and install the official plug-ins (or only offer to do it) If we're doing this, can we at least have the Search tab enabled by default? There's no way newer users will know about the feature, much less use it, if they don't see it.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@glassez commented on GitHub (May 22, 2017):

can we at least have the Search tab enabled by default?

Maybe it makes sense... but how this your offer is related to plugin distribution method?

@glassez commented on GitHub (May 22, 2017): >can we at least have the Search tab enabled by default? Maybe it makes sense... but how this your offer is related to plugin distribution method?

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ArionMiles commented on GitHub (May 22, 2017):

It doesn't. It just came up in my mind so I made a suggestion.

@ArionMiles commented on GitHub (May 22, 2017): It doesn't. It just came up in my mind so I made a suggestion.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 29, 2017):

I had been reading this thread and thinking. Finally, I came here to write my decision and I discover to my amazement that already the general consensus is in the same direction.
Here is the decision:

Move the plugins in a new repo under "qbittorrent" org. Unless there is strong opposition and someone else entirely wants to host it(eg ngosang).
Point the subdomain to the new repo
Don't include the plugins in the source tarballs and binaries
Minor code modifications to:
1. Inform the user, when he switches to the search tab and no plugins are present, to open the relevant dialog and download them. Do not autodownload. The message might be some infromative text in the list view and not and an intrusive messagebox.
2. Relayout the plugin dialog to have room for a static message like: "WARNING: Be sure to comply with the copyright laws of your country."
Of course, the new repo will have someone else as admin. And maybe we can discuss on what criteria we can flag a search site as unsuitable to be included. IMO, this is a tough one.

can we at least have the Search tab enabled by default?

This is off by design. First time users on Windows will get multiple messageboxes. One to agree to license(?) and one to install Python. Seeing the message about Python will confuse them that it is a hard dependency of qBittorrent and that it will not function properly without it.
IMO, the search function is already quite popular without having that tab on by default. So I don't see any reason to change it. Users, aren't THAT dumb. They take a look at the menus.

@sledgehammer999 commented on GitHub (May 29, 2017): I had been reading this thread and thinking. Finally, I came here to write my decision and I discover to my amazement that already the general consensus is in the same direction. Here is the decision: 1. Move the plugins in a new repo under "qbittorrent" org. Unless there is strong opposition and someone else entirely wants to host it(eg ngosang). 2. Point the subdomain to the new repo 3. Don't include the plugins in the source tarballs and binaries 4. Minor code modifications to: 1. Inform the user, when he **switches** to the search tab and no plugins are present, to open the relevant dialog and download them. Do not autodownload. The message **might** be some infromative text in the list view and not and an intrusive messagebox. 2. Relayout the plugin dialog to have room for a static message like: "WARNING: Be sure to comply with the copyright laws of your country." 5. Of course, the new repo will have someone else as admin. And maybe we can discuss on what criteria we can flag a search site as unsuitable to be included. IMO, this is a tough one. >can we at least have the Search tab enabled by default? This is off by design. First time users on Windows will get multiple messageboxes. One to agree to license(?) and one to install Python. Seeing the message about Python will confuse them that it is a hard dependency of qBittorrent and that it will not function properly without it. IMO, the search function is already quite popular without having that tab on by default. So I don't see any reason to change it. Users, aren't THAT dumb. They take a look at the menus.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@glassez commented on GitHub (May 29, 2017):

Agree with @sledgehammer999 plan.
I have some questions. Who will perform this changes? Do you want to make it yourself? Or someone can help you? Or we should split this task into several jobs? IIRC, this issue is only blocking v3.4 release.

@glassez commented on GitHub (May 29, 2017): Agree with @sledgehammer999 plan. I have some questions. Who will perform this changes? Do you want to make it yourself? Or someone can help you? Or we should split this task into several jobs? IIRC, this issue is only blocking v3.4 release.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 29, 2017):

@glassez, I'll do it myself. Today, I am starting to cherry-pick commits for v3.3.13. Then I'll do this(while building). And then 3.4.0 beta can proceed.

@sledgehammer999 commented on GitHub (May 29, 2017): @glassez, I'll do it myself. Today, I am starting to cherry-pick commits for v3.3.13. Then I'll do this(while building). And then 3.4.0 beta can proceed.

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 29, 2017):

Inform the user, when he switches to the search tab and no plugins are present, to open the relevant dialog and download them. Do not autodownload. The message might be some infromative text in the list view and not and an intrusive messagebox.

But plugins could be downloaded from qBittorrent with one click? Or the user has to open the Browser and install plugins manually?

@ngosang commented on GitHub (May 29, 2017): > Inform the user, when he switches to the search tab and no plugins are present, to open the relevant dialog and download them. Do not autodownload. The message might be some infromative text in the list view and not and an intrusive messagebox. But plugins could be downloaded from qBittorrent with one click? Or the user has to open the Browser and install plugins manually?

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (May 30, 2017):

But plugins could be downloaded from qBittorrent with one click? Or the user has to open the Browser and install plugins manually?

In the search tab there will be informative text for the user to click the "Search plugins..." button.
In that dialog the user can click the "Update" button and get any plugins available in the repo.
Behavior will be changed to ensure that auto-update doesn't happen before the user explicitly opens and downloads the list first.

Does the above make sense?

@sledgehammer999 commented on GitHub (May 30, 2017): >But plugins could be downloaded from qBittorrent with one click? Or the user has to open the Browser and install plugins manually? In the search tab there will be informative text for the user to click the "Search plugins..." button. In that dialog the user can click the "Update" button and get any plugins available in the repo. Behavior will be changed to ensure that auto-update doesn't happen before the user explicitly opens and downloads the list first. Does the above make sense?

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@ngosang commented on GitHub (May 31, 2017):

Does the above make sense?

yes

@ngosang commented on GitHub (May 31, 2017): > Does the above make sense? yes

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jun 1, 2017):

Take a look at #6883

@sledgehammer999 commented on GitHub (Jun 1, 2017): Take a look at #6883

deekerman commented

2026-02-21 17:28:39 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jun 25, 2017):

Code merged.
New repo created: https://github.com/qbittorrent/search-plugins
Subdomain updated too. (GoDaddy servers are unresponsive though atm.)

I added @Chocobo1 and @ngosang as admins to that repo. If you don't want then remove yourself. As admins you can accept new people with write privileges as you fit. And of course you can manage that repo.

I opted for search-plugins as the name of the repo without adding "qBittorrent" in it, in an attempt to denote it as not an official list.

@sledgehammer999 commented on GitHub (Jun 25, 2017): Code merged. New repo created: https://github.com/qbittorrent/search-plugins Subdomain updated too. (GoDaddy servers are unresponsive though atm.) I added @Chocobo1 and @ngosang as admins to that repo. If you don't want then remove yourself. As admins you can accept new people with `write` privileges as you fit. And of course you can manage that repo. I opted for `search-plugins` as the name of the repo without adding "qBittorrent" in it, in an attempt to denote it as not an official list.

Rows
Columns

Move plugins to another folder? #4731