* 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>
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.
Manuskript now logs the versions of modules and libraries powering them
for as far those are easily accessible. This includes all the optional
modules, too. None of this is visible on the terminal of course - unless
Manuskript is run with the --verbose flag. This clears up the last bit
of unnecessary console spam, leaving our users blissfully unaware.
Until we (and/or Qt) break something again, that is...
Sometimes you want to do just one thing, and in the process of
implementing that one thing, you implement several others. This is one
of those types of commits.
Implementing the argparse library is for the sake of controlling the
logging behaviour as well as other future I have yet to implement.
It has all the standard goodies you'd expect, and I have also ported
over the existing commandline arguments. (They may need a bit of polish
still, but there is no regression compared to before, only improvement.)
The logger is because it really needed to happen for numerous reasons.
It still logs to the terminal, but by default it only does so for
messages classified WARNING and above. These are the things we actively
want users to see. But if this is not good enough, adding the --verbose
flag will increasingly show more (-v shows INFO level and -vv also shows
the DEBUG messages) so that us coders don't have to miss anything in the
most convenient location.
It also logs to a file with the very original filename manuskript.log. I
may have to add commandline and/or settings arguments to improve that at
some point in the future, but there distractions are endless.
The log file contains timestamps and module information for easy
interpretation that are not present on the terminal, and it contains all
messages classified DEBUG and up. Ideally users will just be able to
attach it to an issue(*) to deliver us all the information we need to
help them with their inquiry.
Last but not least, the other reason I needed logging implemented is
that Qt has its own logging framework, and I needed to figure out how to
siphon out the data and make it shut up. But there was no point in doing
that as long as our own logging facilities were lacking...
(*) I have yet to convert all existing print statements over to the new
system, but that is probably going to be the next commit. This one has
enough change in it already.
