-Cleaned the code up a bit.
-Added warning message before discarding unapplied entries in the bulk manager. The bulk manager now doesn't automatically close when selecting a single (or no) character, but asks for the user's consent.
-Since multi-selection of characters is now possible, it's more intuitive that all selected characters should be deleted.
-Added a confirmation dialog before character-deletion? Why the heck was this not a thing before? It was way too easy to accidentally delete characters, with no way to restore them without external source-control or backups.
Also, a change has been made to the character tree view. Theoretically it shouldn't have any functional significance, but "addCharacterInfo" is used for adding info to only one character, so it makes sense to remove the old multi-selection info-adding functionality, even if it wouldn't ever be accessible.
-Some variables had to be declared in the mainWindow.py __init__ function.
-Added functions for creating the bulkPersoInfoManager widget as a tab when multiple characters are selected. All other tabs get stored and deleted, and restored after only one character is selected.
-Started work on functions that create the intended behaviours of the widget.
-Added currentCharacters method, a list counterpart of currentCharacter.
-Replaced the connection for currentItemChanged with itemSelectionChanged. This is to accommodate for the bulk-changes when multiple characters are selected. The currentItemChanged method is now not called with a connection, but from the handleCharacterSelectionChanged method. The latter is called with the itemSelectionChanged connection.
-If no valid characters are selected, the tabPersos widget is disabled. This obviously breaks the functionality of bulk-adding info to characters. This will have to be fixed by only disabling the parts of the tabPersos widget that should not be affected with multiple selection operations.
* 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>
Some snippets have yet to be converted due to the more complex nature
of those snippets, and to keep things neat a separate commit makes more
sense for those.
When creating a new character, sets an appropriate importance level.
* If a character is selected, the new character has the same importance level.
* If a top-level importance level is selected, the new character has that level
* Otherwise, the importance level is zero
Two separate pull requests indicate an issue translating the warning
for when an import is attempted with PyQt/Qt versions 5.11 and 5.12.
As such change the warning message.
See PRs #668 and #701.
See issue #611 and pull request #642.
The warning previously added in PR #612 for Manuskript users with Qt
5.11 / 5.12 has shown itself, in my opinion, to be overly annoying.
This is because the warning *always* displays on systems with the
affected Qt versions even though the crash is verified to happen with
the import feature only.
Additionally the process to upgrade to a newer version of PyQt / Qt is
not trivial for users who rely on pre-built packages and do not run
from source code.
Because the crash has been verified with the Import feature only, limit
the scope of the warning to the Import feature.
See PR #615
The Travis CI tests began failing after merging Pull Request #583.
Log snippet:
----------------------------------------------------------------------
...
Ref not implemented
PASSED
manuskript/tests/ui/test_welcome.py::test_autoLoad QXcbConnection: XCB error: 8 (BadMatch), sequence: 613, resource id: 2097162, major code: 42 (SetInputFocus), minor code: 0
QXcbConnection: XCB error: 8 (BadMatch), sequence: 619, resource id: 2097168, major code: 42 (SetInputFocus), minor code: 0
QXcbConnection: XCB error: 8 (BadMatch), sequence: 625, resource id: 2097171, major code: 42 (SetInputFocus), minor code: 0
----------------------------------------------------------------------
When running "pytest -vs" locally, which is a command used in our
.travis.yml file, a dialog to "Save project?" is displayed. Because
the test scripts use the "saveOnQuit" default setting of *enabled*,
the "Save project?" dialog should not be displayed.
In other words when a call is made to close the project, a "Save
project?" dialog is incorrectly displayed because the dirtyProject
flag is set, but so too is saveOnQuit set to True. What should happen
is an automatic save with no prompt. This PR fixes this logic so that
the Travis CI test suite completes successfully.
Turning off the timer for saveTimerNoChanges just like the code
already did in closeProject() for saveTimer fixes this bug. Easy.
But how to prevent this kind of race condition in the future?
Several related routines have been adjusted to fail gracefully or report
a bug to the console when something goes wrong, depending on what is
most suitable for that bit of logic.
Intending to learn more about the way Manuskript goes about saving the
project in order to figure out how to tackle some recent saving-related
issues, I stumbled into learning that Manuskript likes to save data a
whole lot. Too much, in fact. When I close the project with unsaved
changes, I expected those changes to not be saved... but they were. This
completely subverts my expectations of a program using typical
file-based operations involving opening, saving and closing files.
There are three more settings that influence when the program saves, and
I personally consider them a bit overkill or even detrimental to the
stated purpose. What if Manuskript forces a save when nothing was
changed and something goes wrong? Saving too much can in fact be
dangerous!
For now, I have left existing functionality as-is, but I would prefer to
respect the dirty flag I have introduced in this commit for at least the
'save-on-quit' and 'save every X minutes' features. (The third is
smarter and only triggers after noticing changes, so it is less
important.)
Making sure the dirty flag works as expected is the first step in making
such changes in the future.
UI-wise, this commit now offers the user the opportunity to save their
changes, discard them, or outright cancel their action entirely when
performing a destructive action on a dirty project. As of this commit, I
have identified two of such scenarios:
1) closing the project,
2) closing the window with save-on-quit turned off.
If I missed any, do let me know. But for now, maybe now I can finally
start digging into those issues that sent me down this rabbit hole...
The About/Settings/Import/Export/ExportManager windows were all created
in odd places, usually to the left of the main window, which meant outside the
desktop area with little overlap if the main window is maximized. The logic in
centering the window on its parent was wrong. This fixes it.
Add support for 6.3.8 which has delete_dictionary_entry and do not use gzipped
pickle. Also give higher priority to symspellpy vs pyspellchecker.
List symspellpy dictionaries by order of cached vs non-cached.
symspellpy 6.3.8 is now the minimum version required and add support for showing
that information to the user.
Also add support for spellcheck libraries that are installed but without dicts.
This modifies the Spellchecker abstraction to add a new dictionary support, with
support for pyspellchecker. It also changes the main UI so that multiple libraries
can be supported and dictionaries provided to the user. The custom dictionary of
pyspellchecker has to be handled manually, and the performance and words of this
library isn't on par with PyEnchant, but at least it works with 64 bits.
Fixes#505
This is in preparation for adding support for additional spellchecking libraries
other than PyEnchant which seems to be unmaintained and does not build in
Windows 64 bit.
The menu option "View -> Mode -> Snowflake" has not been implemented.
This greyed out / disabled option has caused some confusion for users.
Remove the snowflake menu option to avoid confusion.
Closes issue #419
See also earlier issue #45
The root cause was a mismatch between plot IDs and plot model rows.
This issue would appear when a plot was deleted such that the plot IDs
did not match the plot model row numbers and different plots had
different importance levels. The problem would not occur if the most
recently added plot was deleted.
The plot ID / plot model row mismatch was introduced with the
following commit:
Fixes: add plot then choose new plot does not set \
importance slider
3569f78928
Closes issue #404
