3 ms·

i just tried it and i cannot figure out how i use media with the app. even just a simple embedded image i cannot get to work (i never see the image). drag&drop

by bosie 7y ago

i just tried it and i cannot figure out how i use media with the app. even just a simple embedded image i cannot get to work (i never see the image). drag&drop an image from firefox into a note doesn't work either (nothing happens after i drop it).

fabiospampinato 7y ago
That part of the app is a bit rough still, that kind of drag & drop interaction isn't supported yet. If you're under macOS you can copy/paste images to attach them. Otherwise you can add attachments by clicking the attachments icon (the little clip) and then clicking "Add attachments...", and then link to them via the special `@attachment` token mentioned in the tutorial [1]. Or you could have an attachment wherever you want in the file system and link to it like you normally would inside Markdown. [1] https://tutorial.notable.md/ https://tutorial.notable.md/
- bosie 7y ago
  indeed, i am on a mac. i dislike the attachment solution since that is a vendor lockin and you were mentioning lack of that. if i use attachments and special virtual paths like "@attachment" i restricted from editing my notes with anything but your tool. ios is then obviously gone too. This defeats the purpose of being dropbox-syncable (or at least reduces its usefulness).
  - fabiospampinato 7y ago
    Well you don't have to use that if you don't want to. The "@attachment" (and "@note") thing is actually pretty useless today, but it will solve a real problem tomorrow, namely: how do you make links always work even if the resource they are pointing to gets renamed? Which is worth solving IMHO.
    - bosie 7y ago
      Why would you need an attachment for this? Couldn't you 'refactor' the notes instead? Not sure that vendor lockin is worth it. The problem is worth solving but IMO you are going about it the wrong way.
      - fabiospampinato 7y ago
        You might be right, but it's not as simple at it sounds. By using something like `@attachment/UUID` you don't have to refactor anything if the attachment gets renamed or modified. The somewhat unsolved issue there though is reliably keeping track of which UUID maps to which file. If you're using regular links and rename an attachment, worst case scenario, you have to parse all notes, find all links pointing to the renamed attachment and update those, which can get expensive. Also regular path-based links can be a problem when you move the _note_ somewhere else too. Plus how do you know something got renamed instead of the old attachment got deleted and a new one got created? This is partially a problem for the UUID-based approach too however. Lastly what kind of link should you use to link to a note stored in another data directory? Relying on the absolute paths is too brittle, and it won't work at all when the app will also be able to run in the browser.

by bosie 7y ago

fabiospampinato 7y ago

That part of the app is a bit rough still, that kind of drag & drop interaction isn't supported yet. If you're under macOS you can copy/paste images to attach them. Otherwise you can add attachments by clicking the attachments icon (the little clip) and then clicking "Add attachments...", and then link to them via the special `@attachment` token mentioned in the tutorial [1]. Or you could have an attachment wherever you want in the file system and link to it like you normally would inside Markdown. [1] https://tutorial.notable.md/ https://tutorial.notable.md/

bosie 7y ago
indeed, i am on a mac. i dislike the attachment solution since that is a vendor lockin and you were mentioning lack of that. if i use attachments and special virtual paths like "@attachment" i restricted from editing my notes with anything but your tool. ios is then obviously gone too. This defeats the purpose of being dropbox-syncable (or at least reduces its usefulness).
- fabiospampinato 7y ago
  Well you don't have to use that if you don't want to. The "@attachment" (and "@note") thing is actually pretty useless today, but it will solve a real problem tomorrow, namely: how do you make links always work even if the resource they are pointing to gets renamed? Which is worth solving IMHO.
  - bosie 7y ago
    Why would you need an attachment for this? Couldn't you 'refactor' the notes instead? Not sure that vendor lockin is worth it. The problem is worth solving but IMO you are going about it the wrong way.
    - fabiospampinato 7y ago
      You might be right, but it's not as simple at it sounds. By using something like `@attachment/UUID` you don't have to refactor anything if the attachment gets renamed or modified. The somewhat unsolved issue there though is reliably keeping track of which UUID maps to which file. If you're using regular links and rename an attachment, worst case scenario, you have to parse all notes, find all links pointing to the renamed attachment and update those, which can get expensive. Also regular path-based links can be a problem when you move the _note_ somewhere else too. Plus how do you know something got renamed instead of the old attachment got deleted and a new one got created? This is partially a problem for the UUID-based approach too however. Lastly what kind of link should you use to link to a note stored in another data directory? Relying on the absolute paths is too brittle, and it won't work at all when the app will also be able to run in the browser.