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.
Cool! I’ll definitely try to be a voice for the “triangles means children” crowd.
Do you mean something like this?
(Here I took the colour of the typing indicator, which could be like an accent colour, and coloured the ancestors in that colour. Or to be specific, a more muted version of that colour.)
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.
From other apps I have come to think of themes as purely styles and colors.
What if there was another, optional layer above themes. Call it, I don’t know, “workspace”? Where you can select a theme plus other settings, and save all these selections under that “workspace”?
I understand that Bike 2 is introducing stylesheets, which will make theme-toggling much more straightforward.
In the meanwhile, I am personally using an AppleScript in this pattern:
Expand disclosure triangle to view AppleScript source
tell application "Bike"
set white to ((255 / 255) * 65535) as integer
set black to ((1 / 255) * 65535) as integer
-- COLORS
-- Black ink on white paper
set light to {{white, white, white}, {black, black, black}}
-- Chocolate and orange.
set dark to {{8736, 8736, 8736}, {65535, 51656, 37008}}
-- TOGGLE
set {nBack, nFore} to {foreground color, background color}
if (item 1 of nBack) < (item 1 of item 1 of dark) then
set {background color, foreground color} to dark
else
set {background color, foreground color} to light
end if
end tell
(with the elements of each {R, G, B} value expressed as integers in the range 0 … 65535,
based on n/255 values sampled with, for example, macOS Digital Colour Meter)
But I haven’t had the time.)
(I would use it to differentiate headings and bold text.)
