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.
The user can configure a language for Manuskript in the dialog, but
before that setting is ever written to disk, there is the default
behaviour that tries to auto-detect the best language to show based on
the configuration of the device it is running on.
While doing my due diligence on issue #619, I realized we were relying
on the system locale, which is not necessarily equivalent to the
language the user is working with. Worse still: a user can have multiple
preferred languages for their user interface, and our old approach might
actually offer them the 'wrong' language. This patch fixes this.
It also refactors and comments things a little bit where necessary.
Issue #619 revealed an unintentional overlap between the auto-detection
of the locale and the implicit builtin English language, which resulted
in users being unable to select the builtin English language when their
device was configured with a locale that we happen to have a translation
for. The code has been rewritten to more clearly separate auto-detection
and the final fallback that is the builtin English translations.
This code change sets:
- Fequency Analyzer tool default first tab of "Word frequency"
(was Phrase frequency)
Steps to set default window tab:
1. Start Qt Designer
2. Open .ui file
3. Ensure that each selected window tab is the one desired as default
4. Save .ui file
5. Exit Qt Designer
6. Generate .py file with: make ui
See PR #623
This code change sets:
- Character pane default first tab of "Basic info" (was Notes)
- Character pane Basic info "Name" as the default first field (was Motivation)
- Plots pane default first tab of "Basic info" (was Resolution steps)
Steps to edit tab order and default window tab:
1. Start Qt Designer
2. Open .ui file
3. Choose menu **Edit -> Edit Tab Order**
4. Ctrl-click on item just before the first incorrect tab order item
5. Click other items in order until remaining order is correct
6. Ensure that each selected window tab is the one desired as default
7. Save .ui file
8. Exit Qt Designer
9. Generate .py file with: make ui
See https://doc.qt.io/qt-5/designer-tab-order.html
This code change implements a portion of issue #244
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.
Windows 10 has supported a 'dark theme' option for a while, and the fact
Manuskript is like looking into a bastion of bright white while using it
is bothersome to say the least.
Since this is a setting defined as the OS level, I believe this should
be something Manuskript automatically adjusts itself to match, thus the
lack of a configurable setting on the Manuskript end.
Qt has garbage documentation. I dug into Qt 5.0 source code to make sure
the crashing call can be safely left out for older versions, and that is
indeed the case. setSupportedSchemes() appears to be introduced together
with the future to select non-local files in the dialog, but we only
cared about local files to begin with.
I happened to notice the UI briefly locking up when testing my previous
changes on some of the Pandoc exporters. While the bigger mess I found
along the way is more than a little fix can handle, this stopgap measure
will at least stop us from running pandoc when it isn't needed.
According to issue #608 we were silently overwriting files when there
was a suffix being generated for a chosen export filename when one was
missing to begin with. Unfortunately, this helpful feature avoids all
the conveniences offered by QFileDialog in regards to alerting the user
to overwriting an existing file. Worse still, this feature already
exists in QFileDialog and the native APIs it can rely on.
This patch reimplements QFileDialog.getSaveFileName to allow the use of
the default suffix feature as functions.getSaveFileNameWithSuffix and
removes most of the magic involved with the old solution.
It is the only FileDialog in the entire codebase that does not conform
to the rest of the OS like its brethren, and it stuck out like a sore
thumb because of it.
Some bugs are out of our reach to fix, but can still impact the user
considerably. Because losing progress always hurts, we want to make
the user aware of the risks before any tears are shed. (PR #612)
See PR #615
This rename is being done to clarify that when a user enables "Save on
project close" then the project will be saved whenever the user
chooses to close the project or to quit Manuskript.
Note that the actual name of the setting saveOnQuit should also be
changed but instead has been marked as a future TODO because it
involves a change in the project file format.
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 Travis CI builds are failing with the following messages:
pyenv local 3.6.3
pyenv: version `3.6.3' not installed
Fix by increasing python version to 3.6.7.
See issue #561.
The problem appears to be a due to a combination of factors, such as:
- Python does not automatically convert an empty/blank variable to the
integer zero (0)
- Default goal value is empty/blank for a new Text (scene)
- Asynchronous events can occur such that the change in the Outline
pane of a new Text (scene) goal from empty/blank to a value is not
saved to the data model prior to the update event in the Editor pane
accessing the model value for the word count progress display.
Steps to Reproduce:
1. Start manuskript and create new project (no template).
2. Select **Outline** pane.
3. Click "Text Plus" icon to create a text (default name "New")
4. Select **Editor** pane.
5. Click on **New** to display empty text.
6. Select **Outline** pane.
7. Double-click the empty area on **New** line under title **Goal**,
type in "300", and press **Enter**.
Note that manuskript crashes with a segmentation fault.
Work around the crash by using the already existing manuskript
function toInt() which handles conversion of empty/blank values to
integer value zero (0).
Update the language translation source '.ts' files with the
translatable strings in the source code with the following command:
$ make translation
This effectively runs the following command:
$ pylupdate5 -noobsolete i18n/manuskript.pro
After updating the '.ts' translation source files from weblate,
compile all of the language translations into '.qm' files.
This was done with the following command:
$ make i18n
This effectively runs the 'lrelease' command on each '.ts' file. For
example:
$ lrelease i18n/manuskript_es.ts
