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 
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.