very likely this will be also pretty easy to fixįor some reason the percentage text is behind of the progress bar, until it reaches 100%.Īs far as I seen this isn't exclusive to the main window (aka the torrent list), but occurs even with the content window too (aka files list), so it's a reasonable assumption, that every progress bar is affected by this bug.Īs far as I know, it's a specific bug with macOS and Qt 6, this isn't an issue with any other platform or with Qt 5. So, please give some details where to look and for what. also, if bug is reproducible on any other apps, patch can be submitted to Qt (I did this already, so know that's possible). this should not be a problem, because Qt is compiled from sources, so it can be patched before compilation. So, new issue with progress bar is not completely new to me, but the fix/workaround may require the changes inside Qt itself. long time ago I made changes in Qt to fix progress bar displaying torrent progress download misplacement. moreover, I'm familiar with Qt' codebase, and in this particular case with code corresponding to progress bar painting. I can find interesting parts in code pretty quickly regardless of codebase size (consider such huge project like Android for example). What is the issue you are talking about? is it mac-specific or cross-platform? maybe I can fix it. However unfortunately the issue with the progress bar still exists and since I'm not familiar with Qt and the project source itself, I have no idea why. So, wait for updates, very likely native Apple Silicon builds will be officially available with next qBittorrent release :)ĭoesn't work on M1 Big Sur. cross-compiling manual will appear later, I have to solve few more issues to make this process smooth and easy to automate. in few days I'll publish at least guide describing all tricks used to make build possible on native M1. So, now I see the "whole picture" and have some thoughts what to do next, and the end is near. the same code will be tried to be compiled for each architecture, and this doomed to fail (tested with Qt, I even didn't thought that it so much depend on certain CPU instructions). so in such cases as Qt (and moreover OpenSSL) it is unacceptable, because their code rely on specific CPU instructions which are completely different for x86_64 and arm64, and code doesn't not have platform-dependent switches, decisions what to use are made only on "configure" stage, i.e. only if code is really cross-platform (i.e. such kind of binaries are extremely easy to build, but. this is unusual.Īlso I would like to add few words about so-called "universal (or fat) binaries". my experience with Qt 4.8 compilation using MSVC 2017 and a lot of experience in cross-compiling on Linux helped me a lot here :) but process is still different from usual cross-compilation, because you are using the same compiler. Some tricks were also required to cross-compile Qt to M1, there is NO any presets/configurations/options for that, but in general Qt is ready for it. arm64), and it is can't be compiled for host (I tried, but no luck, very likely there is must be the reason for it). and there are some good news - I got arm64 qBittorrent executable on my x86_64 host!īut there is one very inconvenient thing - Qt' very convinient tool called macdeployqt is only for target architecture (i.e. I'll share all my work later, when I find the way to build Qt' arm64 binaries on x86 host (anything else I think should not cause serious issues), but this looks like even harder challenge that compiling Qt 4.8 with VisualStudio 2017 (especially when I'm even not experienced Windows user.) that I did few years ago.įinally, I had some free time when I was not so tired. in all other things I was almost sure that it will not cause any build issues (thanks to my work experience.) Moreover, only one thing I concerned was OpenSSL (due to its uncommon and maybe unique own build system), but seems it is already ready for M1, its build script even had some preset something like darwin20-arm64 (approximate name, don't remember). also I see no reasons to concern about Qt, because it supports arm64 architecture for a long time (at least because it is available for Android and Yocto Linux which is popular across different embedded systems, mostly ARM-based). and that change was caused by very unexpected thing - I got x86 Qt' binaries (moc was among them)! and system complained that something can't be executed (because I don't have Rosetta (I must have clean environment)Īfter that change build process went fine. Even 5.12.x works :) but not exactly "out of the box" :)Īll I did that changed only one line in some Qt' mkspecs file.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |