uqBittorrent?

[bfelten]

Now that uTorrent users like me are abandoning what used to be a microTorrent client, but as of version 3.0 became a miniTorrent and now is more like a midiTorrent client, I'm starting to wonder if qBittorrent shouldn't fork out to a uqBittorrent client, with many of the present extras stripped away?

1. WEB UI: How many users actually use this? 2%? 5%?

2. Language support: Nice, but if you don't understand English, there's a lot of alternatives.

3. RSS support: It used to be great, and I used it a lot on Azureus (when it still was) and later on on uTorrent. But the last year or so it's never worked reliably for me.

4. Running your private tracker: Cool, but there are other ways to do that much more efficiently.

Given enough time, I bet lot's of people can think of other functions that can be removed in order to create a true uqBittorrent client with all the powers of qBittorrent still intact.

What has to be added ASAP IMHO is a function to import all the settings from an uTorrent install. Then all the uT users still insisting on uT 2.2.1 or earlier will no longer have any reason to remain on the uT train.

After all that, maybe the uqBittorrent source can even come in one single package, with one single MAKEFILE, so that thousands of people can compile it, and contibrute to the further developement -- not just the lucky few who manages to compile it with all the hazzles required today.  Just have 'gcc' installed and then issue the command 'make win64', 'make linux32' or whatever... 

[Nemo]

As I know to what you are refering to (Im not using RSS either) I must say that there will be always people who say ''add this'' or ''remove that'' so adding or stripping down isn't really a option in my opinion. By adding I mean more the things like build in media player or streaming and all other things like these (which I personally don't want to see in qBittorrent). Browsing the forums will lead to these various suggestions. Building 2 seperate builds might be possible but the question is more like; is it needed ? I get your point  of course.

[bfelten]

[quote="NeMo_0"] I get your point  of course. [/quote]

Thanks NeMo. And rest assured I've been on many enough discussion boards like this for the last decade to know that you're absolutely right. There will always be users who tricks the developers into adding new "features" into a s/w product. That's exactly what happened to uTorrent, I think.

But my point is, that if there were a micro version of qBt, that was easily compiled without the need to add hundreds of MB of extras to manage a compile, then we could get hundreds -- if not thousands -- of new contributors that could help streamline the core of qBt. Something that a "regular" version could benefit from as well.

I myself am primarily an ASM programmer -- by profession since 40 years -- and I would love to take some of the modules here and optimize them. But I can't even get the damn thing to compile properly...

[ironcross]

As for me - i don't use these things too, but i don't think they're not needed. They're people who use them and that's why such things is called "options" - if you want use them, if don't want - hide them. I think qB needs all options related to the succesful torrenting - and the things above are necessary for that in one or another case. Also with them qB looks very good in comparison with the rivals. The language support is essential - there are a lot of people who looks for software in their native languages. The thing that is not needed is multimedia support and shit like that - they're not related to torrenting and there quite good players for that (KMPlayer for me). If we start removing features now, qB only will lose users.

[Dayman]

You cannot make a small client out of qBt. Most of the size comes from libraries, qBt depends on: libtorrent, Qt and OpenSSL. Removing few qBt options won't affect the size a big time.
RTTI requirements are also taking its' toll. 

The source already comes in one package. You just can't build it w/o building dependencies first.

---

uT is small because it's written in WINAPI, w/o any (AFAIK) 3rd-party libraries and is packed with UPX. This approach is not gonna work for qBt - it's targeting multiple platforms and requires a level of abstraction from OS with the help of boost, libtorrent and Qt.

[bfelten]

You cannot make a small client out of qBt.

Of course I (or rather we, I hope) can!

Most of the size comes from libraries, qBt depends on: libtorrent, Qt and OpenSSL. Removing few qBt options won't affect the size a big time.
RTTI requirements are also taking its' toll.

That's just it. If there's any way to get rid of most of this bloating, the size (not only actual MB size, but more importantly the actual footprint of the client) as well as what needs to be compiled, can be severely reduced. Without e.g. the web interface, do we need the openssl package at all?

The source already comes in one package. You just can't build it w/o building dependencies first.

Exactly. And all the hoops that anyone trying to compile it on various platforms, must pass through, will scare a lot of potential contributors away, IMHO.

uT is small because it's written in WINAPI, w/o any (AFAIK) 3rd-party libraries and is packed with UPX. This approach is not gonna work for qBt - it's targeting multiple platforms and requires a level of abstraction from OS with the help of boost, libtorrent and Qt.

I know. But since we already are heavily depending on a lot of platform dependant compile settings, why not make the Windows thread use all the available Windows functions? All the basic functions will still be the same, but dynamically linking to the available GUI functions will reduce the size of this all considerably -- I think...

As I recall it, the Windows version of qBt is something like a 10MB+ exe. Is that a reasonable prize to pay, just to not use all the available Windows functions, when it's still available all the time whether you use it or not?

Just my 2 cents -- feel free to bash me if you think I'm wrong.

[sledgehammer_999]

[quote="bfelten"]Without e.g. the web interface, do we need the openssl package at all?[/quote]

Yes, we still need OpenSSL for encrypted bittorrent connections(libtorrent uses it).

[quote="bfelten"]Exactly. And all the hoops that anyone trying to compile it on various platforms, must pass through, will scare a lot of potential contributors away, IMHO.[/quote]

I don't want to discourage you in contributing but this is standard practice. Most of open source projects don't package any dependencies in their source distribution. Hunting down the latest version of each dependency and compiling all of them is the task of the packager.

[quote="bfelten"]I know. But since we already are heavily depending on a lot of platform dependant compile settings, why not make the Windows thread use all the available Windows functions? All the basic functions will still be the same, but dynamically linking to the available GUI functions will reduce the size of this all considerably -- I think...[/quote]

Because we want "write once compile everywhere". I think the only acceptable exception to include platform specific code is when the required functionality isn't provided by qt/boost/libtorrent. Also, I may be misinterpreting things, but the huge culprit for size bloat is the usage of templates in stl, qt, libtorrent, boost. But you cannot throw out template usage with losing everything that makes C++ the language that it is.

[quote="bfelten"]Is that a reasonable prize to pay, just to not use all the available Windows functions, when it's still available all the time whether you use it or not?[/quote]

Can you clarify what you mean, I don't follow.

[Peter]

A bit late (and I guess someone already wrote this): The features you mentioned are only small fragments of codes which would reduce the size by a portion. Nothing huge.

If you want something lightweight, you would need a native Windows GUI (no deps), and a custom libtorrent (no libssl).This whole thing would fit into a few megs. Even uTorrent comes with a private tracker and it's 700KB at the moment (with the whole installer. Thought it's packed with UPX, it's still small.)

The thing is.. it's hard to make something "small" on Linux. Of course it will be lightweight if you use GTK for example. Or Qt. Both are fast. But the user got to have the libraries in order to run the client. And there is no thing like "Native GUI" under Linux. Maybe pure X11. But have you ever seen such a hideous thing like that? I promise you that you do NOT want to code something in that.


The Windows client packs Qt and SSL with it. That's why it's so "big".
Of course you could just install Qt and SSL.. and applications would call them.. like on Linux..
But that doesn't happen on Windows. Things don't behave like that (they could.)

On Linux, it's a smaller package... but the dependencies once again.. have to be fetched.



====
Maybe you could have a Java client, but that's anything but small and lightweight.
Or just write the core in C++ and the use separate GUI for each OS? Already been done by Transmission.

Once you start fiddling with it, you will see what Sledge meant.

[Seedthis]

Hello bfelten,

I don't think that a fork to a µqBittorrent client would be useful, you might end up as the only one to use it.

A lot of users actually chose qBt because of its features, and because it's an open source project. I use the WebUI every day because it's needed to connect to the client via Transdroid. I can add/control torrents while being away from my computer, using my phone. The WebUI is also useful when you run qBt on a server.

I also use the RSS autodl sometimes but not often because it lacks of some options (already submitted a ticket on the issue tracker).

OpenSSL is also a necessity for many many users.

qBittorrent resources usage is not that high in fact if you compare it to other maintained clients (not counting abandoned apps and excluding µTorrent). Transmission-Qt Win is also based on Qt and almost use the same amount of ram. Deluge and Tixati use more ram than qBt on my machine. Right now, with 296 torrents containing a total of 46 000 files for 310 GB, qBt uses 68 MB of ram and 2 to 6% of my CPU (C2D 2.4 GHz).

[Dayman]

[quote="sledgehammer_999"]
[quote="bfelten"]Without e.g. the web interface, do we need the openssl package at all?[/quote]

Yes, we still need OpenSSL for encrypted bittorrent connections(libtorrent uses it).

[/quote]
Plus Rss downloader will need it for https feeds.

[quote="sledgehammer_999"]
[quote="bfelten"]Is that a reasonable prize to pay, just to not use all the available Windows functions, when it's still available all the time whether you use it or not?[/quote]
Can you clarify what you mean, I don't follow.
[/quote]
It probably means using dlopen (or whatever it's called on windows) and importing required WINAPI functions one by one (use explicit linking instead of implicit). But this is not possible w/o complete rewrite and ditching Qt.

[loki]

Well if you're aim is to re-create "utorrent" open-source and you would require a rewrite for winapi? You might as well call it uBittorrent... (it was originally called q because of using Qt) with the actual "u" and not the "micro" symbol, and Bittorrent instead of Torrent. I would think that the official name software wouldn't be able to complain, sure it's similar but doesn't use either "unique identifier." And uB as short version.

Now as for Windows specific optimization. Python, is it only used for the search function (as I read on wikipedia)? I don't use it anyway, and last I checked there's all sorts of problems with getting it working at all on Windows, or if it even does.