Bike 2.0 (Preview 268)

Added

  • Added Bike > Interface Explorer
  • Added Bike > Extensions Explorer
  • Expand All / Collapse All commands (+ By Level)
  • ==mark== markdown syntax for highlight/mark formatting
  • Text semantics commands for move, delete, cut, copy, paste
  • Include more system level commands from Cocoa keybindings

Changed

  • Updates to inspector UI
  • Standardize status bar popup UI’s
  • Select All expands immediately to document scope
  • Moved Settings > Keybindings to Bike > Commands Explorer
  • Moved Window > Logs Explorer to Bike > Logs Explorer
  • Moved Window > Outline Path Explorer to Bike > Outline Path Explorer

Fixed

  • Sorting order
  • Ordered list numbering
  • Editor Filter context menu Cut/Copy actions
  • Focus out decoration action maintains scroll position

Extensions

Changes to extension-kit structure and location.

It’s longer a mono-repo that you fork and work in. Instead it’s a package that you depend on. Now includes tooling for unit tests and releasing extensions.

New location: GitHub - bike-outliner/extension-kit: Build tooling and API types for Bike Outliner extensions · GitHub

Download:

2 Likes

Big, and a bit messy release!

Heavy on features/changes. Docs and some polish still trying to catch up. Fingers crossed it’s mostly docs and polish going forward.

Crashes

I didn’t get many crash repots in last release, then I got a flurry last two days, but by that time I had changed enough code that it’s was a little hard to know what was fixed already and what was not. Please send crashes early and often!

Bike > Interface Explorer

Extensions add unordered features. Use the Interface Explorer to organize them:

(Generally drag and drop and click trailing edge buttons in explorer window)

  • Reorder/hide/show location items in the sidebar
  • Reorder/hide/show inspector items in the inspector (and group in tabs if wanted)
  • Make commands available to click on in titlebar
  • Make commands available to click on in statusbar

Bike > Commands Explorer

This used to be the Settings > Keybindings.

I also exposed a bunch of new commands from Cocoa keybindings. Things like text:move-to-line-end. The idea is to be able to see all potential commands when assigning keybindings. They might also be useful to extension which can perform commands via performCommand.

The new commands does make the Command-P pallet quite a bit more noisy. Use the new checkbox column in the Commands Explorer to include/exclude commands from the commands palette.

Text commands

There was a discussion in the forums regarding row block vrs row text editing behavior. I’ve added a bunch of new “Row: Text *” commands. Such as “Row: Text Move Up”. Test them out for more text editor like move/delete behavior. If you prefer them over the default behavior you can assign the default bindings to these new commands. I think the full list is:

  • Edit: Text Copy
  • Edit: Text Cut
  • Edit: Text Paste
  • Row: Text Delete
  • Row: Text Indent
  • Row: Text Outdent
  • Row: Text Move Down
  • Row: Text Move Up

And there should also be a corresponding “Block” version of each command.

Bike > Extensions Explorer

Use the extensions explorer browse/install published extensions, enable/disable installed extensions, delete extensions. You can still manually install extensions by copying them into the extensions folder, but the manager should make the whole process easier I hope. The new extension-kit includes scripts that submit extensions to the registry so they will show up when browsing.

Inspector UI

I’m trying to come up with a good/better inspector (right sidebar) UI. Goal is inspector items added by different extensions will look good together. I think I’ve settled on putting each inspector item in a Disclosure group. You can see that style in the calendar inspector, and in the published “Look Up” extension. This look isn’t enforced, extensions can present any UI they want, but I think it’s a good starting point and encourage sidebar extensions to follow the design unless they have good reason not too.

Building Extensions

I’ve moved all extension related code to:

Last week @complexpoint asked if the extension API was stable to start building on…

I said yes, and then started changing lots of stuff! Sorry! There will likely be a little headache updating to new setup, but actually API isn’t much changed. Lots of changes to extension-kit tooling. Any extension authors please ask dumb questions in the forums guilt free. I certainly would :slight_smile:


Previously the bike-extension-kit was a single git repository with everything in it. The pattern to use it was to create your own fork of the repository. Add your own code. Pull changes from the origin git repository for new releases.

The new bike-outline/extension-kit pattern is a bit more standard. The extension-kit is a package that your own package depends upon. You update using standard npm patterns, not by pulling from a repository that you forked. (The core and example extensions are split out into separate repositories, see below)

You can find the new extension-kit and documentation here:

If you have been developing an extension I think your best bet to update is to re-create the project structure from scratch like this:

mkdir my-extensions && cd my-extensions
npm init -y
npm install --save-dev https://github.com/bike-outliner/extension-kit
npx bike-ext new my-extension
npx bike-ext build

Next copy your existing extension code from the old project into the new project. Then npx bike-ext build --install and you “should” be ready to go, or have some hopefully not too big errors to deal with.

After that headache some nice new features including:

  • You can write tests for your extension
  • You can build and publish your extension for others to use

Previously the core and example extensions were included in the extension kit. They are now in separate repositories here:

In those repositories some useful things to look at:

  • In core bike.bkext has testing for much of the extension API (see how it’s used)
  • In examples tutorial is simplified and I added a new kitchensink.bkext with many examples
2 Likes

Re: ==mark== highlights:

        <p><strong>B<mark>old</mark></strong><mark> <em><s>i<strong>ta</strong>li</s>c</em> <code>c</code></mark><code>ode</code> <s>strike</s> <mark>highlight</mark> <a href="text">link</a></p>
  • Bold italic code strike highlight link

The above edge case seems to return the following:

- **B==old==**[ ~~*i**ta**li*~~[c]{em} c]{mark}ode ~~strike~~ ==highlight== [link](text)

What I see is some kind of fallback to [highlight]{mark} if there is overlapping markdown syntax.

For exmaple:

  • Bold highlight

will return

- **==Bold==**[ highlight]{mark}

How do i add new keybindings in the Command Explorer? I tried typing, e.g., cmd-shift-leftarrow, but nothing appears in the box.

You need to type those literal text characters c-m-d…:

cmd-shift-leftarrow

The best documentation is probably here at the moment. The reason it works this way (and not like other keybindings text views) is text gives a little more control (left vrs right command, etc). Plus Bike supports sequences. So in block mode you might make keybinding a a. Which means it only triggers when you press a twice in a row.

now i get conflicts with existing keybindings. i tried to just delete them but couldn’t.

That shouldn’t matter. Maybe I need to improve that messaging (ideas welcome), but your keybinding should take precedence. The warning is just so you know that your keybinding is overriding some other one.

1 Like

instead of “Conflicts with” could write “Overrides existing” or similar

3 Likes

The new extension system is working really well !

( Extensions in floating windows too. It opens up all kinds of things to have the outline and an extension display next to each other – the latter fully resizable and draggable, and the two views interacting with each other )

Many thanks for all of this – it’s invaluable.

2 Likes

( and very easy to install a working draft of an extension (from a zipped file) in Bike.app on someone else’s machine – I’ve just done that successully here, through Bike > Extensions Explorer ... )

1 Like

Oooh the “build extensions in the forked repo” always felt a bit odd to me. Glad we can now depend on the sdk explicitly!

Also, thank you for the ==mark== detection!

1 Like

thanks for this

Anyone been able to make sense of the Bike > Interface Explorer? It definitely needs documentation. I’m just curious if it makes any sense to people at the moment or not?

I just tried it; it’s quite cool and I think I understood it for the most part. I added a couple command buttons and everything seemed to work.

1 Like

I noticing a small glitch with the Text: Move Word Right/Left commands. It seems they are mapped by default to option-left/right. But they didn’t work for me until I overrode them myself with the same keybinding. Please see screenshot below.

Very neat !

I hadn’t noticed that …

(powerful, and nice quiet buttons for adding commands to Title bar and Status bar)

I noticed that the style for the “currently focused” index row seems a little wrong in this release, the background doesn’t change anymore so it’s hard to tell what’s currently highlighted. Here’s the default Bike themes in light/dark, but it’s a problem for all the themes I have installed.

Unrelatedly, I think the new explorers are awesome! I noticed the command window has a very noticable stutter when scrolling and filtering, not a huge deal though. I do wonder if the command explorer makes more sense inside the settings window, I feel like that’s where you’d typically see shortcut customization in other apps. But at the same time, I think separate windows are good ways to keep the settings from getting overwhelming. And most users probably aren’t going to mess with keybindings.

Yeah, that’s on my list :slight_smile:

Ah good! … and bad!

I’m building these views rather fast in SwiftUI. Still doesn’t seem like it should stutter, I’ll investigate.

In Settings, I tried to use “Document/New Document Format” set to “Bike Markdown” with Extension “md” instead of the default:

  • When I create a new document and try to save it, Bike HTML is still the default and I have to manually switch to the (newly created) “Bike Markdown (.md)”. I was surprised that there was a new entry and that you don’t just use .md for Bike Markdown. (Actually, I hadn’t noticed the new entry at first.)
  • I tried to save an old Bike document to the new Bike Markdown (.md) (with md-Extension) – but it’s not in the Save-As list. Also, I can’t manually change the extension in Save-As, it will end up as “filename.md.bikemd”.

A bug, looks like I broke this a while back when adding automatic naming from document content. Fixed for next release.

Hum, Bike’s always been a bit of a mess here. I think Save Panel behavior changed at some point. And it’s also generally a confusing situation, to much flexibility, but all of the flexibility has some uses cases:

First, Bike can read/write four formats:

  1. Bike HTML (.bike)
  2. Bike Markdown (.bikemd)
  3. OPML (.opml)
  4. Plain Text (.txt)

The whole point of basing off HTML and Markdown is so that Bike files can participate in larger ecosystem. But Bike’s versions are specific subsets. Bike can express this using macOS Universal Type Identifier (UTI) system, but much of ecosystem uses only file extensions, and that’s where trouble is.

Cocoa save panel isn’t really designed to work this way as far as I can tell, so it requires odd customization. Plus it makes read files more difficult. If Bike is passed a .md file it needs to determine if it’s a .bikemd or a more general .md. And then decide what to do. Options are lossy open as .bikemd or open as plain text.

Anyone know of other apps that have this situation? Would be useful see what they do.