This PR includes various fixes and improvements, most of which I discussed with @somas95 a couple of weeks ago. It also includes some refactoring, mainly to improve encapsulation.
Fixes#17Fixes#75Fixes#90Fixes#120Fixes#122
Some considerations/questions follow.
**Commit messages**
I recommend reviewing each commit message carefully, as they explain the thinking behind each change. Not everything is small or linear, and hopefully the commit message explains the background and reasoning properly. If anything is missing, I'm happy to try to explain.
**Translations**
There are a few capitalization/copy fixes. I am unsure how this affects translations, or if there's any work I can to make the transition easier. For instance, how are the po files updated?
**Styling**
Styling is subjective, and although I claim to address #90, it's important to note that I'm a fan of UberWriter's simplistic style, reminiscent of iA Writer's approach. As such, I didn't introduce any sizing nor color changes, as I don't personally agree with this direction. Instead, the changes are subtle:
* For links, the link/syntax part is greyed out, without any further changes
* For code blocks, they are indented similarly to quotations, without any further changes
**UI changes**
There are (very minor) UI changes within the places that were touched, mainly preferences and the export dialog. Most of these are around improving small things, such as spacing (eg. multiples of 8), slightly broken alignments, etc.
The only exception would be the removal of ODT as one of the export options in the top bar. As before, subjective, but I find that a sub-window's top bar with 6 horizontal buttons is a little overwhelming, and considering that ODT is still available within the advanced tab, I propose that we remove it as a default option and have a more balanced top bar. I am assuming that PDF/HTML are the most used, but please let me know if that's not the case.
**Further work**
I have a few more tasks planned for the upcoming weeks, hopefully built on top of this codebase as it makes some of them much easier. [Here's a screenshot of my Todoist.](https://cl.ly/4160755d210d/gnome-shell-screenshot-3MMO0Z.png) Hopefully this helps knowing what to expect. 😊
TextIter must not be reused in between buffer changes. This resulted in
unpredictable behavior when using search and replace. For instance,
in the following string:
This _is_ a _test_ of _search_ and _replace_
Searching for "_" and replacing with "**" sequentially would:
[0] This **is_ a _test_
[1] This ****is a _test_
[2] This ****is a **test_
[2] This ****is a ****test
Replace had similar results.
There were 2 problems.
When pasting very large documents, the height calculations will be
temporarily incorrect while the content is rendered over several frames.
This is addressed by waiting for the UI to be idle to scroll.
Additionally, the scroll time (typically 200ms) needs an adjustment as
well. Starting at 200ms, it now scales linearly with distance, amounting
to roughly 4 seconds with Pandoc's user guide.
This commit adds markup support for code blocks, styling them in a
conservative manner, similar to blockquotes, solely indenting them.
Partially fixes#90
Code-wise, this means marking up around the cursor becomes exponentially
more complex, as a change in one line can affect multiple lines. Solving
it is non-trivial, so the whole document is always marked up.
Marking up the whole document is irrelevant for small to medium
documents, but can incur in a performance penalty for
very large documents (empirical testing: 1M characters takes ~0.15s).
To alleviate this, GLib.idle_add is used to ensure that markup is only
parsed and applied when the UI is idle. Again, small to medium-sized
documents see no difference. For very large documents, markup will be
slightly delayed to allow for a fluid typing experience.
It's important to note that the previous flows frequently used full
document markup: paste, focus mode, and search and replace.
In some extreme cases, doubly parsing (eg. paste + text change).
For very large documents, doing any of these actions would freeze the UI
unconditionally, so in more ways than one this is an upgrade.
Lastly, it's a little overzealous: with over 1M characters the UI itself
struggles more than parsing.
In sum:
* Markup is always applied to the whole document
* The code is simpler
* There is never double work
* Markup is applied when the UI is idle, for a more smooth experience
* Multi-line formatting is now possible to do reliably
Changes include:
* Much better encapsulation of textview/textbuffer, with each isolated
responsibility living independently on its own class/file.
* Less code overall
* Various small fixes around the components involved, such as:
* Indentation of nested lists (fixes#120)
* Unwanted scroll on select all (ctrl+a)
* Removal of unused code around the components involved
* Fixes for scrollbar location, now at the edge of the window
Overall refactoring of how the theme is set, bounding it to the window
instead of the application, which generally makes it easier to listen
for the "style-updated" signal.
A lot of improvements made by @goncalossilva:
Fix#112
Improve the themes support:
Clean all the CSS involved
Encapsulate theme handling
Reload preview when theme changes
Fix fonts on the preview mode
Add support for high contrast themes
Add Hemingway mode
Theme colors are originally based on GitHub's theme.
This script (slightly) offsets them to match the color pallete of the
specified theme automatically, and prints them out.
While the adjustments are meant to be minor, color contrast should still
be verified.
Finally, a few themes should not be automated in this way. For example,
the high contrast themes are meant to be purely black & white.
somas95
