I think it looks much better than the previous design. It makes sense to have a border around the whole field, because the UI elements of that header (LabelContainer) exclusively affect that field.
Regarding the dashed bottom-border of the header, I agree - it could be omitted. This results in a cleaner look:
Maybe a darker border (between --border and --medium-border) and replacing the bottom sticky border with a background for the tag input would help reduce the clutter?
There are some power-users that would probably cringe at that thought With a lot of space occupied by add-on buttons, moving the tags and add-button etc. on top would create a very imbalanced look. I think the current bottom position of these elements looks good. Is there any specific reason why you’d want to move them above? Or did I misunderstand the suggestion?
Sure, here goes a typical example, with Qt5 the .png image (1.3 mb) is showed nearly instantly:
The same card with Qt6:
Not the end of the world and still perfectly usable, but notably slower. This does not happen with all large images, I have tried different sizes and formats and so far I have not recognised any pattern.
I’m tecnhically very limited and get a little bit lost with the info in that link, sorry. Not really sure about how can I tweak the graphic settings when using the Qt6 version, but if you let me know how can I do that I will be happy to try.
Bug: esc key while previewing a card in Browser throws this error:
Anki 2.1.50 (43c41d76) Python 3.9.7 Qt 6.2.0 PyQt 6.2.0
Platform: Mac 12.0.1
Flags: frz=True ao=False sv=3
Add-ons, last update check: 2021-12-07 20:04:33
Traceback (most recent call last):
File "aqt.progress", line 53, in handler
File "aqt.browser.previewer", line 319, in _on_close
File "aqt.browser.previewer", line 124, in _on_close
AttributeError: 'NoneType' object has no attribute 'cleanup'
Workaround: Click the exit button in top-left of preview window
Shift-started Anki, and turned off all keyboard/trackpad programs (BetterTouchTools, Karabiner Elements, Keyboard Maestro).
Thanks, I can reproduce the problem here too. 2.1.50 is using Qt 5.15, as the 5.14 version 2.1.49 uses isn’t available for our current tools. Slowdowns when loading large images were observed in the past (second point on Qt 5.15 issues · Issue #982 · ankitects/anki · GitHub). Qt 6 seems to perform even worse.
If you shrink the images down to less than 4000 pixels in either height or width as an experiment, does that make them load quickly?
Is your _Test3.png file (the one with the squares) freely distributable? If so, we can use it to report this to Qt.
Not sure it’s the right setting, but if you mean the “Cards” button below the card list in the browser and then the “Options” button and then “Browser Appearance” and “Override font”, I’ve tried changing it to an appropriate font (Antinoou), and it doesn’t change anything. Still display replacement characters instead of proper glyphs when I return to the card browser. Anyways, that option doesn’t seem like it would be the right place for a setting that would change the font used in the general card browser a few windows back.
Yes, I’ve made some experiments with different image sizes, and it seems that the problem affects only to images larger than 5000 pixels height or width. Here is the test deck, if you want to check yourself.
And yes, the squares image is just a quick doodle made with paint (but it’s nice, isn’t it ), you can use it to report the problem.
Personally, I’m adding only a few tags to my cards so I would enjoy a menu with the most used tags.
Also, most other icons are hollow (not solid) and the tag icon is filled in. This looks a bit inconsitently.
I would also remove the tags icon altogether, and, instead I would put a hint into the tag input filed (as in, text that disappears when you start typing) that reads “Tags” or “Add a tag”, or perhaps combined with the current “Tags” label, “Click to add”, or maybe a “+” button at the end of current tags that would list the most used tags.
I think that the design of the current stable is pretty good? I would remove the line that separates the buttons from the input fields as well; otherwise I like the way it looks. Oh, and I would also remove the sliiightly different background color behind the input elements. Why is it different to the background color of the window itself?
I see what you mean, but I doubt that people are actually confused by the labels. While the labels are not closer to their field than to the previous one, I just don’t see how someone could think that the labels are pointing to the field above? Is this a problem in practice?
I should also say, not putting any borders around individual field labels has been a mainstream design for, like, forever. In all apps the labels just float on top or on the left. Lately even category labels (labels that denote a group of input fields/controls) are not using borders, instead, different font sizes, typefaces and colors are used. If anything, this makes Anki look weird
The “Create copy” feature is really useful, and I’m sure a lot of people are going to love it, thanks!. Maybe, some users might be confused if they select several notes and try to create a copy of all them, so I would suggest either not allowing using that command when several notes are selected, or inform the user that only the first note will be copied in those cases.
On the other hand, the window position when in full screen is still being saved in my system, so I’m still experiencieng this issue:
This action uses the current row, which is not necessarily the first selected, or even part of the selection, if keyboard modifiers were used to create it. It’s the same behvaviour as with the card info dialog, so I wouldn’t special case it. In both cases, the opening dialog should make clear what’s happening.
That’s strange. Are you sure it’s not the invalid state saved with beta 1? If you switch off fullscreen before exiting a window (multple toggles may be required to reach a consistent state), it should be back to normal when reopening it.
I’m not sure if I’ve understood correctly then. When exiting Anki with fullscreen mode off, everyhting works OK, but if I start Anki > F11 > Exit > Start Anki again, the program start in full screen mode and the tool bar/ gear icons are not respondig, as described above. Shouldn’t this prevent Anki to start in fullscreen mode?
With that change, we refrain from saving the fullscreen state. But if an invalid state has been saved with Beta 1, it needs to be overriden with a proper state before issues will disappear.
I thought, this might be the problem. But as @dae says, we also have to take care of saveState() which is used for the main window, which I have overlooked.
Sorry for the confusion!
I noticed that I cannot use Ctrl+Shift+Alt+C to create clozes with the same cloze number anymore. Can somebody else recreate this? It seems like any additional keys after pressing Ctrl+Alt are ignored by the webview.