We can no longer save valid torrent files in the general case, because
for torrents of version 2, we need a full merkle tree to do it, but if
a torrent is added from magnet link, full merkle tree may not be available
even before the end of downloading all the data. Actually, we don't need
the full torrent file for the purposes of resuming the torrent, so we can
allow libtorrent to produce only a minimal part of the metadata as part
complete resume data, but we still want to store it in a separate file,
so we extract the resulting metadata from the complete resume data before
saving and merge it together before loading.
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.
- warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
Caused by mismatch between size_type of std and Qt containers. It is safe to cast to int as all of those containers hold low number of objects.
When restoring from tray icon, although the window manager shows qbt
window but qbt itself didn't handle the event correctly, i.e. the
`show()` was missing and thus qbt did nothing and the window is blank.
Note that at this point the `visible` property is `false`.
After invoking `show()` qbt will start showing the contents and also
fire another showEvent where `visible` property is `true` and here is where
qbt should handle preparations for the window.
Fix#9510.
AbeniMatteo