* Changed default logging behaviour
We now log by default to a timestamped file in $datadir/logs/. No longer
shall restarting Manuskript after a crash wipe a very useful logfile.
Logs older than 35 days in the $datadir/logs/ directory are pruned
during startup. In case of subtle corruption detected a few weeks after
the fact, relevant logs might still exist to explain what had happened...
yet it does not come at the cost of infinitely gobbling up a users
storage space, either.
The --logfile (-L) argument can now utilize strftime() specifiers. A
special modifier %# is also supported which will insert the process id.
Besides being an added factor of uniqueness for a filename, it can also
be relevant to help identify the log file belonging to a misbehaving
Manuskript process.
* Added support-related items to Help menu
The 'Technical Support' item should lead to a landing page that will
guide the user to the most efficient way to resolve their problem.
How to report bugs and submit logs would be one of those.
The 'Locate Log File' item should open a file manager window with the
logfile of this session highlighted. Because Manuskript is still writing
to it, we first remind them of its limited use until Manuskript is
closed.
This approach was chosen because users might want to locate the file
prior to reproducing a bug, or because they'd like to look at other logs
from previous sessions.
* Updated translation files and added german translation
Co-authored-by: TheJackiMonster <thejackimonster@gmail.com>
* Fixed pandoc command arguments
`--base-header-level` throws a new export error because it is deprecated, now we should use `--shift-heading-level-by`
* Adjusted default and min value for base-header
Co-authored-by: Tobias Frisch <thejackimonster@gmail.com>
Due to my struggles reproducing the official build, I felt it might be
useful to log extra information regarding the version of PyInstaller.
Unfortunately, such information is not available due to the way things
work. However, during that process I came across some other interesting
details that would likely be useful when logged.
When implementing most of the logging code weeks ago, I got so caught up
in implementing and testing the Qt bits that I completely blanked on
actually implementing the Python-side of catching exceptions.
Unfortunately, it is not exactly trivial. PyQt complicates things, but
also Python itself isn't very helpful in older versions which will rob
the ability to properly log errors from threads. By the time I realized
we don't actually use the threading module and that catching the errors
on there does not actually help to fix the weirdness I was seeing, it
was already implemented. Thank you PyQt for surprising me yet again! :-)
I have tested this on Python 3.7 by raising random exceptions in various
parts of the codebase to make sure it behaves as expected. I haven't
quite gotten around to installing Python 3.8 yet but this gets it out
for testing. I'll hopefully not forget to do more tests in 3.8 when I do
the final squashing prior to a merge.
Some log messages use characters in the Unicode character set that
aren't typically represented in the older encodings. One such example
was the messages that happen when renaming an item and saving the
project.
Positive note though: errors while logging might not end up in the log
file when the log file is the cause, but they still showed on the
terminal with excessive detail. Also, despite the exceptions and errors,
the project I was testing successfully completed its saving procedures
as a subsequent reload showed. I am personally quite happy with the
degree of thought and care put into the Python logging system. :-)
During development, the version number does not have much meaning... but
when faced with a reported issue, you would still like to know in more
detail what version of the Manuskript code was at work there.
Knowing the exact git revision will hopefully make it easier to
troubleshoot such issues in the future.
Note: this code takes special care to not rely on external modules
(we have enough dependencies) or even the git executable (invoking a
program can be relatively slow on some operating systems). It might not
handle all the edge cases, but I think it should cover our needs well
enough.