Same logic than in last commit. Actually, there is no change of model
which need a full sync until the model is uploaded. After all, even if
a change in model imply that some card will change, those cards and
notes have not been uploaded either
This commit solves a problem that I had many time in the past. When I
create a new model, I usually want to edit it. Clone of existing
models present no interest by themselves. And as soon as I edit it, I
need to do a full sync.
As far as I understand ankiweb (which is sadly closed source), the
full sync is required because ankiweb needs to know that the model
associated to note type on the server did change. But since the model
is new, it has no note type associated to on the server, so there is
no need to do a full sync immediatly. Since the model is new, it also
means there is no risk of the inconsistency with a change made in
another computer/smartphone.
Thus, when a field/template is added, I check that the model is not
new by checking both whether it's id is not null, and also that it's
usn is not -1. (I set usn early in the model's life)
If it does not make into anki, then it'll be an add-on. But it's worth
a try first.
There is currently what I believe to be a small bug in anki. You can
clone a note type without doing a full sync, but you can't create
forwardReverse and forwardOptionalReverse note type without doing a
full sync. On the other hand you can clone, and even create any other
basic type without doing a full sync.
This commit simply wants to correct this.
The main trouble is that the method to create a copy of forwardReverse
and forwardOptionalReverse use a copy of the basic model, and add this
copy in the model manager BEFORE adding yet another template. This
commit corrects it by ensuring that the model is added only after all
templates are added, so that anki does not detect any change of a
template in the schema.
In order to do this, I created a method newBasicModel which creates
the basic model without adding it.
By the way, addBasicTypingModel could also use newBasicModel, and then
only change afmt. I didn't do it here because I believe that you want
the change to be minimal, and this correction would not add any
feature, only factorize the code.
Here is a bug, how to reproduce it, and why this is a fix.
This is a way to create a new note with a due card extremly high
without any add-on, just with basic anki.
Bug
===
Create a note type with three fields One, Two, and Three and three card
type One, Two and Three such that each card is generated when the
field of the same name is filled.
Create a note with fields One and Two filled only. Review card One and
click on good. Card one should goes in learning mode. Fill the field
Three. In the browser, you'll see that card Two and Three are new, but
card Two and Three's due value are distinct. More precisely, the due
value of card Three is equal to the due value of card One; except that
in card One it's interpreted as a timestamp, while in card Three it's
interpreted as a position in the list of new card.
You'll remark by the way that the due of card Three is extremly high,
potentially more than 1000000; which may explain why so many
collection has this bug.
Fix
===
Only consider due value of new cards.
In some systems, the default Qt hardware renderer is buggy. There's a Qt
option for forcing software rendering. This commit adds support for a
new environment variable, ANKI_SOFTWAREOPENGL, that, when set, will
prompt Anki to force software OpenGL in Qt.
