I’ve been throwing a few things at Notenik for a day now and been delighted at how clever it is at making sense of them. Really love the text-based approach that doesn’t dispense with helpful database fields.
The App Catalog turned to collect some quite useful information I’m glad to have in one (quick) place.
And Outlines are an impressive extension of the Notenik concept, too. Love the links between entries especially. I added a last modified date field and was pleased to see I could sort on that and display the field in the sort.
Also tried Import > Folder of Text Files and converted quite a collection in the blink of an eye.
Really nicely done, Herb.
Here are few bullet points (posing as questions) for consideration as well:
Can we have larger indents than a single space on Titles for Outlines in List view?
And indents in Tag view for Outlines so the hierarchy is observable?
Paragraphs in the Body beginning with an indent (a tab or multiple spaces) lose whatever default formatting is applied (both with and without display.css) by Bowie Markdown parsing (but the other two options are worse)
Import > Folder of Text Files skips files whose title isn’t clear. The error message pointing to the log merely mentions having trouble importing them but all I had to do was add the Title and Body tags to the file.
Might mention somewhere the Basic template works for Populate App Catalog or just start there when the menu item is selected. I threw caution to the winds and it worked out for me.
With display.css for fonts, the Dark Apperance preference has no effect (System is light and Display used a white background).
Thanks again for making this quality tool available.
Re: User display.css overriding the Dark appearance in Display mode
I’ve chalked this up to the fact that Notenik handles the document’s appearance as described above, i.e. a custom stylesheet is meant to replace all default styling. So it looks like the Dark appearance option only applies to Notenik’s default stylesheet.
I do know however that if you make minute changes by accessing the Display Preferences ( Notenik > Display Appearance) you can make universal CSS changes that apply to all of your Notenik collections and these changes shouldn’t affect a note’s display when in dark mode (as long as you do not change the background-color). The only caveat to this method is that you cannot declare any changes to specific CSS selectors in the Display Preferences; you are essentially making changes to the entire html or body element. Also remember that Display Preference alterations apply to all collections.
Depending on what your custom stylesheet consists of and if you want it to apply to more than one stylesheet, you may want to delegate the code to the Display Preferences menu.
Or you can try this workaround that I’ve thought about. We can query @hbowie’s Github repos for prefers-color-scheme: dark. This should lead us to any Notenik code that refers to the default CSS that activate the Dark appearance that we’re looking for.
Into our display.css files and change the code around:
@media screen and (prefers-color-scheme: dark) {
body {
background-color: #000000;
color: #F0F0F0;
}
a {
color: #93d5ff;
}
}
We could have a Dark appearance in our collection and even expand on its functions. I haven’t tested this myself, but I hope to return back to this thread later and plug the CSS into my own stylesheets to see how close it gets to the default Dark appearance. I hope this helps you though. Welcome to the forum.
I did manage to get around this to what I wanted by generating the full display.css in the appropriate folder and modifying the body tag, as you suggested:
And that gave me my preferred font and size with a dark (if colored) background.
Just dropping the CSS generated by Notekin’s Display Fonts button into display.css did change the font but reverted to a light background, as I mentioned.
Excellent discussion! I’m working on a change for the next release that I’ve documented in the Pipeline such that the CSS used internally, and written out externally, will reflect the current user’s light/dark preferences. Hopefully this will make this easier for other users in the future!
I was previously unaware that you could generate a pre-made display.css. Now I fully understand the breadth of @mrpasini’s initial post. Glad to know that I was able to help nonetheless.
I think that would reflect the expected behavior nicely.
I’m finding it helpful to use different color/background schemes (beyond light or dark) for different projects so I can see at a glance which project they address. Since this pertains only to the Display area (and not to the app’s general light/dark preference) it would be nice to see two color swatches to be able to set in the Display Fonts window.
Can I get some clarification/further discussion around your second bullet, concerning indents in Tags view for Outlines so the hierarchy is observable?
There are several complications here:
Notenik allows for multiple levels of tagging, and indenting is already used on the Tags tab to show that hierarchy;
Additionally, if, as I generally do, there is a Seq field, and the Seq numbering reflects the level (so seq 1 is level 1, let’s say, and seq 1.1 is level 2), and you are sorting by Seq, then the Seq value is displayed just before the title, so that the positioning of the start of the actual title tends to reflect the outline level anyway;
Depending on how you use your tags, the Note titles appearing beneath a particular tag may come from a variety of locations in your Outline, so any attempt to indent titles may become confusing (since the item appearing above on the Tags tab may not necessarily be a parent in the outline structure).
I hope all of this makes sense.
Also, depending on your Collection setup, it can be useful to use the command beneath the Collection → Level menu named Replace Tags Based on Seq + Level. This function creates a series of tags on the Tags tab that reflect your outline structure, and allow you to reveal and hide various sections of your outline.
Regarding the issue of loss of formatting when paragraphs begin with an indent, this is just a characteristic of the Markdown format. See this note in the Markdown Guide for clarification. Let me know if I’m misunderstanding.
No, I think you’ve diagnosed it correctly. Thinking about it later, I realized it could just be a limitation of Markdown.
The issue arose when I imported (many) text files that had been formatted in InDesign and exported as utf-8 text files. They used a block style paragraph for main points with tab-indented paragraphs and a single return for main points with fine points.
I think that’s a little more sophisticated a format than Markdown supports, as you point out.
Still, I find it disturbing that the font changes and the lines don’t wrap. I’ll enclose a sample:
The problem is that, within the Markdown syntax, indenting a line implies that the line is to be treated as code, instead of regular text. And code is generally shown in a monospaced font. It’s not treated as a regular paragraph at all.
Had I been generating these files in Notekin, I wouldn’t have indented them. Although I’m not sure what I would have done. But the format was pre-existing.