I need to sleep now, but your concerns have been heard and I will do my best to fix the widget issues mentioned above. I’m interested to hear additional opinions on this and perhaps Damien and Henrik can tell you why they decided to move towards webviews.
This is what Damien had to say in 2021:
Qt’s Chromium port seems to choke on every second video driver on Windows, and they recently dropped LTS releases for open source users, and don’t have a new release with WebEngine support planned until something like September. The LTS changes were likely motivated by money issues, and it makes me worry about their long term viability.
While we likely won’t be able to move away from Qt any time soon, there may come a day that we need/want to, and if at that point the bulk of the UI code is implemented in TS/HTML, we’ll have options like switching to Electron or a native webview.
Aside from Qt’s future, I think in the long term it will just make things easier as well - driving the UI with Python and having to send asynchronous messages back and forth to the various webviews is needlessly complicated.
Thank you! If I find other issues, I will post them here.
Qt’s Chromium port seems to choke on every second video driver on Windows, and they recently dropped LTS releases for open source users, and don’t have a new release with WebEngine support planned until something like September. The LTS changes were likely motivated by money issues, and it makes me worry about their long term viability.
I understand the concern. Not sure but I believe it’s not valid anymore since it’s almost 2023 already (webengine 6.4 has been released this month), but if the WebEngine issue arises again some time in the future, wouldn’t it be better to move to GTK instead? Seems more natural than using html/css/js that work poorly in desktop applications. GTK has its own webview.
One possibility to fix the table issue is to make the styles specific to the QTableView with id #tableView, the one used in the browser. The stylesheet looks buggy on other tables, because the styles are targeted specifically at the one in the browser, which has some unique requirements.
The alignment and background color issues would be fixed:
QPushButton should still be styled globally in my opinion, but we could target the border styles specifically to buttons that do not have the flat property, e.g. QPushButton[flat="false"]. Then you could just make the buttons in your add-on flat to indicate they’re meant to be used inside table cells, which already have a border.
Example:
table = QTableWidget(5, 2)
for i in range(5):
table.setItem(i, 0, QTableWidgetItem("Sample Word"))
button = QPushButton("Flat Button")
# Make the button flat, i.e. omit border styles
button.setFlat(True)
table.setCellWidget(i, 1, button)
Why not apply the styles directly to the Browser QTableWidget?
This would require more logic, because the stylesheets should not be applied on macOS by default and we’re allowing users to force the custom styles with a flag.
Regarding user Qt/GTK themes
We should be able to offer Linux users the option to use their system theme the same way we’re allowing macOS users to force our custom stylesheets, so I think it will be easy to implement.
In my opinion, the new Anki version looks absolutely great and I would definitely not revert it. The previous versions looked a bit outdated, now Anki has a much more modern and fresh look. I definitely prefer it. If there are issues with certain components, like the tables mentioned here, of course those would need to be fixed. But in general, I definitely think it is Anki’s job to style itself. This may just be a different philosophy when it comes to apps, but I don’t think there’s anything wrong with an app having its own distinctive style.
On what systems? Before 2.1.55 the users were able to have Anki respect their GTK or Qt theme, so there was little difference between how Anki looked and how other programs looked on their systems. Now this functionality is broken for some reason. I haven’t found a way to fix it yet. Tried removing default styles, it didn’t help, but it fixed unusable widgets so that’s something.
The new style just forces Anki to look like a weird macos app or something.
It looks very foreign, as if it was slapped on top. Compared to what we had previously, it has grown noticeably taller, and that’s not a good thing, especially for smaller screens. There’s also a gap between the end of the shadow and the upper edge of the card when reviewing.
It could be moved somewhere else. For example to the very top where all the Qmenus are.
Or it could simply be shrunk vertically, with the shadow and background-color removed. Personally I didn’t mind the way it was in all older versions.
I think it would be cool if there was an option for addon developers to tell Anki not to apply any styling to their widgets, e.g. call something like this inside addon code:
I don’t see much in the way of improvement. Someone posted another webengine-related crash less than 24 hours ago, and we can’t even use the current 6.4 release on Mac or Windows at the moment due to regressions.
You appear to be approaching this from a Linux-centric perspective, when we have the rest of the ecosystem to consider as well. 97% of Anki’s desktop userbase is on Windows/Mac, and GTK is generally considered to be inferior to Qt on those platforms.
There are also the mobile platforms to consider, with AnkiDroid accounting for a sizable portion of the userbase these days. Our traditional model has required them to port code and UI over to Android, and it’s led to them falling quite behind, and stalling adoption of newer functionality like the v3 scheduler. By sharing parts of the codebase and shifting parts of the UI to HTML, it will reduce duplicated effort, and allow us to make better use of the limited developer resources we have.
I don’t see much in the way of improvement. Someone posted another webengine-related crash less than 24 hours ago, and we can’t even use the current 6.4 release on Mac or Windows at the moment due to regressions.
On Android they use Android SystemWebView. It crashes all the time too, and they said it’s unfixable. For example, if a card template contains @font-face css with local files, Ankidroid crashes every N reps, and it also causes each card to load slower. So it has problems as well.
You appear to be approaching this from a Linux-centric perspective, when we have the rest of the ecosystem to consider as well.
I’m not using other operating systems, so I can only talk for my user experience. This time there’s a number of regressions on the OS I’m using (GNU). I’m not saying to ignore other OSes if there are still people who use them.
The broken parts of the UI could be fixed by changing their default styles. For example, the notch could be moved or made smaller. The scrollbar could be made rectangular instead of pill-shaped.
Interference between addon code and anki code could be fixed by allowing addon code to disable or overwrite default styles (without affecting default widgets).
The user’s GTK theme should overwrite default styles as it was in 2.1.54 and earlier.
97% of Anki’s desktop userbase is on Windows/Mac, and GTK is generally considered to be inferior to Qt on those platforms.
It seems there are many cross-platform GTK apps. Gimp, Firefox, etc. Though moving Anki to GTK probably means rewriting everything so it’s unlikely to work out.
There are also the mobile platforms to consider, with AnkiDroid accounting for a sizable portion of the userbase these days. Our traditional model has required them to port code and UI over to Android, and it’s led to them falling quite behind, and stalling adoption of newer functionality like the v3 scheduler. By sharing parts of the codebase and shifting parts of the UI to HTML, it will reduce duplicated effort, and allow us to make better use of the limited developer resources we have.
AnkiDroid is unlikely to benefit from the move away from Qt widgets because it is almost entirely written in Kotlin, but the desktop Anki doesn’t have any Kotlin code.
However, Qt apps can be run on Android. For example, Okular or Neochat.
This might make it into 2.1.56. In a later release the separate webviews for the top and bottom toolbars will be removed and everything will be contained in a single, main webview. Then it will be much easier to customize their orientation and style of such toolbars.
Having an option to hide the toolbar is nice, but that’s a different thing. Addons sometimes print information on the toolbar. The users will have to choose to keep the toolbar always visible. So the regression in question is not addressed.
I propose that the styling is altered so that the toolbar is smaller by default. If I figure out how to do that, I’ll submit a patch.
I don’t think things like the scrollbar of the toolbar look broken at all, to be honest. It’s just a different style? Personally I definitely prefer it over the previous look.
Or they could just stop breaking everything all the time, instead focusing on stability.
The issues in this thread in particular are easy to fix with a few PRs. Would be even better if they were never introduced.
I felt motivated by @MIZMU’s comment to work on some fixes this evening. But when I read a commanding comment like yours after a full day of work, I rather do something more relaxing instead.
Please do not generalize. “They” is me in this release, as I’m the only one who introduced breakages. Other contributors are not at fault here.
You can stay on 2.1.54 as long as you feel it’s superior to the newer versions. 2.1.55 is not forced upon anyone, in fact 2.1.54 is still the first download that shows up on AnkiWeb. There’s no duty for Damien or any of the contributors to deliver a bug-free release. Neither do we need to follow any quality standards or obey the ideas of add-on authors. Work on a project like this is fueled by the intrinsic motivation of its contributors.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
No motivation is needed to change 3 lines of css. From what I have found, the regression has to do with styles applied to .tdcenter and .hitem.
Currently I don’t know why GTK themes are not applied anymore, but I hope to find why.
I would stay on 2.1.24, but I have to take into account previous bugs that were fixed afterwards, the users of Ajatt-Tools who use a variety of different OSes and Anki versions, and other add-ons that I might want to use myself.
I observe lots of frustration with Anki after maybe 2.1.35. Personally I tend to be rather forgiving in this regard. I can fix the addons that would break after an update in a short period of time, whilst other people sometimes can’t put up with “upgrades” anymore.
2.1.55 is the product of a lot of time and effort over 6 months by multiple developers, and every change is an attempt at making Anki better. We don’t always get the calls right, and sometimes there are unintended breakages along the way, but we’re doing our best, and trying to move Anki in a positive direction. By all means bring regressions to our attention (preferably during the alpha/beta testing period!), but please be more respectful of the effort that we’ve put in and the problems we’re trying to solve, as the tone of your posts does not really motivate us to engage with you.
Is there any text above or below that which might hint at the cause?
