Below matrix shows attachment related operations in Joplin, on 3 different platforms (desktop, iOS and Android), add / see / retrieve / remove ... and their limitations. It's a summary, a first shot of my testing and playing with it. Unfortunately I do still see a lot of areas for improvement. I believe attachments and their "easy" and proper handling within an app are vital to notes taking.
Please comment and share your experiences. One or the other table entry could be wrong, or not the same in your environment. And if a table entry isn't clear, please ask.
Do also start by reading rows 20+ first and before trying to interpret the table.
Imagine I add an attachment to my desktop db, sync it later with my Android device. In this case I want to be able to retrieve the identical, unchanged file from the db on Android and store it (e.g.) on the SD card of my Android device.
Ok, so what does that mean in regards to the "not implemented" on the lines against desktop and Android pic?
You mentioned in the example that the idea is that you "create" on desktop then "retrieve" from Android having synced over the shared folders but I'm not sure which of your testing cases are "local" vs "cross platform" if that makes sense.
Doesn't matter to me. I want to attach it anywhere and retrieve it anywhere I want, with the original file name, extension and other attributes.
The "not implemented" entry has to be seen in context of how I started my tests. Running, desktop, attaching files of different types ... and realized I cannot save them back to my SSD. Simple example, you add a picture to a note (column B = ok), you see it immediately within the note (column C = "inline"), you try to retrieve it (e.g. with a right click or with a menu command) and ... uuuuups ... you can't. (column D = not implemented).
I'm not having a go at what you have done, I'm trying to make sure that if I try to repeat it then I'm actually doing the same test as you, no need to be annoyed at me.
Also trying to make sense of that example, what is the difference between what you have labelled as "bug" and "not implemented" on the Android "retrieve attm" section? It sounds like you are saying that right clicking and saving is not doing what you expect it to do (on desktop) which sounds like a bug rather than intentional design.
Yo are right, edited it already not implemented should be easy - it is not "there" bug means you can (one way or the other) start the process (e.g. save the file, get a dialog box, etc.), but for some reason you do not end up with the expected file on your SSD,
OR that you can save the file, but it has changed, and is corrupted in one way or the other.
Back to the desktop / picture example: when I do a right click on that picture (within Joplin) exactly nothing happens. All I can do is select the picture.
So I did a bit of my own testing and came up with the following for the Android Mobile App (Android 10, Joplin 1.5.1) and the desktop app (Windows 10, Joplin 1.5.14).
I've put text as green for expected results, blue as functional but not ideal and red as something that doesn't seem possible/desired functionality.
Thanks for your inputs :
I can't say anything about windows, but between Android 8 and 10, I guess, one should see the same behavior more or less. So for a little cross-check I focus on your "Android App only" rows. Our tables agree in the add column. In the view/save columns, I can tap on each file type of course, here is what happens :
text > Android offers to open the file in a built-in html viewer, from which you cannot save the file + one cannot save it from within Joplin,
picture > no response at all,
binary > Jopiln proposes "OPML import" (whatever this is), and a few even less usefull options (my phone app ?), but no way to save the file.
So for me ... three red marks in this column.
In the two remove columns, we agree again on the finding, but I wouldn't mark the result as green, whether intended or not.
I marked the remove ones for the MD editor as green as that is exactly the behaviour I would expect, seeing as it is a 'pure' text editor. Notice that in the WYSIWYG I put blue because I would expect it to behave more like an 'object' than text.
I think your issues with attachments (txt and bin) are more down to your phone than Joplin, it seems you simply don't have the correct applications needed to deal with the files. For example if I click on a .txt attachment I can choose to open it with Total Commander and save it wherever I want, you simply either don't have a default app for dealing with the types of files you are attaching or have one configured as default which doesn't offer the functions you are looking for.
I appreciate the insight, I don't think it addresses the problem (or let's say all listed problems). Don't want to go through all the "boxes" again one by one. But take the bug marked in C16 of my original matrix ... what shall I say ...
But I am happy to rename "bug" into "major inconvenience"
I wonder if a good feature would be that a long press of the attachment would open android's share menu rather than relying on file type associations (i.e i think it reasonable to expect somebody to have an app opening by default for certain file types but they might lack the ability to share or save).
I'll think about all of this again tomorrow, ... we are approaching a new year here in Western Europe, just 2 hours to midnight ... So, all the Best ! Make sure you get a good "new" one, from the start, not a "used" year
step 1, desktop findings (or : comparing Win and Mac):
it would have never occurred to me that the choice of editor might influence the handling of attachments, since I have exclusively used Joplin with wysiwyg, this explains some of my (correct !) table entries under "desktop". It is also correct that when I switch to the MD editor, the right click pop-up menu works.
Caveat: while (you find that) under Windows the results are the same with both editors, this ain't the case under Mac: the right click pop-up does not work in wysiwyc. Conclusion: the entries D5, D6, and D7 change from "not implemented" to "bug".
Next, I do still consider the fact that a text file is shown as a link (entry C5 in my table) as sub-optimal (you found the same under Win). Ideally, the wysiwyg editor should show the text (inline) just a a picture is shown (inline), or if the text is too long, show the first couple of lines.
Will get back with comments on Android and iOS later.
step 2, findings for iOS:
after review I still think my table is fundamentally correct, the bugs are for real. A few more details follow. All files on iOS are either located through the 'files' application, or photos. This of course has it's own built-in limitations. Nevertheless,
one should be able to add / view / retrieve or remove a pic, a txt, or a binary file.
On entry B12 (see original table), binaries cannot be selected from within Joplin to be attached (greyed out). So there is no need to think about other operations.
Pictures work fine when it comes to add / view and retrieve. What isn't ideal, there is no feedback after selecting "save image". You don't know it worked until you open your camera roll, and the file name is lost in the process. Another (minor) problem with pictures. If you edit an entry's link string by accident it cannot be restored and it is unclear what happened to the picture. (note: unlike the situation on the desktop).
Text files (entry D10 of the table), one can add and view text files. Like on desktop, it would be nice(r) if one could see the text or at least the first few lines. Anyway, when you choose 'share' from the iOS text viewer, and select 'save to files' ... the file name is lost in the process and replaced by a long string (prob. the ID# of the attachment + ... and the extension txt). No problem if you have few files, just one file to retrieve and all in just one location. But hopeless in many other cases.
The fact that you can remove the link to an attachment, but not the attachment itself has me wondering a) whether this way your db might grow bigger and bigger (if sync does not remove the attachments later ?), and b) whether a sensitive file stays forever in your (iOS) database and there was nothing you could do about this.
The fact that you can remove the link to an attachment, but not the attachment itself has me wondering a) whether this way your db might grow bigger and bigger (if sync does not remove the attachments later ?), and b) whether a sensitive file stays forever in your (iOS) database and there was nothing you could do about this.
I'm sure I read an old (2018) post about this where the feature was added to cull orphaned attachments after 4 hours.
last step, findings for Android (8! not 10):
I cannot confirm all your findings, just a few inaccuracies on my side. So step by step. I can add txt / pic and bin attm. Like on iOS, a way to display (some) text inline is missing, a pic can be added and viewed, but no tap, click, long-press or whatsoever has any action following. One cannot even select a pic in the middle of a note and copy it. This has nothing to do with what other apps are registered.
The same finding for the binary attm., no tap or else has anything happen. It's been added, it's there, it's dead.
There is a share button in the top-right menu of Jop, but it is designed to share the whole note (with textual links to any attachments), no way to retrieve the files. So just some minor corrections in my table as far as Andr8 is concerned. Is Andr 10 really different, for sb else to find out.
After completion of this step I come to the conclusion that all the actions for attachments on all platforms need to be tidied up a little.
I'll update the original matrix again and post it a little later, just for the records.
Even so the matrix lists only text, picture and binary files, it does indeed cover any file types and attachments. Consider text and picture as the "basic" file types (often used) and "binary" to cover anything else. In this sense the table is still correct. Whether PDFs should be listed separately is just a matter of convenience. Whoever works a lot with PDF/s could easily complete the table.
