Image / file attachment support?

Hi Jesse, thanks for your work here. I’ve been looking for a good outliner tool and I’m excited to try Bike out.

For me image support is very important, and when I saw that you said the format is a subset of HTML I thought images might be supported in this first version.

When I tried pasting an image in, the app hung then crashed:

After I tried pasting in a much smaller image, I noticed that it was pasting the binary image contents as text, so the previous crash was probably exhausting a buffer somewhere.

I’m curious – is image support planned for a future release? Thanks again for all of your work!

1 Like

Image support is on my list, or really I would say attachment support with a thumbnail is more likely how I would implement it. With that said I don’t want to promise it at this point. The tricky part is attachments and text files and macOS sandbox don’t work easily together. To make it work I’ll likely need to define a new bundle format, possible, but maybe a chunk of work that’s hard to finish.

7 Likes

Thank you!

+1 for image support!

+1 to image support. I copy/paste screenshots (shift-cmd-option-4) into my other apps like Notes, and would love to have same in Bike!

This app would be perfect with at lease in-line images addition possibility. I’m a university student and the schema if Bike app is basically a conceptual tree in which you can go deeper and deeper in the details of what you’re studying. The addition of screenshots of lectures or other graphical stuff would make this app the perfect app for every student.

Thank you for the work you’re doing!!

2 Likes

The recent thread about introducing additional “row types” made me think about image support again. Having used Bike for a year now, this is still something I regularly think about and would find very useful, though it does seem like a big feature to implement coherently.

I wrote a small note about the part of the problem to do with the HTML-based file format, though reading Jesse’s comment from earlier in this thread again, it seems there might be deeper issues at play here. Figured I’d leave the note here in case it’s helpful, anyway.

Thanks for the note, and I don’t know, data urls might be a good option. The options to investigate are:

  1. File bundle like .rtfd. Include attachments in the bundle where bike will have full read/write access. The nice parts of this area generally files travel nicely with file, content part of file stays small, and it’s a well known and tested approach.

    Drawbacks are it means another file format to support… .biked. In theory this shouldn’t be too hard, but I haven’t actually done it yet. Also there may be well known problems/complaints with the rtfd approach that I don’t know about.

  2. Bookmark based file attachments. Instead of just storing a URL also store extra sandbox information indicating that you have read/write access to that file. Nice thing about this approach is you can link to files where they are, you don’t need them embedded in .biked bundle. That’s also a weak part of this approach, since it means you have to keep everything together yourself … can’t just copy a single file, need to copy the Bike outline together with linked too files. Also I’m not sure (I expect not) that the bookmarks will work when synced to another computer.

  3. Data URL approach. This would be the simplest for implementation and would sidestep the sandbox nicely. I’m not sure about scaling, a few big images might start to slow down read/write time of your outline. Maybe most important I think this approach would mean the linked to file wasn’t really editable by other applications after you added to Bike.

  4. Last approach to think about is “Workspace” approach. This is similar to the bundle approach (.rtfd, .biked), but instead of embedding files with a particular outline … you have a workspace folder, and put all your outlines and attachments into that workspace folder hierarchy. Then you have Bike open the top level folder and it will have easy access to all the files inside.

    Generally I think this last approach is the most robust and flexible. The problem is just that it’s a lot of extra work to build out the UI for the workspace. I would want a file browser sidebar and things like that.

So in the end this is all still a work in thought process, but adding row types is an important first step, so the fact that that’s what I’m working on now brings attachments a little closer, even if they are not right around the corner.

5 Likes

Chiming in to cast an aye for attachment support.

Thanks for your work, Jesse!

I was going to say the same [that I too wanted img support please], but then I remembered the (rare) promo Jesse had for Hookmark. Long story short, I had a PNG I wanted to include in Bike, so I created a folder under where I store my Bike files, called attachments/ and put the PNG in there. Then installed Hookmark (free for 30 days), focused on the file in Finder, clicked Hookmark in the menubar and it copied a hooklink to the PNG. Went to some text in Bike, added a link, pasted, and now in Bike if I click the link, up comes the attachment.

This is SO extensible, clearly you can link in this way to any resource anywhere (almost).

PS: after copying the file to my attachments/ folder, I opened “Sandbox” pref in Bike and added that location – I am not certain that was needed/correct, but if I understand Sandbox here, it allows Bike to tell MacOS - I should retain access to this location.

I think adding that location will make the link a little easier, though maybe it’s not strictly necessary…

  1. Without Sandbox permission then when you click on a link to a file Bike will reveal the linked to file in the finder.

  2. With Sandbox permission then when you click on a link to a file Bike will activate (open) the linked to file and it will be opened in associated apps.

I think behavior #2 is nicer, but #1 is also passable.

The reason that I really added Sandbox permission is because if you are creating “bike://” links to specific rows in an outline… then those links will only work if the file is stored in a location that Bike has Sandbox access too.

The issue is Bike needs to do a spotlight search to find the file by a unique ID. If Bike doesn’t have Sandbox access to the file, then the file just doesn’t show up in results, and so Bike can’t do anything with the link.

Hope that helps… thought I could also understand if it just confused! :slight_smile: This issue is a bit of a complex mess.

It does help - thanks Jesse :slightly_smiling_face:

1 Like