Getting close to done I think. Still some bugs to investigate, but I don’t think any more big chunks of code to write.
Few thoughts on this release:
I added back strikethrough formatting for done tasks. It is un-needed, in that the tasks already have the checked box, but I still think it looks a little better this way. In some future should be customizable with stylesheet.
I have also tried adding visual marks to types, so that you can tell the difference between, say a quote, and plain italic text.
The logic goes:
notes get a “marker” decoration, similar to list items, because that’s what’s simplest.
quotes get a vertical bar, because that’s the standard.
code gets background color because that’s also a bit of standard.
I’m still not 100% certain about visuals, but I think they are better than not having any. Of course let me know what you think.
With notes, I like the little icon to remind me which is which. Works for me.
The vertical bar is standard everywhere I work, so I like this a lot.
I don’t code
But I’m back to loving the strikethrough. Though redundant when I have a long list of tasks in no particular order the strikethrough makes draws my eyes immediately toward those things I still need to do. Much better visual clarity (for me).
(I think I might personally prefer slightly quieter marking for notes – that icon feels a bit polyphonic; it contains a number of different contrast edges – but perhaps any style system that you develop later on might allow for some relative muting of that kind ?)
Generally I picked it because the apple symbol name is “note.text”.
In truth I haven’t total figured out what note will be used for. One one hand we have notes attached to headings in some outliners, and they are generally quiet. On the other hand we have sticky notes and “info” blocks added to documents, and they are generally louder.
Mind mind was kinda going in the sticky note direction. I was imaging maybe adding a type attribute (info, warning, etc) down the road and then setting background color based on that. Or no background color if no attribute.
Any thoughts? Or it may make the most sense to not add it at all until I have a more clear idea of what it should be used for. Anyone have thoughts? I don’t think it’s essential that I add now, it was kinda an extra type just to remind myself that types could be anything, didn’t need to be markdown elements.
(Not sure whether there are any users who might want to use the note row type to flag lines which – with their descendants – would be exported to the OPML _note attribute, for display in mind-mapping apps like iThoughtsX and MindNode, which both use it)
Though generally I would have thought that access to structure:
I had been envisioning notes would be a single row, with maybe multiple wrapped lines. When repeated over multiple lines, I agree it’s way too busy. I think I will keep note type, but just use a style similar to OmniOutliner to distinguish it. No icon.
I think I will also dial back the code block formatting. Grey background spacing isn’t quite right, and not really possible to get right without more work on styles system. Later when styles are more powerful I will try again to make things a little more chunked and distinct.
“Done” status is represented as a row level attribute. It can be set on any row, and that row will be considered “done” and get strikethrough formatting. Task lists just add a checkbox to toggle this done state.
I like this model, but I think it’s a little confusing in Bike’s current form, where there are not visible tags. You can tell that a row is done because of strikethrough, but it might be a bit hard to figure out how it got that way.
So right now I don’t really want to have non-task rows marked as done…
The issue is that if I add a “toggle done” command I’m not sure if I should constrain it or not. Should it only work on task list items? Should it convert current time to a task list item? Should it just do nothing if the selected rows are not tasks.
Or should I ignore the problem and just not add that command (what I’ve been doing so far)
I think what I might do is add a spacebar keybinding to outline mode that toggles the done attribute. It will work on all selected rows, just toggles the “done” attribute. Won’t change any type. So you’ll be able to easily checkoff things from keyboard, but feature won’t be advertised in menu item yet.
I think this version is getting close. Maybe have a release sometime late next week. I’ll be off camping for a few days later this week. Do let me know if you see any bugs that I’ve missed.
@jcb Do you still see it? I definitely see it in your screenshot. I don’t see it on my Retina display when I set it to non-retina resolution in system settings. I also looked and at least on first pass the code that draws those marks seems to be doing the right thing… problem is I don’t remember actually changing anything… anyway let me know what you see please.
This is what I see on my 2020 MacBook Air M1 Retina display
Then moving the window onto that same 1920x1080 acer monitor I get
While typing this response up I also noticed the big size difference between the screenshots, and decided to play around with the font size on the acer monitor, and lo and behold:
After holding command and pressing + once:
After holding command and pressing + another time:
Finally holding command and pressing + one more time:
It’s sharp! or at least sharper It seems to be when I’m ‘between’ font sizes or something everything takes on blur. It’s like every couple increments it’ll snap into sharp-mode.
For example shrunk everything way down and it was crisp todo-boxes:
Since you asked for any outstanding bugs, I did notice that pasting plain multi-line code or text into a code block keeps the first line as code but makes the rest of the lines formatted as regular text. For example, pasting the following lines into a code block
