textColor isn't always set to a value and whenever it was used as an empty variable the program would crash. I'm uncertain as to whether or not this solution is appropriate, but this is one way to handle it and maintain functionality. Another would be setting textColor to a default value, but this default would have to depend on the theme set by the user.
-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.
-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 the selection mode to extended selection on the lstCharacters tree-view. This will not affect anything else other than the "detailed info" rows. Every other change to a character's descriptions, motivations and such only affect the last selected one.
-Made a method to get all the IDs of the selected characters.
-Added a character-info dialog UI. Originally, adding information worked by adding a placeholder and then changing it. Users never want to just add a placeholder without initialising the values. And the bulk-adding only works this way.
A long time ago, I identified this failure but wasn't sure why it was
failing. I still don't know why, but the emergency fix at least prevents
other people from running into it. As a bonus, since we have a proper
logging facility now, we can actually log it as I desired to do back
then!
This commit tentatively fixes issue 729.
QDocument::toPlainText() has the stupid decision to convert nbsp to
spaces in it, which our users obviously hate. Unfortunately, this is
out of our control to fix completely. It is a very deep rabbit hole. :(
Typing non-breaking spaces in the editor now works. Reopening these
files at a later point has these characters remain intact.
What does NOT work is copy-pasting non-breaking spaces. These will end
up looking like normal spaces when you paste them somewhere else, be it
in Manuskript or some other document. In other words: it is impossible
for users to verify whether something is a non-breaking space or an
ordinary one.
I realize that it makes this partial fix meaningless for many. Sorry. :/
Partially fixes issue 738.
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...
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.
This is the quick way to patch this. I'd recommend changing the findFirstFile function in functions/__init__.py for a more permanent solution, but this should suffice for now.
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
When i was using certain styles like cleanlooks or qt5ct-style, a TypeError was raising in cascade about the function not having enough arguments.
It looked like that, despite the last args of Qstyle.subElementRect() and Qstyle.sizeFromContents() were optional, it was still required to mention it (even if it was just None).
That TypeError was only appearing with certain styles, at startup or when changing styles in the settings window.
Last time I touched this code, I went in looking for a specific problem,
and came out with a fix specific to that issue. That fix was not wrong,
yet it hardly covered all the problems present in the code once one took
into account issues like:
- local vs remote resources,
- relative vs absolute paths,
- different operating systems behaving differently, and
- Qt being uniquely buggy on different platforms.
The major part of it was fixed by using QUrl.fromUserInput(), which does
the exact kind of auto-detection for the nature of the resource that we
were in need of.
The rest of the issues were fixed by creating a number of test cases and
fixing problems as they popped up. Testing was done in Windows & Ubunty
against the above-mentioned test cases, which can be found in PR #629.
Regarding ImageTooltip.supportedSchemes
When QUrl.fromUserInput() misidentifies the scheme on Linux, it causes
all resemblance between the original request and the reply.request() in
the finished() signal to be lost, which results in this item getting
stuck in the ImageTooltip processing pipeline.
Limiting the supported schemes to the ones most commonly encountered
('file', 'http', 'https' and the schema-less local paths) is the only
reliable method I have found to work around this particular bug in Qt.
Describing all the rabbitholes that I and kakaroto have gone through
while debugging this one until dawn can frankly not do enough justice to
the crazy amount of rubberducking that went on while trying to fix this.
This bug would be triggered whenever you had a document open in the
editor and then moved an ancestor object downwards (visually) in the tree.
Or when you simply deleted the ancestor. Depending on the exact method
that caused the opened item to be removed from the internal model, the
exact nature of the bug would vary, which means this commit fixes a few
different bits of code that lead to what appears to be the same bug.
In order of appearance, the bugs that ruined our sleep were:
1) The editor widget was trying to handle the removed item at too late a
stage.
2) The editor widget tried to fix its view after a move by searching for
the new item with the same ID, but in the case of moving an object down
it came across its own old item, ruining the attempt.
3) The editor widget did not properly account for the hierarchical
nature of the model.
Upon fixing these the next day, it was revealed that:
4) The outlineItem.updateWordCount(emit=False) flag is broken. This
function would call setData() in several spots which would still cause
emits to bubble through the system despite emit=False, and we simply got
lucky that it stopped enough of them until now.
This last one was caused by a small mistake in the fixes for the first
three bugs, but it has led to a couple of extra changes to make any
future bug hunts slightly less arduous and frustrating:
a) When calling item.removeChild(c), it now resets the associated parent
and model to mirror item.insertChild(c). This has also led to an extra
check in model.parent() to check for its validity.
b) The outlineItem.updateWordCount(emit=) flag has been removed entirely
and it now emits away with reckless abandon. I have been unable to
reproduce the crashes the code warned about, so I consider this a code
quality fix to prevent mysterious future issues where things sometimes
do not properly update right.
Worthy of note is that the original code clearly showed the intention to
close tabs for items that were removed. Reworking the editor to support
closing a tab is unfortunately way out of scope, so this intention was
left in and the new fix was structured to make it trivial to implement
such a change when the time comes. An existing FIXME regarding unrelated
buggy editor behaviour was left in, too.
Many thanks to Kakaroto for burning the midnight oil with me to get to
the bottom of this. (I learned a lot that night!)
Issues #479, #516 and #559 are fixed by this commit. And maybe some others,
too.
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.
Issue #549 was caused because the request and reply object urls are not
guaranteed to be the same. Redirects are the most common cause, but a
malformed URL apparently also qualifies. We now make sure to look at the
original request.
Because the code confused me while I was working on it, I decided to
refactor and document it in order to understand what was going on. I am
glad I did: I found another crashing bug involving the rapid-firing of
tooltip requests, and the processing dict never had its entries removed
either, leading to a (very slow) memory leak over time.
All is good in the world of image tooltips now.
In the properties view, the context menu on the title line would be black
making its content unreadable. Same in the filter line of the "Set Custom icon"
window on the outline's context menu.
Windows path to the image has '\' path separator instead of '/' which makes
the stylesheet fail. Background images don't appear and console gets spammed with :
Could not parse stylesheet of object corkView(0x27248eb6900, name = "corkView")
