* If you accidentally try to add a lot of duplicates -- for example, by
starting up with a lot of duplicate torrents in the watchdir -- then
coalesce all of them into a single error dialog instead of spamming
the desktop with a different dialog for every duplicate.
* Make the duplicate torrent dialog's error message slightly terser to
make it accommodate a long list of torrents: omit the ".torrent" file
suffixes and show an abbreviated form of the existing torrent's hash.
* Support searching by torrent hash in the filterbar's text entry.
This is useful when copy/pasting the hash from the duplicate torrent
error dialog and is also consistent with the GTK client behavior.
* Copy the GTK client's behavior of appending ".added" to the end of
.torrent files after they've been added to the session.
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.
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).
Charles Kerr