trilium
trilium copied to clipboard
zadam
RFC: Image support re-design
Problem statement
Image support in text notes is one of the core features of Trilium or any other note taking application. However, the current way of working with images is a source of pain, especially for new users, because of its un-intuitive behavior.
Trilium has had a design philosophy “everything is a note” where “note” should be understood as an object placed into the note hierarchy. As a result, image is a note of type “image”, is placed into a tree, can be moved around, cloned etc.
When user drags & drops an image into Trilium, the image is uploaded and an “image” note is created directly below the current text note. Because this creates “messy” image structure, Trilium has a feature which by default hides such images from the tree. But they are still there, waiting to produce unexpected results and confuse users.
Here are some of the cases where things go wrong:
- user wants to protect a single note (encrypt it) by toggling the button. User might get surprised that only the text is encrypted, but not the image - the image is a separate note and must be encrypted separately (or via encrypt subtree).
- user copy & pastes an image into a different text note in some other part of the tree. Several things can go wrong:
- user exports a subtree, but since the referenced image is actually sitting in some other subtree, the image is not included and the reference is broken
- user protects a subtree, but the image is outside of the subtree and thus not encrypted
- user shares a subtree, again the image is outside of the subtree, so it is not shared and thus results in a broken image
- user wants to see note revisions, but sees that only text is revisioned, images not, so user might see a wrong version of image or perhaps a broken reference (image has been already erased)
Solution proposal
Trilium will introduce a new object - provisionally called “note attachment” with these characteristics:
- each attachment is wholly owned by a single note.
- it's not possible to link one note's attachment to another note. If you want e.g. same image in the other note, it will be transparently copied (not just linked) over to the other note.
- attachments are shared/protected/versioned together with the note. It's not possible that the note is shared/protected and the attachment isn't (or the other way round).
- attachment has a name, role, (mime) type and the content (binary, text)
- note can have multiple attachments. Attachments don't form a hierarchy, it's a simple list.
- attachments will be accessible by a special UI/dialog, but this UI will not be very prominent. Attachments are meant to manifest themselves outside of their dedicated UI, for example, an image is visible directly in the text note.
An “embedded” image will be one use case of these attachments. The user will have the option to use either the old system (image is a note placed into a hierarchy which you can link in your text notes) or the embedded images and switch between them - user can “pull up” an embedded image into a note or embed an "image note" into the note. The embedding approach will be the default one. A migration will be created which will convert all suitable images into the embedded ones (= image which is referenced by its parent text note, currently it's hidden from tree by default).
A further benefit is that note revisions will encompass the attachments, and thus you will be able to see the state of the note in the past, including the images.
A feature currently called “Hide images included in a note” will be removed, since the same use case will be covered by the embedded images.
Questions? Remarks?
Questions or remarks are welcome.
Naming is as usual difficult:
- "attachment" seems to express the idea relatively well. One of the possible use cases in the future would be to allow generic file attachments (similar to e.g. emails)
- I also like the verb "to embed", but the noun "embed" or "embedding" is quite strange sounding.
- Not sure if using both makes sense "to embed an attachment".
What troubles me most is that the image does not moved with note content in the current design. I use Cut & paste selection to sub-note to split large notes into smaller ones for easier search. The image note becomes visible, and stays in the same level of the new sub-note. I had to drag it under the new sub-note and ctrl + r to refresh the frontend to make it invisible again.
Looks like the new design will amend this little flaw.
Yes, this would be fixed. The image would actually get "physically" copied to the subnote's attachment in this case.
The idea doesn't sound bad :) Though, I feel ok with the current way of things. I actually like that the images are notes on their own, and I can put them anywhere I want to reference in different notes without having to make physical copies, and if I update a certain image - it gets updated everywhere.
@XXXJetfireXXX this possibility will remain. Default type of storage of an image (separate note / embedded image) will be action dependent:
- when user drags an image into the text, it will be imported as embedded image
- when you import an individual image by dragging it into the tree or using the import dialog, it will be added as a separate "image note"
You will be able to "unembed" an embedded image, and vice versa.
@zadam And for leaving both options and letting users choose the one they prefer, I respect you :)
A migration will be created which will convert all suitable images into the embedded ones (= image which is referenced by its parent text note, currently it's hidden from tree by default).
Though I've got a question about this part: will it affect the image notes that are currently referenced by their parent notes and hidden, but are also referenced somewhere else? Will the 'external' links get broken?
but are also referenced somewhere else? Will the 'external' links get broken
No, they won't. Images referenced from 2 or more notes will not be embedded in the migration.
Thank you for being very responsive, this update will greatly improve Trilium and ensure its stability. I hope that the integration of attachments in the notes will also concern files of all kinds and not only images!
This is an excellent feature! I have one question: Can it be used in custom widgets? Or do you have the plan to organize the assert of html to be "note attachment" as well?
I have one question: Can it be used in custom widgets?
There will be a script API for that, yes.
Or do you have the plan to organize the assert of html to be "note attachment" as well?
Not sure what is meant by that, but the main note's content (HTML or a different type) is not going to be an attachment.
Not sure what is meant by that, but the main note's content (HTML or a different type) is not going to be an attachment.
For example, can the font files of css theme be attachments as well?
For example, can the font files of css theme be attachments as well?
Yes. Not sure if in its first iteration which might be focused on images.
@zadam Hello, I would also like to integrate files (video, PDF, executable...) to a specific note without these attachments becoming separate notes.
Will the other attachments also be able to be integrated to specific notes? (This is very important for me)
Sounds like a great proposal to me. A couple benefits i see:
- Imported notebooks with photo/icon attachments will be much cleaner. For example, when i imported onenote notebooks via an Evernote export, many of the original onenote tags were converted into images which resulted in hundreds of 'attached' images cluttering the note tree - for some reason these 'image' notes were not hidden.
- Deleting images from notes won't leave 'image' notes behind anymore. (Currently if you delete an image from a note, the (previously hidden) 'image' note re-appears without the user knowing:
Screenshot of note with attached picture:
Screenshot of tree after image is deleted from note:
I can't wait until the attachment problem is fixed and we can integrate them without separate notes. Is there a release date for this fix?
I look forward to being able to attach my files directly to the notes without them creating their own notes. I hope this feature will be released soon!
Hello. Thank you for your work. Until now I've been using Joplin. I would like to use Trilium but I don't know when this update will be available, because I don't like attachments creating their own notes. I'd like them to be integrated directly into the main note (I'd like to attach mainly videos and PDF documents).
Do you know when this corective will be implemented?
@Love-Ukraine I've also been waiting for this update for several weeks. For the moment I'm using CherryTree, but as soon as trilium has this update, I'll migrate my entire cherrytree database to trilium!
As far as I'm concerned, this business of files creating their own notes is the only reason why I don't use Trilium. I hope an update comes out soon!
First beta likely within a week.
Hello, will this very important feature soon be released on the main branch?
Hello, I'm looking forward to this feature, can you tell us when it will be released?
There's a 0.61 beta containing this. Stable will be released when it's ready.