Revalidate the date upon every change, and disable
OKing the dialog when it is not valid, for usability review.
If it is not good, we can always revert this commit.
when Date.set throws during the date fields sanity
check validation, it now attaches an (undocumented) .date field
to the exception -- proof of concept for 7198 and potentially
for 7212 as well
Improve user experience as promised in [98d8e6].
Now, if one clicks OK in the date editor and the date is invalid,
it's switched into text mode and the dialog remains open,
so the user can either correct the date or type it as text,
no more loss of entered data happens.
Now it just autoconverts into MOD_TEXT and returns whatever
text was there. This fixes the crash on the master branch,
but is not the final user experience yet.
Attempt to fix the failing
DateHandlerTest.test_invalid_month_with_ny
(see 7197:32625). Tests still fail, investigation shows
there's a problem in Date.set setting Julian+Mar25 date even if the
date validation check is disabled by inserting a return before
the validation block, i.e., before this line
if modifier != Date.MOD_TEXTONLY:
which seems to be the root cause of the remaining failing tests.
To investigate, add the return and try
LC_ALL=en_GB.utf8 LANG=en_GB.utf8 GRAMPS_RESOURCES=$PWD \
python -m unittest -v \
gramps.gen.lib.test.date_test.MatchDateTest.test_match
It's actually on both PPC and Intel, and it's from forgetting to update
gramps.accel after upgrading Gtk past 2.24.10, which changed the mapping
of alt/option from Mod5 to Mod1.
For gramps40 and master, the problem was masked by the bundler putting
the file in the wrong directory.
Convert old markup to reStructuredText.
Use warning and todo directives where appropriate.
Add some new links to classes and methods.
Use consistent case for "Gramps".
