Replies: 106 comments
-
@sledgehammer999, @Chocobo1, @qbittorrent/frequent-contributors, @qbittorrent/bug-handlers, please participate. |
Beta Was this translation helpful? Give feedback.
-
QStringRef I'm thinking about how to get rid of the use of deprecated QStringRef class (we use it mainly via |
Beta Was this translation helpful? Give feedback.
-
Points to note: |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, this turned out to be even worse than I had previously assumed. Qt5 QStringView is even more flawed (in particular, it does not have any parsing methods, such as |
Beta Was this translation helpful? Give feedback.
-
I disagree with the overall approach. I think we'd be better off migrating at once, even if it takes some time. The downside is that some users would not have access to new versions for a long time (thinking mainly of Ubuntu 20.04 LTS users here). So, we should ensure at least that whatever version we're going to leave 20.04 users stuck on until next year doesn't have too many annoyances. From my own personal use, the curren versions seem OK, but I haven't looked at the issue tracker for the past 2 months so I have no idea if there are frequent issues that users are experiencing - will look into that. Regardless, assuming everything else is OK, I think it's going to boil to down to whether we want to migrate to Qt6 before or after finishing up BT v2 support. That is one of the most wanted features, and I think for many users it would be quite annoying to get stuck without v2 for another year. On the other hand, that kind of result sort of comes with the territory of using Ubuntu LTS, so.... |
Beta Was this translation helpful? Give feedback.
-
You're too radical (as always). |
Beta Was this translation helpful? Give feedback.
-
How about create a branch for v5_x_x which will focus on Qt6 & libtorrent 2.x.x? Edit: Maybe even make it |
Beta Was this translation helpful? Give feedback.
-
I wouldn't mix libtorrent2 and Qt6. Support of libtorrent2 can be implemented independently.
IIRC, Qt6 doesn't support 32-bit in either way. |
Beta Was this translation helpful? Give feedback.
-
True - my brain's a bit fried..... Doesn't support Windows 7/8//8.1 either.... |
Beta Was this translation helpful? Give feedback.
-
The solution I'm proposing is rather unprecedented, yes, but in my eyes the trade-off seems worth it. I've already looked a bit into this, and honestly it seems like it would be a giant mess to support both Qt versions at the same time - on this, we agree:
But the alternative you suggest doesn't sound like an alternative at all, just the same thing with extra steps:
For instance, we would constantly have to think about backporting patches from one branch to the other, which sounds like a massive headache. I think it's unrealistic to commit to supporting 2 versions.
But why, specifically? I think it is important for you to elaborate on that, so that I and others can understand where you're coming from. In my previous post, I reflected on the "why" and ultimately deemed acceptable that basically only Ubuntu PPA users would suffer from an unusually long upgrade wait time (>= 1 year). If you think that dropping support for Windows 7/8/8.1/some EOL macOS version is a problem... well... you already know what I think about that (even more ironic as we're about to drop support for Ubuntu 18.04)... Surely, porting to Qt6 would take at least some months, but hopefully not more than the long hiatus of last year. We are in a much better position than last year - we have better infrastructure (CI artifacts), new active members on the team, maintainership situation clarified, etc. And even if it took a lot of months - hey, it's a port to another major Qt version. Most users understand that.
This is a good point. Collaboration could be a challenge. But suppose you were one of the people at the helm of such a PR - what would you like to change to make the following easier:
I should point out that, compared to the same time last year (just as a point of comparison), there have been improvements to both of those aspects already:
Agreed, only one big change at a time. |
Beta Was this translation helpful? Give feedback.
-
are we sure to drop 32-bit support. It has over a hundred thousand downloads on Sourceforge also consider its secondary download source IMHO Qt6 doesn't provide/plan to provide anything in their widget module to worth anyone's effort for maintenance. |
Beta Was this translation helpful? Give feedback.
-
I would say yes! - we won't be moving to Qt 6.x until the end of the year, possibly even this time next year. Also looking at Sourceforge/secondary source doesn't prove that all those users are running In my opinion, it's more of a convenience thing for people to just click the first link available etc. We should look at "real-world" examples of what Windows OS Version users are using such as |
Beta Was this translation helpful? Give feedback.
-
We won't get anymore updates for Qt5 Series for about a year anyway over their corporate LTS stance. What if Qt 6.x fixes something that is broken for users?? (HiDPI etc.) |
Beta Was this translation helpful? Give feedback.
-
@glassez Since you opened a PR targetting v5, IMHO you should open a separate issue with expected goals and related discussions on the major release. |
Beta Was this translation helpful? Give feedback.
-
I'm sorry, I'm not going to do more than I do yet. My goal for now is just to add preliminary support of Qt6 (simply put, make qBittorrent build with Qt6) so that someone can start doing pre-tests. v5 means for now only that switching to Qt6 is a long-term (no ETA) plan. Although I would really increase the major number when switching to Qt6 (upgrading framework is enough reason for it). Someone can open any Issue about it if it's something to say about.
Personally, I care the least about widgets. But here are a lot of the core changes I really like. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
For license clarification see PR #14575 I made this offline before reading the new comments here. |
Beta Was this translation helpful? Give feedback.
-
This is semi-relevant for the discussion here. Now after the v4.3.4 release (and it's immediate followup), the v4_3_x branch steps into a mild freeze. Work on master now involves libtorrent 2 intergration, qt6 integration and various refactorings. It isn't a good idea to have the stable branch just copy the master branch anymore. Master is now in a volatile state. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
KDE just announced Qt 5 Patch Collection which will maintain patch set for QT 5.15 until the switch to QT 6. Archlinux has already switched to the KDE branch. For reference. https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection |
Beta Was this translation helpful? Give feedback.
-
Folks, Qt 5.15.3 has actually been released as open source now, so I think it would be great if you could rebase upon it: https://raymii.org/s/blog/Qt_5.15.3_OpenSource_released.html Sorry if it's a wrong thread. |
Beta Was this translation helpful? Give feedback.
-
@Sin2x Thank you, we are already aware of it -> #16733 (comment) |
Beta Was this translation helpful? Give feedback.
-
I believe that the transition to Qt6 will not be instantaneous and we will need to support both Qt5 and Qt6 for some time. So I suggest discussing here the main incompatibilities between Qt5 and Qt6, as well as the steps we should take to add initial support for Qt6.
I suggest that we start preparing the codebase by cleaning up the use of deprecated features, for which there are replacements in Qt5. Unfortunately, many of them are deprecated in later Qt5 versions (5.14 and 5.15), so we will still have to add a lot of conditional code (since we will not be able to abandon the use of earlier Qt5 versions so quickly).
Beta Was this translation helpful? Give feedback.
All reactions