The general idea is that you’ll have a list of themes. Choose a theme and it will apply to all open documents by default. There will also be an option to apply to a single document. So possible to have multiple documents open, each with own theme. Themes will also be remembered as part of window restorable state.
Themes will have most of the settings which are currently in Bike’s Settings > Editor panel. So visual things like colors and fonts.
I’m also considering that other settings such as text wrap, typewriter scrolling, and focus mode become part of themes.
Themes will also eventually have (not in first release) custom styling that you can set using outline paths. For example you might have a rule that says any row that matches the outline path //heading should be colored red.
In the end a theme is really a big collection of settings. Changing a theme changes all those settings at once.
Before I get too deep into this… feedback is welcome. Does the above sounds like a good picture to you? Or are there things that you want themes to do that aren’t compatible with the above. Let me know what you want!
That would be even clearer than how it is now (even though the two last ones are true today as well), and also that every symbol is different. I especially like the clarity when you have all three symbols, like with Sibling 1, Child 11 and Child 12.
(I’ve been trying to work on a little animation that animated between a circle and the triangle, as that would be nice. But I haven’t had the time.)
But I saw that you don’t like that idea yourself, hehe - so that’s why it would be neat if it was theme-able.
Lastly, I don’t know if this is outside the scope of your work now, but I’d like the Logseq plugin called “Bullet Threading” to be copied.
Yes, I expect this will be possible when I add ability for custom style rules. Basically you will write an outline path that matches code runs and then list out styles to apply such as font and foreground color.
This is the system where that setting would go I don’t know that it will be a focus in first few iterations, but please keep up with the requests once I have most everything else in place, and then I expect I will do it.
Interesting… though this is probably less likely. At least that particular visual would be tricky to implement as part of the style system. One thing that it hints at though is rules that incorporate current editor state (selection) instead of just outline model state. I do think that will be possible. So for example maybe you don’t see the blue loops, but you do sea the ancestors of the selection in a different color.
Yes, that would be much more possible. It’s a little hard to say for sure what I will have time to implement before something else takes priority, but that would fit pretty well into the style system I think.
This sounds great. I just want to add that I’d like a GUI. I don’t want to have to write in a subset of CSS or some such (nothing against CSS, I love it). I’m just lazy and want it to be easy like the rest of Bike!
I’m not sure. TaskPaper used a CSS like stylesheet, but with many small differences. I think that just ended up confusing things. At the moment my plan is to configure in GUI and save as JSON. So in theory you will be able to edit in text editor, but generally it will be GUI. That’s the theory anyway
other settings such as text wrap, typewriter scrolling, and focus mode become part of themes
I wonder if this scope might be overly complicated/annoying. I can imagine myself wanting to change colors & fonts & such way more often than wanting to change wrap & scrolling & focus mode, and would not like to have to check &/or fiddle with such things every time I changed theme.