refractor: simplify torrent model signal emissions
The Torrent->Application signal connections make up for about 5% of the
app's memory use. Move this to the TorrentModel so that there are only a
handful of signal connections.
Moving signals to TorrentModel means batch change signals can be emitted
instead of per-change-per-torrent emissions and can be handled that way.
* refactor: don't load the same stock more than once
Some actions share an icon -- for example, "start all", "start now", and
"start" each use "media-playback-start". When this happens, get the icon
once and cache it to avoid hitting the disk more often than necessary.
In addition, the statusbar's network transfer icon was being reloaded in
a periodic upkeep timer, reloading with QIcon::fromTheme each time. Only
give icons are needed, so load them once and cache them.
* refactor: better lookup of torrent mime-type icons
filename-to-mime-type and mime-type-to-icon lookups are both expensive,
so do a better job of detecting top-level folders and caching the icons
based on file suffixes.
This also lets find a good mime icon even if the torrent doesn't have
its 'files' property populated yet from RPC.
This way all the qualifiers (`const`, `volatile`, `mutable`) are grouped
together, e.g. `T const* const x` vs. `const T* const x`. Also helps reading
types right-to-left, e.g. "constant pointer to constant T" vs. "constant
pointer to T which is constant".
There're places where manual intervention is still required as uncrustify
is not ideal (unfortunately), but at least one may rely on it to do the
right thing most of the time (e.g. when sending in a patch).
The style itself is quite different from what we had before but making it
uniform across all the codebase is the key. I also hope that it'll make the
code more readable (YMMV) and less sensitive to further changes.
This refactoring is driven by the need to be able to do true queued RPC calls
(where each successive call uses the result of the previous).
Currently, such queueing of requests is done by assigning them special "magic"
tag numbers, which are then intercepted in one big switch() statement and acted
upon. This (aside from making code greatly unclear) effectively makes each such
queue a singleton, because state passing is restricted to global variables.
We refactor RpcClient to assign an unique tag to each remote call, and then
abstract all the call<->response matching with Qt's future/promise mechanism.
Finally, we introduce a "RPC request queue" class (RpcQueue) which is built on
top of QFutureWatcher and C++11's <functional> library. This class maintains
a queue of functions, where each function receives an RPC response, does
necessary processing, performs another call and finally returns its future.
This has a couple of benefits: 1) it is clearly visible to the user that
the list is filtered (doesn't display all the torrents) even when filter
bar is hidden, 2) doesn't lead to filter bar controls being shifted to
the left/right as when "Show:" label text changes.
Disable "Open Folder" and "Verify Local Data" actions for magnets in
Torrent menu. If more than one torrent is selected, "Verify Local Data"
is enabled but only non-magnets are verified if activated.
Add a few sanity checks when opening folder, just in case.
Split FileTree.{h,cc} and FilterBar.{h,cc} files so that each class
is in its own file.
This breaks translations (some classes got renamed => context changed),
to be fixed by next commit (along with Tx sync).
