This allows the system to properly encode the '|', instead of passing
the '|' on in the URL, which is not allowed and breaks proxies such as
Authelia.
Then, for the purpose of generalization, I pushed this pattern through
to all places where we join items with a '|'.
This comes with the caveat that when we have individual components which
contain a '|' or any other character that is not allowed per the
HTTP standard, we still like to encode the individual components,
for example in the case of 3 strings, separated by a '|'.
If we don't do this we run into the risk that upon decoding URI finds
'|' in our original strings, which is something we don't want.
For example:
Sender:
````javascript
const arr = ["foo|1", "bar|2"];
const uri = new URI("test.html").setData(arr.join("|"));
````
Then on the receiving window, when it receives the uri and splits it, it
looks like this:
````javascript
const arr = new URI().getData('hashes').split('|');
// arr is now ["foo", "1", "bar", "2"]
````
This is why when we want to send a literal "|" we need to do
`encodeURIComponent` and `decodeURIComponent` manually on each item,
and THEN we join.
For example:
Sender:
````javascript
const arr = ["foo|1", "bar|2"];
const uri = new URI("test.html").setData(arr.map(encodeURIComponent).join("|"));
````
Receiver:
````javascript
const arr = new URI().getData('hashes').split('|').map(decodeURIComponent);
// arr is now ["foo|1", "bar|2"]
````
We don't need to with hashes as they are HEX, so no risk of any weird
characters in there.
Those strings sometimes are quite long and having a tooltip would
save the action of resizing the column width to see the full message.
The WebUI already has it done for all columns.
This also suppress the compiler warning:
src/base/bittorrent/torrentimpl.cpp:228:36: warning: comparison of integer expressions of different signedness: ‘int’ and ‘const size_t’ {aka ‘const long unsigned int’} [-Wsign-compare]
Both `lt::create_torrent` constructor and `lt::create_torrent::generate()`
can throw an exception so we need to handle it to prevent the app from crashing.
The issue was resolved by using QAction::toggled signal instead of
QAction::triggered. In QT 5.15+ the latter signal causes a QMenu
to close, whereas the former does not. Closes#13492.
AbeniMatteo