I have a feature suggestion: Basically it’s about integrating Arthur’s opening the same window multiple time. I don’t mean that this should be the default behavior but instead ideally there would be an option in the preferences to allow multiple add and browser windows.
When this idea was brought up in February 2021 Rumo and Damien were very sceptical because of issues with this add-on and so far it’s not popular.
I propose to reconsider this now.
I guess that today many of these problems should no longer occur because of the commit Simplify note adding and the deck/notetype choosers that was released in 2.1.45. Since then you can rely on only Arthur’s short multiple window add-on. Before that you had the problem that changing the note type in one add window affected other add windows so Arthur made another add-on named Keep model of add cards. This add-on overwrites some methods in aqt/addcards.py and aqt/model.py. This add-on was rarely updated whereas Anki changed these parts of the code a lot. This is a good source of errors. Another problem is that a few other add-ons (e.g. by me) relied on specific versions of these add-ons. This should be the main source of problems. When checking the reviews of “opening the same window multiple time” there was one from 12/10/2020 that was related to the add-on Symbols As You Type. So I doubt that having multiple browsers or add windows is inherently buggy.
I think the more relevant question is whether it’s sufficiently important to build this into Anki or if it’s just feature creep that’s best left in an add-on. I admit that the limited popularity of this add-on doesn’t help my case (though the one-sentence description on ankiweb is not very enticing). On the other hand having two add or browser dialogs should be very useful for a substantial minority of users. Multi window modes are well known on desktop so it wouldn’t make Anki more complicated (and if it did it would be much less complicated than the note-card distinction or more arcane features like e.g. the “leech threshold” or the “leech action” in the deck options or the “browser appearance” option in the card templates). On reddit people regulary post questions where a solution would be to have multiple browsers.
I think a multi window mode is different from e.g. an add-on that automatically fetches images and translations for two reasons: The multi-window mode is more basic and more general so that it’s a better candidate to be built-in and Arthur’s add-on is only ~100 lines at the moment. The option to have two windows at the same time might allow different workflows we don’t know yet.
For me having two browsers is very useful e.g. if I want to compare two notes which is something I do daily. At the moment this only works when I review a certain card that I can put with the shortcut “e” into an EditCurrent window and then I can use the browser. But when reading a professional journal sometimes I want to check if my notes need updating and since many of my notes are short a lot of topics are distributed among different notes and it’s much easier if I can see multiple related notes at the same time. (Actually one of the things I dislike most about supermemo is that you have just one window for your cards).
Having two Add windows is also useful in many cases: E.g. when processing a textbook I often copy a sentence or paragraph into an add window and then start to reduce it to something reviewable. While doing this I sometimes notice that e.g. some foreign words/technical terms need an additional card so I use another add window and only after this I get back to the first note. I could formulate my notes in a different program and only copy over the final versions or when I think that I need an additional note I could try to do it after finishing the first note but this always an additional time or mental burden. Workarounds like using another program to prepare the new notes or a clipboard manager are inferior alternatives imo.
Unfortunately my technical skills are too limited so I can’t make a mergeable solution. The only thing I can offer at the moment is helping with the German translation of the manual …
The changes in 2.1.45 related to undoing and change notification make this somewhat simpler/more robust to implement, but there are probably still things that will break because they assume only a single instance of those screens will exist. I don’t have the bandwidth to implement this, but if someone is willing to look into it, give it an appropriate amount of testing, and deal with any breakages that result from it, then I’d be happy to accept a PR.
Rather than an unbounded number of windows, 2 is probably the sensible choice, so that we can preserve the existing behaviour of those actions opening the existing window if one exists. Maybe the action could open the standard window normally, and a shift+click would open the second instance.
Anki is my note taking app, so all my study knowledge is stored there. When I want to edit an existing note, I might want to look up related info with a browser search. Here it would come in very handy to have two browser instances next to each other. I could compare notes and easily copy contents.
Additional Suggestion: Modular Views
When editing on three monitors, I sometimes feel limited by the fixed layout of the browser. With all that room, I’d prefer to have the browser table + sidebar fill out a whole screen and put the browser editor webview on a separate screen.
Big apps like Photoshop and VS Code have very nice modular systems, where you can snap views next to each other and open separate windows by dragging a view outside. With a system like that, users could easily build their perfect layout (like snap the browser-editor to the side instead of vertical to the search table).
I’m not a programmer so I can’t modify anki core components.
kleinerpirat’s additional suggestion would be perfect but it would be much more complicated than just integrating arthur’s add-on which is a pretty short add-on.
Ideally someone would do this before the main window rewrite?
Thanks for the add-on suggestions! The issue I had with “External Note Editor for the Browser” was that it doesn’t update when switching notes, while I would like to have a decoupled view that still responds to browser changes.
agree, simply allowing multiple window instances to coexist would certainly have the biggest impact. Coupled with a function to maximize/minimize parts of the browser, this would solve my use case.
Modular views are definitely more complex, but maybe we can keep something like that in mind when reworking/implementing Anki’s screens. No rush/high priority there.
I misremembered how the “External note editor for the Browser” add-on worked. I thought that it was like hgiesel’s Persistent editor but for the browser …
But it shouldn’t be too complicated to adjusted the persistent editor add-on? A browser hook like browser_did_change_row could be used to save the old note in the editor if needed and then load the note that’s in browser.editor.note?
Probably not, but it would be another add-on that has to be maintained by someone. I’d rather have such control natively. It’s not an urgent issue for me anyway, just a suggestion
I tested your add-on “Browser Maximize/Hide Table/Editor” - pretty cool! On 2.1.50+, the editor cannot be fully minimized, though. From the GIFs on AnkiWeb it seems like it has worked better on lower versions.
To be honest, I think the best solution would be something à la Emacs (similar to how terminal multiplexers — tmux — or tiling WM — i3 — work), that is:
each view (the browser, the review, the main menu, but also the left bar of the browser or every pop-up) only stores information about its content, not about its shape or about how its content is drawn (but it keeps information about the relative placement of its content);
each frame contains information about:
which view to render,
where to render it,
which shape / size to give it to.
each window (which correspond to actual windows) only knows which frame it contains, and how they are lain out.
This means that:
a view cannot assume how many time it is being rendered, as it may it be referenced by several frames (and thus it can be shown in multiple windows);
a window can be setup to display several UI parts just like the user wants them (you don’t want that bar? No problem, just remove its frame. Now you want it? Create a new frame, and make it point to that bar’s view. You want it somewhere else? Drag-and-drop its frame. Want to have multiple monitors setup? Just create one window per monitor (and partition the frames between them just like you want them).
This may seem complex, and it actually is, so it would require rewriting most of Anki’s UI from scratch, with an additional complexity layer. On the other hand:
this would be the foundation for a resilient (as I have the impression the current implementation makes quite a number of assumptions that easily break) GUI architecture, which means less pain in the long run;
this would solve most of any GUI feature request any user ever had (from my experience, a GUI never feels as seamless as when it’s just a drag-and-drop away from literally putting everything you want anywhere you want them to be).
As a downside, I have to admit that, for now, I don’t think Anki is complex enough to justify such a heavy GUI (at least, for me, the current interface is good enough and since the last editor’s upgrade, I don’t think any other update would result in a significant time gain), so I don’t think it’s worth it yet, but maybe some day it will be.
agree, simply allowing multiple window instances to coexist would certainly have the biggest impact. Coupled with a function to 