Themes too difficult

Yeah, those themese dont look too nice. Have you tried plugin themes? They look much nicer.

1 Like

Now I can't install plugins from a file.
The Manage your plugins->install from file, doesn't bring any dialog box. Nothing happens when I click it.
This is the same behavior when I try to import or export fro the file menu.
What's up?

That was a bug with the 2.5.8 release on Linux, try 2.5.10

2 Likes

thanks

Ok, I updated Joplin, now the dialogs are appearing but they appear behind the main window. It took me awhile to figure out that they were present..
This happens every time.

Plugins can also installed manual.
Drop the jpl file into .config\joplin-desktop\plugins

2 Likes

thanks

I second @iomari's suggestion because in my humble opinion there's an issue with lack of contrast in the default settings: When I use the split-screen markdown editor (which I like very much because it gives me a 'centred' experience just like reading mode in Firefox), the font colour (light theme) seems somewhat greyish to me (not black).
What's even more problematic is the dark grey scrollbar in the notebooks section on the left of the screen: almost indistinguishable from the black background so that I accidentally end up nesting notebooks when I fail to hit the bar for scrolling.
Customisation is one of the great strenghts of Joplin, but for those unacquainted with CSS (or at least with its practical usage) it's rather hard to tackle with these issues.
Joplin 2.5.12 (prod, win32): really great app nonetheless!

2 Likes

@former_evernotist I too found the default light theme lacking a little bit of contrast.

Below is some css I have collected over the years to put a bit of contrast into the Joplin light theme. It still seems to work and It also makes the scrollbar easier to see.

I have commented the css so you can remove any bits you do not want / need.

userchrome.css

Click to expand
/* ==Interface modifications== */

::-webkit-scrollbar-thumb {
    /* changes the scrollbar slider colour */
     background: #c0c0c0 !important;
}
 div.note-list-item span {
    /* notelist - note title text */
     color: black !important;
}
 input.title-input {
    /* note - note title text*/
     color: black !important;
}
 a > span.icon-back,
 a > span.icon-forward,
 a > span.icon-share,
 a > span.icon-bold,
 a > span.icon-italic,
 a > span.icon-link,
 a > span.icon-code,
 a > span.icon-attachment,
 a > span.icon-bulleted-list,
 a > span.icon-numbered-list,
 a > span.icon-to-do-list,
 a > span.icon-heading,
 a > i.fa-ellipsis-h,
 a > span.icon-add-date,
 a > span.icon-layout,
 a > span.icon-info {
    /* changes toolbar icon colour - inactive icons are a % of this colour*/
    /* these can be broken out into individual entries if a "rainbow" of colours is wanted*/
     color: black !important;
}
/* Start - the below section is not required if you do not use the "Menu items, Shortcuts, Toolbar icons" plugin */
 a > i.fa-highlighter,
 a > i.fa-strikethrough,
 a > i.fa-underline,
 a > i.fa-superscript,
 a > i.fa-subscript {
    /* changes the "Menu items, Shortcuts, Toolbar icons" **plugin** toolbar icon size and colour - inactive icons are a % of this colour*/
    /* these can be broken out into individual entries if a "rainbow" of colours is wanted*/
     font-size: 1em !important;
     color: black !important;
     font-weight: 600 !important;
}
/* End - the above section is not required if you do not use the "Menu items, Shortcuts, Toolbar icons" plugin */

/* ==CodeMirror editor modifications== */

 span[role="presentation"] {
    /* editor pane text */
     color: black;
}

userstyle.css

Click to expand
 body,
 table th,
 table td {
    /* sets body text, table cell, and header cell font colour */
     color: #000000;
}
 code {
    /* sets code font colour - fenced code, inline code and pre */
     color: #000000;
    /* stops code boxes extending off the note page */
     white-space: pre-wrap;
}
 caption {
    /* puts a table caption underneath the table rather than the default (above) */
     caption-side: bottom;
    /* sets the colour of the table caption */
     color: #000000;
}

Thank you very much @dpoulton! It's good to hear that things still work because there's this official warning somewhere else in the forum that every CSS customisation can potentially become unusable after an update…
Strange thing is that contrast in the markdown editor seems to be better on smaller and sharper screens such as a 12" Surface. Large fonts on a 17" laptop tend to look rather grey and blurry, but maybe I should check first what colours are effectively encoded (after giving up my reluctance to CSS tweaks of course…).

Yes, that's true and is why I mentioned it! However it's not that common and, of course, the less you customise the less chance there is that something will stop displaying as you wanted it to!

It's possibly not that strange. If the 17" screen has a comparitively lower resolution (pixels-per-inch) the font-smoothing can become more noticeable and make the letters look at bit "greyer / blurry".

Looking into Joplin shows that the default editor text colour is #32373F which is noticably lighter than black and can then be made to look a bit lighter again by font-smoothing.

colours

Thank you very much again for that clarification! So I would like to suggest that the standard font should be made blacker and the bar for scrolling the notebooks list be made lighter - and all would be so well...
Maybe I'm a bit obsessed with UX issues, because one of these made me leave Evernote (not privacy concerns, although I know I should have had them all along). After switching form Android to iOS I was shocked to discover that Evernote doesn't support dynamic text (which it does on Android), and the standard font is ever so tiny. But that's what I pointed out in another posting:

I really hope someone helps Ohmine to gain some traction by adding an easy switch. It's pure eyecandy imho :slight_smile:

I can definitely second the general sentiment.

Some time ago Joplin changed its default styles to add padding on the sides; this was undesirable for my purposes, so I went to revert the change and found out about the process, which involves hunting down classes in the dev console for each one of the several different editing components that Joplin uses.

The nitty-gritty details of the process are virtually undocumented, making even simple modifications opaque and time-consuming.

Out of interest what padding are you referring to?

I would argue the main areas are pretty much covered.

  • Selection of inbuilt themes
  • Addition of theme via plugin (like macOS theme)
  • Addition of themes via CSS
  • UI modification for advanced users by CSS.

I wouldn't say that eliminating UI padding by modifying the application CSS is a standard user practice, many apps don't offer anywhere near that level of granularity outside of advanced config such as css.

On the sides of the editing area, to limit line length.

If you mean the editor width then you didn't need to do it via css:

That's good to know! But it doesn't change the fact that doing it manually takes quite some work and requires figuring out stuff by trial and error because it's undocumented.

(Ofc if documentation has been published since my last search on the subject I'd be very happy to be proven wrong).

The core of the problem seems to boil down to with the way Joplin is put together, and more or less the same reason why it's impossible to do any editing on Android that isn't super basic (albeit, the last time I did attempt that was quite some time ago, so if things have improved I'll stand corrected).

For whatever that may be worth, as it is my understanding, that any attempt at remediation would require a significant, lengthy effort. So, thanks for the pointer.

PS: and also, apologies for the brief diversion from the specific topic of discussion.

I don't think it is normal to document literally every setting, feature and button of an application if they are somewhat self-documenting - the setting in question already has a description in the setting wording. It was included in the change notes (granted I think the wording isn't as clear as it could be but it wasn't some hidden setting with a complicated way of changing the value).

I don't quite understand what is meant by this? What exactly is this reason and how does an appearance setting relate to the mobile editor?
As for editing on mobile, the new beta editor is certainly better than the old one, the main issue for me is just inputting markdown via a stock mobile keyboard is a bit of a faff (mostly making task lists).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.