Thanks a lot for `Window.subtitle`. Though, could you elaborate on why subtitle is added, instead of making title writable? That would allow more flexible title display, instead of just {title} - {subtitle}.
It should now, but I think there is no element in that inspector that’s taking keyboard focus. For example I “think” if you make an extension that puts a text field in the inspector, then that text field will be able to get keyboard focus. I think the calendar just doesn’t have any element that uses keyboard focus.
Title is used by macOS document based architecture to show filename. Icon, maybe edited state. I think when a document is attached to a window, the title becomes a bit of a black box that I don’t want to override.
Subtitle on the other hand (also a native NSWindow setting) isn’t used by document architecture. So I’m pretty sure it’s safe to modify anyway you want, with out the possibly that it will be messing anything else up.
Just updated. I haven’t seen any crashes yet, but wanted to toss out some ideas I had regarding extensions.
Is it possible in extensions to open a file, or navigate to an open tab? Example use case would be, I have a “journal” extension that allows me to create an entry for today or a past date, and it would be nice that when I execute the command, it automatically switches to my Journal.bike file.
Is there any ability to search across multiple files? E.g. if I wrote about a certain topic somewhere, but I’m not sure where, I could search either across all headings or all text in my Bike folder. I can already do this externally via the ripgrep terminal utility, but might be nice if I could do this in Bike.
I don’t think this is possible now, but I agree it would be useful. I’ll add some activate functions that do this for windows, panels, editors, etc.
Currently there is API to open URLs. So if you pass in a file:// URL to that API and it points to a Bike document, and Bike.app has read access to that location (Bike is sandboxed, so no for most locations)… then you can open a document that way. But that’s not a very controlled or reliable route…
On the other hand if a document is already open, then your extension can see that document, and activate it, once I post the next release with the new activate API.
No, other then having them all open and then the extension can iterate through the open documents and search each associated outline individually.
I think eventually I will add a new Folder/Workspace document type to Bike. Then you can open that folder and easily access all contained outlines. And I will likely implement a workspace level search. But that’s down the road, not something I have started working on yet.