Zettlr / Zettlr

Your One-Stop Publication Workbench
https://www.zettlr.com
GNU General Public License v3.0
10.14k stars 623 forks source link

[Enhancement] Remove color from simple markdown in existing themes #2243

Closed Redsandro closed 2 years ago

Redsandro commented 3 years ago

Description

Edit: Remove colors for simple markdown from existing themes, and other conservative tweaks.

Original issue below:


Description

With Zettlr 2.0 coming up, I'd like to bring up the idea of removing the old colors and permanent markdown display for simple markdown e.g. _italic_ and **bold** text. I know it's kind of a signature look to have those lines marked in the theme color, but the colors and the symbols make it look crowded. I find them to be interfering with my thought process too much.

image

So much even, that on texts where I used a lot of simple markdown, I tend to prefer to edit the notes on Nextcloud Notes (compatible with Zettlr) where the color is the same as the rest of the text.

image

Additionally, it would be more zen to hide those markdown symbols like Zettr does with URLs.

Proposed Changes

In stead of showing simple markdown symbols like _italic_ and **bold**, we can make it look more modern and easier to read by showing italic and bold in the color of the rest of the text, and only show the markdown code when the cursor is over it, much like Zettr does with links.

Caveats

You will lose some of the signature look, but a new 2.0 major version is the ideal moment to make a bigger change. Just like the "Search" is a big change. Although technically the change might not be so big, since the same concept is already used for links, which show differently when the cursor is on them.

I think it has a modern and peaceful look when the text displays normally until cursor is over it.

BellLongworth commented 3 years ago

Voting for this as well. I understand that Zettlr is not a WYSIWYG editor, but for simple markdown like bold or italics it really makes sense to just have the text be bold or italics. URLs, tables, checkboxes all get nicely rendered - so this is not a big departure from the current concept.

nathanlesage commented 3 years ago

This really touches an area where I'm pretty opposed to :D

Hm. I really don't like this, but I know that this issue has been coming up steadily and frequently, so … well I'll take another look into this, alright?

Redsandro commented 3 years ago

I really don't like this, but I know that this issue has been coming up steadily and frequently, so … well I'll take another look into this, alright?

@nathanlesage Perhaps I can add some words for your consideration. I appreciate that you have reasons for this. In the end, we are looking for tools to help our productivity, and if this helps you, it needs to exist. We forge or fall in love with tools that help remove obstructions from our workflow. When an obstruction is removed, we look for the next biggest obstruction to remove like sanding our creativity with increasingly fine grained sandpaper. No detail is too small to be considered an issue for a perfectionist.

I'm finding myself intermittently cheating on Zettlr because this layout thing is starting to become the next biggest obstruction in my note taking workflow. But I come back for the other features. Sometimes I draft in Zettlr but finish elsewhere.

If you empirically find the current style to help you be productive, and you can empathize with people saying it obstructs their workflow, perhaps rather than making a choice, you can consider making it an option.

For example:

Rendering:

or Rendering:

An added benefit would be that you can make more conservative and progressive choices at the same time in the future.

On the other hand, if the current style doesn't really help you be more productive while the change is a popular request, perhaps it's time to kill your darlings, or find a middle-ground e.g. remove the markup but retain a (less contrast!) version of the theme color.

nathanlesage commented 3 years ago

That was poetic! I think I just realized what was my main inhibitor: Everyone can already do that, since that's what Custom CSS is for. Maybe I subconsciously fear that if that is changed the Custom CSS is useless, but that can be pretty irrational. In the end, the easiest way to make me change the CSS is to just implement it yourself (since the colors are actually quite easy to modify) as a "custom theme" and just show me. I've in the past very often taken up good ideas of people!

But in any case, does the Bordeaux-theme look anything like what you'd like? We can simply add a theme using sans-serif font in this minimalist sense?

Redsandro commented 3 years ago

(This message was edited after the notification email was sent.)

@nathanlesage I must admit that I just picked Berlin in dark mode on day one and never looked back. I just falsely assumed the other themes were the same in different fonts/colors.

So I just learned that Bordeaux doesn't color code the simple markdown codes. Unrelated to further discussion, I have two suggestions I like to make before I forget them:


  1. After seeing Karl-Marx-Stadt in dark mode for the first time, I notice that the contrast is more pleasant. This leads me to believe that the colors for Berlin specifically in dark mode are simply too dark to be pleasant either for anyone or for people with a certain monitor calibration profile (mine is calibrated for photo editing and has a gamut of 100% sRGB 99% AdobeRGB). Perhaps the default colors should be lighter in dark mode.

I will experiment with this and propose some different values. I've found the custom css documentation, but could you point me in the right direction for simply changing the default colors for bold and italics in a way that similar colored markdowns are also updated for consistency purposes? Can you use a different shade of color in dark mode as opposed to light mode, or do we need a single shade that works well in both?

  1. 2380


Back to the discussion - I did a similar thing when I read about custom CSS: I made assumptions without actually trying it out. I will try this. I do think that if there is a popular request, Zettlr 2.0 is a great time to consider making tweaks. For example I could imagine no one likes a monospace font as a default. (I'm probably wrong - do you have any telemetry on what themes are hardly used?) We could remove that one, and take the most popular theme and make a variant with the markup symbols hidden. Because not everyone is tech savvy enough to play with custom CSS (and apparently even if they are they might still ignore the option. :sweat_smile: )

Note that I'm trying to find a compromise that everyone can be happy with. In my raw opinion, users want a toggle/option that will remove markdown markup symbols regardless of theme, so it is good for Zettlr's popularity to offer that. If I understand correctly, it is possible with some internal CSS to offer a "Markdown mode" and a Typora/Mark Text like "WYSI sort of WYG mode" while keeping the themes. Currently Zettlr is a hybrid (by showing links and tables in "WYSI sort of WYG mode" and other markup in "Markdown mode") so in some cases you do see the benefit of hiding the markup. Your tolerance for distracting symbols in the text is just a bit higher than that of the people requesting this option.

nathanlesage commented 3 years ago

This leads me to believe that the colors for Berlin specifically in dark mode are simply too dark to be pleasant either for anyone or for people with a certain monitor calibration profile

Absolutely. The Berlin theme is the oldest one (before I even started adding multiple themes to the app), so the colours are back from a time where I didn't have enough experience at all. Suggestions are very welcome – especially in reducing the colours, because me not being a good designer I tend to default to too many colours instead of less and thus more legible ones. But, as I said, I depend on others for this with more experience than me. It's a classic case of "works on my computer"/"works for me", and I have too less time to poke around in the dark. But if someone has good ideas, I more than welcome these to be put into the app!

I will experiment with this and propose some different values.

That would be awesome!

[…] but could you point me in the right direction for simply changing the default colors for bold and italics in a way that similar colored markdowns are also updated for consistency purposes? Can you use a different shade of color in dark mode as opposed to light mode, or do we need a single shade that works well in both?

I tried to make the CSS as easy as possible. That being said, this is the order:

  1. Everything is namespaced to body.
  2. Then, everything is namespaced to light or dark mode (just body for light mode, body.dark for dark mode)
  3. Finally, many things (but not all) can be namespaced to the platform (e.g., body.darwin, body.linux, body.win32)

But the easiest way of editing Custom CSS is to activate the debug mode in the preferences, then open the DevTools (they work exactly as they do in Google Chrome) and using the "Inspect Element" function to inspect an element. Screenshot:

image


Below the theme icons, on the preferences page, I recommend putting a short text that describes the theme.

Actually, I had something like that in the 1.8.9 which had displayed the dominant colours and the used font. But I think a short description might help. I don't know how other themeable apps do this.

There can also be a reminder on the theme page that further refinements can be made with custom css (insert link to css documentation).

Sounds like a good idea!


Lastly, yes, 2.0 is definitely the right time to make tweaks to everything but I'd like to retain all the themes. Adaptation? Yes! But I'd like to prevent having one theme with different colours. Rather the themes should still have some character to them (I mean, after all, the theme only applies to the editor)

Redsandro commented 3 years ago

Now that you have given me this power (or reminded me that I had it all along), I'm tempted to go crazy and find it very difficult to stay conservative and true to the theme. But as promised, let me try some small suggestions. Here is a screenshot from the default Berlin in Night mode:

image default Berlin Night mode

I think the title hashes are begging to be made consistent with the other markup css, which means an opacity of 0.3, and I have made the colors of bold, italics and links very slightly brighter and more uniform:

body.dark {
  --c-primary: #10d993;
  --c-primary-shade: #0aa46e;
}

.cm-strong, .cm-em {
  color: var(--c-primary);
}

body .cm-formatting-header {
  opacity: 0.3;
}

I would prefer to make it even brighter, but I think this is conservative enough not to freak people out.

image

Personally I'd remove the color from bold and italics altogether, including keeping the inline-code text white in stead of grey. It already has a brighter background, so it already lost enough contrast. The inline-code change is subtle but it pops a little bit more, as if washed from a layer of dust. Consider this, or just the cm-comment class, as an addition to the above.

.cm-strong, .cm-em, .cm-comment {
  color: white !important;
}

image


Spin-offs:

nathanlesage commented 3 years ago

But I don't believe I can replicate the link behavior in custom CSS to hide the asterisks and underscores

No, that requires text markers. The functionality is already in Zettlr, funny enough. I just need to expose a setting to actually enable it. If you didn't know: I did write an experimental WYSIWYG-mode two or three years ago, but never opened it to the public :D

To the rest I answered in your issue. It might be much simpler for me and others who might want to implement this if you could split up the four different issues into separate issues!

nathanlesage commented 3 years ago

Oh and with regard to removing color completely from italics and bold: I think that's absolutely good for all themes (since there's still color in other parts)

Redsandro commented 3 years ago

@BellLongworth your vote would go to #2377 - I'll repurpose this issue for the color removal alone.

Redsandro commented 3 years ago

@nathanlesage I've cleaned up this issue. This one is now about the themes.

with regard to removing color completely from italics and bold: I think that's absolutely good for all themes

I believe this selector can remove color from all the themes, but I can't find the variable that holds the color of the main font for the current theme; white only works in this specific theme/night-mode:

/* All: Remove shades from simple markdown */
.cm-strong, .cm-em {
  color: white !important;
}

Have I missed your comments about my other proposals?

  1. Berlin (or All?) Remove shade from inline-code; e.g.:

    .cm-strong, .cm-em, .cm-comment {
    color: white !important;
    }
  2. Berlin: Make colors slightly brighter

    body.dark {
    --c-primary: #10d993;
    --c-primary-shade: #0aa46e;
    }
  3. Berlin: Make title hash annotation opacity consistent with the other markup annotations

    body .cm-formatting-header {
    opacity: 0.3;
    }
nathanlesage commented 3 years ago

but I can't find the variable that holds the color of the main font for the current theme

It's --c-primary and --system-accent-color. --c-primary-shade is deprecated, I just don't have the time to remove that (rather, what we need is a contrast, not a shade).

I'm perfectly fine with all of your three suggestions here! Question to number 2: Would it work to just use Zettlr's Crayola Green for that (#1cb27e)? Or would that be too bright or dark? Because in theory that should have a good contrast with dark!

Other than that, feel free to open a PR to fix that if you like, else I can copy&paste that stuff into the source code.

Redsandro commented 3 years ago

feel free to open a PR to fix that if you like, else I can copy&paste that stuff into the source code.

Time is a rare commodity for me too so I'd like to do a PR if you have the patience for me to set it up. If you run out or want to release 2.0-rc at some point and I'm still queued , I recommend copy/paste before release.

I had some other unrelated and previously discussed things I wanted to try too but I had some problems building and then (conveniently) postponed looking into it until 2.0 nightlies were a little bit more molded.

The problems iirc were (1) something about the yarn version but I didn't want to make a global update because I used it for another project, and (2) I messed up some of my actual notes because I didn't read correctly so I need to make sure I'm not using my existing notes for the development version.

I know you wrote extensively about how to build this, but if you could write a world record micro-sized summary of essentials, I would appreciate it. Here, let me write it, and you only tell me what is wrong and what else is important to keep in mind:

git clone https://github.com/Zettlr/Zettlr.git zettlr && cd $_
nvm use 14
npm install
npm install yarn # so I can leave global yarn alone, do not --save-dev
npx yarn test-gui
nathanlesage commented 3 years ago

Time is a rare commodity for me too so I'd like to do a PR if you have the patience for me to set it up. If you run out or want to release 2.0-rc at some point and I'm still queued , I recommend copy/paste before release.

Sounds good!

and you only tell me what is wrong and what else is important to keep in mind:

The complete micro-setup guides is:

install node # Adapt to your system, at least node 12 afaik
install yarn # Which you have apparently already done
install git # For completeness sake
git clone https://github.com/Zettlr/Zettlr.git Zettlr && cd Zettlr
yarn install --frozen-lockfile # Important to prevent yarn from updating the lockfile
yarn test-gui --clean # This runs in development, apart from your actual notes and settings.
                      # Pass --clean the first time and whenever you want to reset the directory

If you tried to set it up approximately two hours ago I had shortly messed up the repo, but it should work again.