Conversation
a523111 to
eeb35c0
Compare
|
Yay! 👏
Hmm, I was thinking there might be something in the autoselect logic to only auto-switch to Qt6 on 6.5.2+, do you think there is any need for that? |
|
Welp, I just noticed some of For the latter, I think we can safely use For the former, I'll need to experiment some more, because those scripts are sometimes useful outside of qutebrowser too. But I suppose having a qutebrowser installed would still be a safe assumption. Should hopefully have time to get to this before this can be merged anyways. |
I thought about it, but I'm somewhat lukewarm about it. I'm really not sure what happens exactly when you mix Qt 5 and Qt 6 in the same process. It might be fine when not creating a But when doing this, we'd be forced to import Qt 6, then find out it's actually not good, and then import Qt 5 instead. Since I have a workaround for #7732 now (which was probably the most important issue, all the rest is annoying but not a crash), I decided to not bother with it. I'm assuming once 6.5.2 is out, people are not usually going to use 6.5.0/.1 anyways. If I need to revert that workaround (#7753 possibly...), that might be worth another thought. |
I don't have the whole situation in my head atm but when I was looking at #7128 I had the thought that just upgrading them to Qt6 and not worrying about Qt5 compatibility would be fine. I guess the downside of that would be any distros that package the new release and don't have Qt6 available. I'm not sure how common that scenario is and how much effort we should put into polishing all the rough edges for it. |
28beeca to
6d0fd03
Compare
Only mypy missing now...
Closes #7742
Using qutebrowser.qt where we import from qutebrowser already anyways
This used to be possible in some situations and was handled in somewhat unexpected places (e.g. .to_qt()). Instead, we now assume that KeyInfo is always "clean", and we handle the conversion from an int to a Qt.Key elsewhere. This only seems to affect tests, since otherwise we already made sure we get a Qt.Key and Qt.KeyboardModifier(s) e.g. in .from_event().
6d0fd03 to
4e67a17
Compare
QUTE_QT_WRAPPER, so that PyQt6 is preferred, and we fall back to PyQt5 if it is unavailable_DEFAULT_WRAPPERinmachinery.pywith a_WRAPPER_OVERRIDE(cc @ionenwks)...-qt5is the Qt 5 variant, and no suffix is Qt 6Will be merged once Qt 6.5.2 is out due to various regressions in Qt 6.5.1. That's planned to happen on Wednesday. With a few days until Archlinux/
Gentoohave updated their Qt packages hopefully, I'm aiming to merge this in early July.As for distributions:
The unstable-qt6 docker environment fails because the image isn't pushed yet. Will need merge to master first, as it gets only pushed there.
Closes #7202 (finally!).