Bike’s most original feature is the “fluid” text editing. Lots of text editors have animated some interactions (cursor movement, insert newline, etc), but I think Bike is the first designed from the ground up to support fluid editing.
Give it a try, it feels different. (movie on home page if you don't have Mac)
Other Features:
• In text mode Bike works like a normal text editor. In outline mode rows are constrained to outline hierarchy.
• .bike file format is HTML subset, so files are easy to parse and manipulate. Bike also supports .opml and .txt.
• Scriptable via AppleScript. Javascript plugin API also expected in future, though no timing on that.
• Architecture needed to support fluid editing also makes Bike faster/more scalable than most (all?) outliners and many text editors. I test performance using the Moby Dick Workout[^1].
Implementation Notes:
• View is built using CALayers[^2].
• Animations are performed by Core animation and Motion[^3] lib.
• View performance is determined by visible text, not document size.
Model representation is interesting in that it’s just a flat list of rows. Each row has a `level` property, outline structure is determined dynamically. View implementation requires that each row has a unique ID.
I’m using OrderedDictionary from Swift Collections[^4] to store rows. This is Bike’s performance bottleneck for large outlines. Eventually I may change to augmented b+tree and then should be able to work with gigabytes worth of outline. That will be fun, but not sure it’s actually needed. Already probably fast enough for 99% of use cases as is.
Hope you find Bike interesting. I’m happy to answer any questions.
[^1]: https://www.hogbaysoftware.com/posts/moby-dick-workout/
[^2]: https://developer.apple.com/documentation/quartzcore/calayer
[^3]: https://github.com/b3ll/Motion
[^4]: https://github.com/apple/swift-collections
Give it a try, it feels different. (movie on home page if you don't have Mac)
Other Features:
• In text mode Bike works like a normal text editor. In outline mode rows are constrained to outline hierarchy.
• .bike file format is HTML subset, so files are easy to parse and manipulate. Bike also supports .opml and .txt.
• Scriptable via AppleScript. Javascript plugin API also expected in future, though no timing on that.
• Architecture needed to support fluid editing also makes Bike faster/more scalable than most (all?) outliners and many text editors. I test performance using the Moby Dick Workout[^1].
Implementation Notes:
• View is built using CALayers[^2].
• Animations are performed by Core animation and Motion[^3] lib.
• View performance is determined by visible text, not document size.
Model representation is interesting in that it’s just a flat list of rows. Each row has a `level` property, outline structure is determined dynamically. View implementation requires that each row has a unique ID.
I’m using OrderedDictionary from Swift Collections[^4] to store rows. This is Bike’s performance bottleneck for large outlines. Eventually I may change to augmented b+tree and then should be able to work with gigabytes worth of outline. That will be fun, but not sure it’s actually needed. Already probably fast enough for 99% of use cases as is.
Hope you find Bike interesting. I’m happy to answer any questions.
[^1]: https://www.hogbaysoftware.com/posts/moby-dick-workout/
[^2]: https://developer.apple.com/documentation/quartzcore/calayer
[^3]: https://github.com/b3ll/Motion
[^4]: https://github.com/apple/swift-collections