Dreadful look on macOS Mojave with dark theme

[pshirshov]

Please check https://bugreports.qt.io/browse/QTBUG-68850

[evansan]

I haven’t tested qt 5.11, and it doesn’t look like you are using qt 5.11. I have tested the official release(qt 5.8) and another version with qt 5.9, this problem appears on both.

[pshirshov]

It's latest qbittorrent release for mac. QT 5.8.0.

Though I doubt there would be any difference for any QT version, the framework itself is buggy and at the moment they have just a dirty workaround for 5.11 which still isn't accepted (check the qt bugtracker link above)

But it's possible to mitigate the issue by setting proper stylesheets in the app.

[ThisIsJeron]

any update on this? now that Mojave is officially out...

I think the gray is a little off, should be a little bit darker

[quicoto]

The app also seems to crash with Mojave? It wasn't happening before. Not sure if it's a coincidence.

[zdlo]

The SVG icons also render low-res on retina displays on Mojave, as well as on High Sierra (as mentioned in #9549).

[Kolcha]

so, finally Qt has dark theme support! nothing must be done I compiled master branch as is (but in own way, without homebrew). and have no any issues with icons, see attached screenshots anyone can download this build here, minimum supported macOS version is 10.12.

[quicoto]

@Kolcha any idea when the new release? So we get it naturally through an update?

[zeule]

First we have to wait for the Qt 5.12 release.

[eduarcor]

so, finally Qt has dark theme support! nothing must be done I compiled master branch as is (but in own way, without homebrew). and have no any issues with icons, see attached screenshots anyone can download this build here, minimum supported macOS version is 10.12.

It definitely has some bugs, but is usable. Thanks!!

[evansan]

@Kolcha Can you upload a newer build? Thanks so much.

[Kolcha]

done , compiled from latest commit https://github.com/qbittorrent/qBittorrent/commit/1baa71c97a5313f9ab1bba5512ea56fbafae188a from master branch

[eduarcor]

Someone knows when the 5.2 will be released officially? Cheers.

[yuxincs]

Someone knows when the 5.2 will be released officially? Cheers.

In case you don't know, It was released officially yesterday (12.6)

[eduarcor]

Someone knows when the 5.2 will be released officially? Cheers.

In case you don't know, It was released officially yesterday (12.6)

Not the qt 5.12, but bittorrent 4.2... (sorry for the typo)

[thalieht]

For qBittorrent alpha is just a label for the dev branch. It doesn't mean anything special and usually all versions are just the latest commit from that branch.

[eduarcor]

I am not talking about the alpha, but the final 4.2 release. Someone knows about when the 4.2 version would be release?? Even the 4.1.4 was not release on macOS...

[evansan]

Can you give an explanation why macOS doesn't get 4.1.4? @sledgehammer999

[eduarcor]

There is no place in the whole internet where you can download qbittorrent 4.1.4 for macOS... just take a look... was not released in any place... maybe there is a compiling problem or something? I don't know... but there isn't...

[Kolcha]

qBittorrent 4.1.4 release for macOS

so, I compiled 4.1.4 for macOS . anyone can download it.

Libraries used:

• Qt 5.12.0
• boost 1.68.0
• libtorrent 1.1.11
• OpenSSL 1.1.1a

This release supports macOS dark theme. minimum supported macOS version is 10.12 (inherited from Qt).

Upd.: made some workaround to place progress bars where they must be (but draw in different style). @zdlo just re-download dmg file, link remains the same.

[eduarcor]

Thanks Kolcha, at least there is a 4.1.4 version (it definitely has some graphics glitches, I am sure for the new qt version, but is usable)... What I don't understand is why this version was not released for MacOS... Don't understand it at all.

[zdlo]

qBittorrent 4.1.4 release for macOS

Thanks, Kolcha! Is it just me who gets a progress bar on the first line of every list?

[evansan]

@Kolcha Are you considering sending a pull request for the workaround?

[Kolcha]

@evansan this workaround likely "quick and dirty hack" rather than true workaround. so it is not worth to be published as pull request, you can view patch here.

[vit9696]

@sledgehammer999 I suggest you temporarily add NSRequiresAquaSystemAppearance = NO to Info.plist file for the 4.1.x branch. This will avoid the disaster until a migration to a more recent Qt happens. Note: https://stackoverflow.com/a/52508548

@zdlo, the progress bar issue was mentioned in https://github.com/qbittorrent/qBittorrent/issues/8419. Somebody needs to investigate it and perhaps ask Qt devs to unbork their code.

[eduarcor]

@evansan this workaround likely "quick and dirty hack" rather than true workaround. so it is not worth to be published as pull request, you can view patch here.

@Kolcha To be honest, your patch is working really well, and I still haven't seen any glitches, besides that it solved the "Done" menu as well, (because I couldn't see anything, until this patch!! So, it didn't change just the bar... Just take a look and compare... with both (and with some torrents working of course). Now it is a pleasure to use it!! Thanks!! And it deserves a pull... or someone to find a way to solve it at least...

[vit9696]

I am not happy with such a workaround honestly, yet I have to admit that it does not look particularly bad.

In my opinion, we could merge it, yet guarded with Qt version being 5.11 or 5.12. Ideally that is reported upstream and researched sooner or later. Keeping this silent and having workarounds could make things much worse in the future.

[Kolcha]

I created small app which reproduce mentioned bug with progress bar and reported progress bar related bug to Qt (QTBUG-72558). So, wait until Qt devs fix it.

[sledgehammer999]

The builds are late because now I have access to a high sierra machine (previously was yosemite) and I am rebuilding the toolchain (boost, libtorrent, qt, openssl) etc...

I am aiming to use Qt 5.9.7 (part of LTS series) instead of 5.8.0. Is it supposed to have the issues with progressbars? About the dark theme: As far as I understand it, this was introduced in Mojave. And you can have support for it by using xcode 10 and the 10.14 macOS SDK and of course Qt 5.12. Qt 5.12 has support only for mojave, high sierra and sierra. Is this enough for the macOS world? Honestly I don't have a clue if people stay behind in OS versions on macOS like they do on Windows. I would be happy to provide 2 builds for each release. One with 5.9.7 and one with 5.12 to cover all bases, but 5.9.7 doesn't work with xcode 10/10.14 macOS SDK. @Kolcha is it possible to have 2 versions of xcode installed and 2 versions of the SDK installed on the same machine?

[Kolcha]

first of all, few words about old macOS versions. It is not common to stay on the same macOS version for a long time. A lot software stop working with new macOS release. software compiled for old macOS also often doesn't work on newer versions. Apple doesn't care about compatibility... I tried to stay on OS X 10.9 Mavericks so long as it possible, but in January 2018 I was forced to upgrade because even browser and player stopped to work, and it has no sense to keep such every-day-use software as browser and player outdated.

@sledgehammer999 , First of all, I'm not experienced mcOS developer, I'm just enthusiast, so I know not so much. I found no way to use 2 Xcode versions (I didn't try to do anything myself), but it is possible to use old SDK with new Xcode. I found this. I personally I tried that method for exactly the same thing as you (provide 2 builds: one with 5.9.7, another - with latest development Qt). so, try it, just follow this link. to select specific SDK during Qt build, just pass line similar to -sdk macosx10.13 to Qt configure script. to view installed SDKs run xcodebuild -showsdks

[vit9696]

You can have two Xcode versions by installing them to different names. E.g. I have Xcode-9.2.app and Xcode.app in /Applications.

Regarding dropping legacy macOS support: it makes sense with 4.2.0. But to be honest, building with two different Qt versions makes more sense to me. It is not too common to upgrade macOS on servers unlike desktops.

Regarding Qt 5.9: it has no progress bar issue, and it also has proper unified toolbar unlike 5.8.

I would strongly suggest you to implement continuous integration for macOS releases. Having to manually build every release is quite tiring. Additionally I could suggest you use VMware with several VMs.

[sledgehammer999]

Small update: I seem to have my toolchain up and running finally. I also seem to be able to have 2 Xcode installations and using Qt 5.9.7 and Qt 5.12.0 successfully with each one. I'll probably be able to make v4.1.5 releases tomorrow.

However, I don't know how to handle the 2nd flavor of macOS release. Currently the autoupdater for macOS knows of one flavor/release for that OS. If you download and run v4.1.5 build with Qt 5.12 and then I release v4.1.6 the autoupdater will point you to the flavor using Qt 5.9.7 (and not the one using Qt 5.12 or newer). In the Windows versions we differentiate between the flavors based on the bitness (32bit vs 64bit). But here on what? Should I just introduce a new compile-time switch? And name the one using latest Qt as eg qbittorrent-4.1.5-bleeding_edge.dmg?

[eduarcor]

@sledgehammer999 If I can suggest, you could differenciate macOS in 2 flavours: 1) Legacy (I guess for old macOS versions support, right? if this is the reason, which I guess) 2) New for the latest libraries (official non-beta) for the latest versions of macOS.

What do you think? This is what I am guessing that you need to have 2 flavours, if it is not... sorry, I don't know why 2 flavours then...

[vit9696]

I believe the update channel should be selected based on current macOS version. By default in 4.1.x — use 5.9, yet prepare the code:

• to update to 5.12 4.2 when it gets released on macOS 10.12+
• to update to 5.9 4.2 when it gets released on macOS < 10.12 Additionally upload a 5.12 4.1.6 that can be tested manually and reported for bugs.

[sledgehammer999]

If I can suggest, you could differenciate macOS in 2 flavours:

I think the one using Qt 5.9.7 should continue to use the current naming scheme aka qbittorrent-4.1.5.dmg. This will ensure smooth transition for everyone. The naming change should be for the flavor using latest version of Qt.

I believe the update channel should be selected based on current macOS version.

This sound good but it needs an exceptionally "smart" updater. The updater will need to know which OS version each Qt version supports. And it will break easily for older clients. Older clients can't know what future clients support. Nor do I want to lock each qbt series to specific Qt versions.

What's a good word alternative for "bleeding edge"? Maybe modern?

[eduarcor]

@vit9696, which is pretty much what I was saying, which I think "legacy" and "new" is easier than "bleeding edge" or even "modern"... but I mean, I don't care, is pretty the same

[eduarcor]

If I can suggest, you could differenciate macOS in 2 flavours:

I think the one using Qt 5.9.7 should continue to use the current naming scheme aka qbittorrent-4.1.5.dmg. This will ensure smooth transition for everyone. The naming change should be for the flavor using latest version of Qt.

I would suggest to do the inverse, I would keep qbittorrent-4.1.5.dmg for the latest stuff, if someone wants to keep the previous libraries and stay legacy, just opt for legacy and that's it, IMHO. It is more moving forward agile methodolgy adopting new libraries, and with the option of holding the previous one with legacy..., the other is just more kind of "beta" for the new libraries methodology... which I find it more messy at the end.

What's a good word alternative for "bleeding edge"? Maybe modern?

qbittorrent-4.1.5.dmg, and qbittorrent-4.1.5-legacy.dmg, should be my chosen over, qbittorrent-4.1.5.dmg, and qbittorrent-4.1.5-NEWWORDHERE.dmg

But I mean, just my humble opinion.

[vit9696]

Next time you upgrade Qt and drop more macOS releases formerly modern will become legacy. This means that modern will no longer be modern, and you would have to invent modern-legacy.

I would suggest to use macOS codename/version if you want this to be more or less automatic. If you want to keep the updater least changed, you could make it try to download by current major and pick the first one that does not return 'Not found'. I.e. on 10.13 one would:

• try to download qBittorrent-4.1.5-10.13.dmg → fails
• try to download qBittorrent-4.1.5-10.12.dmg → succeeds

On 10.12 it will succeed immediately, and on 10.14 it will succeed in one more hop (10.14, 10.13, 10.12). Make the updater only decrement till the currently supported minimum version, i.e. 10.8, and abort on failure to find a working URL with a macOS version unsupported message.

For the transitioning period, e.g. 4.1.5 on 10.9, you should upload a fallback qBittorrent-4.1.5.dmg image. Yet later on, qBittorrent-4.2.0.dmg will not be uploaded but only qBittorrent-4.2.0-10.9.dmg and qBittorrent-4.2.0-10.12.dmg be. So this someone, let's say on 10.8, will update to 4.1.5 and then switch to a new update system, which will fail to find a compatible version and report that his macOS is no longer supported.

I would personally prefer to have manifests with URLs to not have to request the server multiple times, but the suggested approach is not too bad and will be somewhat future-proof.

[eduarcor]

@vit9696 I like the approach, which makes it even more than 2 flavours proof, but seriously, it is not too much to support more than 2 flavours?? I think that having covered kind of 5 versions of macOS is a little bit too much. If someone wants to work with even older macs, just get an OLD version of qbittorrent. I understand the efforts and mess, if you want to have that fancy multi flavour aproach, but If you don't want to make things complicated, I think legacy and normal way, it is more than enough which will cover 99.99% of people. Having said that, I like your approach too.

[vit9696]

Sorry? The issue with your approach is that somewhere at 10.16 you will have to make let's say 10.12 legacy, but you will have no proper way to do it. In my case in all versions there is no need to provide more than 1 version, but it gives you an approach to provide as many of them as possible.

[sledgehammer999]

If I understand correctly @vit9696 proposes this naming scheme qbittorrent-<version>-<minOS>.dmg It could work, but it will break older updaters.

[vit9696]

Older updaters will update to 4.1.6.dmg lastly. And then the new URL is supposed to be used.

[eduarcor]

@vit9696 In my opinion, and as far as i know, legacy is when something like a library which is current (not beta) is not posible to be used in a system. In current, or near current OS, should not be a problem to adopt the library, but what you are saying is to still not mark 10.12 as legacy if it needs another libraries which are deprecated or near to be, when the time of 10.16 comes? Of course should be legacy! (and the previous versions deprecated). Otherwise, do you want to support every single version of MacOS from let’s say 10.12 when 10.19 comes? No way... having 2 versions should be work enough (as with both will easily support a range of 4 versions of MacOS) for the developers messing with diferent version libraries... or you want to end up of supporting 10 OS which no one will use and obligate to mess with legacy stuff to the developers for no reason. The less legacy the better, not several levels of legacy stuff to keep supporting... But this is just muy opinion, which is as respectful as any other. Cheers

[eduarcor]

By the way, in the content menu of the second region where the content of the download lies, there is still a problem with the horizontal scroll bar, I think that needs to be fix in wherever list are there... (versión 4.1.4 with the fix). Cheers

[Kolcha]

I recompiled release version (4.1.4) again. dropped my previous "dirty hack" which fixed progress bar in torrents list and now made some changes inside Qt instead. Now each progress bar will look like any other progress bar in macOS, but... it almost always painted as inactive... I still don't know why, I didn't find where and how Qt handles passed flags during drawing... @eduarcor , try this build.

[eduarcor]

@Kolcha, @sledgehammer999, One thing that I still don't understand, why there is not 4.1.4 MacOS version in the official qbittorrent website?? https://www.qbittorrent.org/download.php To be honest, I still don't know the reason... because is just in this platform, not others... I don't think it happened before, or at least I haven't seen...

[sledgehammer999]

One thing that I still don't understand, why there is not 4.1.4 MacOS version in the official qbittorrent website??

@eduarcor because time...

I just released 4.1.5 on macOS too. It is based on Qt 5.9.7 this time, dropping support for Mavericks. Go to the official download page. The whole ordeal of releasing 4.1.5 took me at least 5 hours (compiling is only a part of it).

Anyway, for those wanting to try I have also a 4.1.5 build based on Qt 5.12. Please tell me if it works. Word of caution: On Windows, I observed that qbittorrent with Qt 5.12 crashes randomly during application exit. This may happen on Linux/macOS too. Link to 4.1.5 with Qt 5.12: https://builds.shiki.hu/temp/qbittorrent-4.1.5-qt5.12.dmg

[Asgardsurfer]

One thing that I still don't understand, why there is not 4.1.4 MacOS version in the official qbittorrent website??

@eduarcor because time...

I just released 4.1.5 on macOS too. It is based on Qt 5.9.7 this time, dropping support for Mavericks. Go to the official download page. The whole ordeal of releasing 4.1.5 took me at least 5 hours (compiling is only a part of it).

Anyway, for those wanting to try I have also a 4.1.5 build based on Qt 5.12. Please tell me if it works. Word of caution: On Windows, I observed that qbittorrent with Qt 5.12 crashes randomly during application exit. This may happen on Linux/macOS too. Link to 4.1.5 with Qt 5.12: https://builds.shiki.hu/temp/qbittorrent-4.1.5-qt5.12.dmg

Running it right now, quits correctly, everything appears normal. Will run it for a couple days and report back. Thanks for enabling "Dark mode" in this build! ;-)

macOS 10.14.2

[eduarcor]

One thing that I still don't understand, why there is not 4.1.4 MacOS version in the official qbittorrent website??

@eduarcor because time...

Gotcha. Word of caution: On Windows, I observed that qbittorrent with Qt 5.12 crashes randomly during application exit. This may happen on Linux/macOS too. Link to 4.1.5 with Qt 5.12: https://builds.shiki.hu/temp/qbittorrent-4.1.5-qt5.12.dmg

First, just to let you know, that I have never notice, with the other Kolcha Qt 5.12 builds, any problem of crashing during app exit. Pretty sure you are doing the same in order to make the build, maybe there is something different... (just in case).

And last, sadly, It has the problem we explained above about the progress bar, which Kolcha already solved it.

By the way, maybe this is not the place, but I would like to know if it is possible to do the following: In order to minimize the time of downloading, getting the max bandwidth: 1) Is there a way to download things in a batch way?, meaning, download first one thing, then start the next one of the list in, etc... 2) Maybe should be great in combination with the following optional feature: just if there is still enough free bandwidth and is not used start with the next one in the list...

If there is still not a way, these should be 2 great features...

[eduarcor]

@Kolcha, could you please implement the fix on the 4.1.5 with qt 5.12? Cheers

[Kolcha]

@eduarcor , done, qBittorrent 4.1.5 built with Qt 5.12 and patched to fix progress bars