Feature request: intuitive drop images

FelixFurtmayr commented 5 years ago

Current state

An Image that is dropped is saved and can be added then later by choosing with the "add image button".

My Thoughts

I don't need to see a new tiddler where the image is stored.
I don't want to manually add the image after dropping it

Improvement

Just do it like github or gitlab (or in word or writer): Add the image where it is dropped.

That is so easy for the user. There is no reason why I manually should do 5 clicks more, when I always (over 95%) want it like this. For me this missing feature is currently "the" weakness of tiddly wiki (and a lot of other wikis).

Implementation

The basic functionality seems already there, but the process has to be automated. There may be a parameter "imageAutoSave" to enable the described behaviour, but it should be enabled by default, as many people will be happy when this is as easy as possible.

For me it would make sense to optional store files in an extra folder, that one can specify, if the wiki is big. But considering my own usecase, it would be enough if everything is embedded. If the file is 20 MB - I don't care. The browser might still handle it and it won't break due to wrong external links.

ToDo

please give some Feedback to the idea
if others see the feature as important as me, the implementation can be discussed

AnthonyMuscio commented 5 years ago

Perhaps building a different drop zone or drop mode that accepts the image drop as you wish. You will need to address duplicate tiddler names and while we are at it we should allow a folder name such as "images" to be provided that creates external links to images\imagename.jpg as dropped (canonical address?), thus allowing an external reference to the image to also be dropped.

Of course this could be designed to treat all dropped files the same way.

Finally if the dropping of a file as an external link works it would be nice if the file could be "exported" to the named folder at drop time (appropriate access available of course).

Regards Tony

sukima commented 5 years ago

I would love for a way for an imported tiddler of a binary type to import as a _canonical_uri tiddler to the file:// located on the drive you drag and dropped it from. Sadly, I've learned that browsers have this capability intentionally disabled. So there goes that dream!

rryan commented 3 years ago

Any thoughts on whether this is feasible / desirable in core or should/could it be a plugin?

I would love supporting drag-drop of images, audio and video in the editor for WikiText and Markdown tiddlers, resulting in automatic creation of a tiddler for the content in the background, followed by embedding of the image via WikiText/Markdown markup (just like GitHub, Gitlab, Slack, Discord, etc.) all support.

pmario commented 3 years ago

Images in tiddlywiki should always be imported as external tiddlers with an _canonical_uri parameter. If we import images, they have to be stored in base64 format, with roughly doubles the size of the file.

TiddlyWiki is built for reusability. If an image would be embedded into a tiddler, it wouldn't be reusable anymore.

@Jermolene ... I personally would close the issue with a "wontfix"

pmario commented 3 years ago

I would love supporting drag-drop of images, audio and video in the editor for WikiText and Markdown tiddlers, resulting in automatic creation of a tiddler for the content in the background, followed by embedding of the image via WikiText/Markdown markup (just like GitHub, Gitlab, Slack, Discord, etc.) all support.

That's nice, but the browser won't let you do that with a file TW. ... For importing and saving binary files into a client-server wiki there are probably some more open issues here in the repo.

rryan commented 3 years ago

TiddlyWiki is built for reusability. If an image would be embedded into a tiddler, it wouldn't be reusable anymore.

Oh I was thinking it would work similar to the current drop workflow -- where a tiddler is created for the image. I was just thinking it would be automatic (use the file name of the dropped file without prompting the user for anything) and automatically emit the correct markup to embed the image. The image would be re-usable in other tiddlers.

A use case to be concrete about why I want this:

I'm watching a lecture and taking notes. I want to grab a screenshot of the slide on screen and drop it in my notes. Use the system's screenshot feature then drag the resulting screenshot into the text area where I'm writing my notes.

That's nice, but the browser won't let you do that with a file TW. ... For importing and saving binary files into a client-server wiki there are probably some more open issues here in the repo.

Ah hrm. I was thinking if you can do it via mouse today, it should be possible to automate. What's the technical restriction preventing programmatic creation of a tiddler in a drop event handler? (Or.. if you see my misunderstanding please LMK what question I should be asking :)).

FelixFurtmayr commented 3 years ago

Hi guys, no discussion if it is possible - but you were right - there were issues in the past. Github here and Gitlab do it exactly this way and it is awesome - I will do it in 80% like this (working in IT and Marketing). Just try it here and convince yourself in Github.

https://stackoverflow.com/questions/490908/paste-an-image-from-clipboard-using-javascript

// window.addEventListener('paste', ... or
document.onpaste = function(event){
  var items = (event.clipboardData || event.originalEvent.clipboardData).items;
  console.log(JSON.stringify(items)); // will give you the mime types
  for (index in items) {
    var item = items[index];
    if (item.kind === 'file') {
      var blob = item.getAsFile();
      var reader = new FileReader();
      reader.onload = function(event){
        console.log(event.target.result)}; // data url!
      reader.readAsDataURL(blob);
    }
  }
}

https://caniuse.com/?search=onpaste

grafik

pmario commented 3 years ago

That's nice, but the browser won't let you do that with a file TW. ... For importing and saving binary files into a client-server wiki there are probably some more open issues here in the repo.

Ah hrm. I was thinking if you can do it via mouse today, it should be possible to automate. What's the technical restriction preventing programmatic creation of a tiddler in a drop event handler? (Or.. if you see my misunderstanding please LMK what question I should be asking :)).

For TW it is important that a workflow works for the single file wiki and the node-js version ...

I do see the desire, and the workflow is sensible, but there are technical limitations for a file based wiki. As I wrote it is a different problem for a client-server based wiki. ... We just didn't implement it here. There are open issues here in the repo.

Browser security restrictions only allow us to download and save something using the system dialogues. There is no way to download and write something to the HD "in the background", for obvious security reasons. If this would be possible without user consent, every page could save maleware to the users disk. ...

That's the reason why we need browser AddOns to save to disk without dialogues. .. And even with an AddOn the browser restricts the save action to the browser Downloads directory and subdirectories thereof.

saqimtiaz commented 3 years ago

I believe the original requirements for this issue have been met in #5699 and it can be closed. I haven't seen this issue before, otherwise it would have been closed with that PR.

If there is something further still needed, it would be helpful to create a new issue for it.

AnthonyMuscio commented 3 years ago

I believe the OT is nothing different to normal. It's just that when you drop the file you can do so in the text editor where a transclusion to the droped file will be inserted, and the file turned into a tiddler silently. I thought something similar is in the pre release.

Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Saq Imtiaz @.> Sent: Tuesday, July 6, 2021 5:11:53 PM To: Jermolene/TiddlyWiki5 @.> Cc: Anthony Muscio anthony.muscio@PSaT.com.au; Comment @.***> Subject: Re: [Jermolene/TiddlyWiki5] Feature request: intuitive drop images (#3901)

I believe the original requirements for this issue have been met in #5699https://github.com/Jermolene/TiddlyWiki5/pull/5699 and it can be closed. I haven't seen this issue before, otherwise it would have been closed with that PR.

If there is something further still needed, it would be helpful to create a new issue for it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Jermolene/TiddlyWiki5/issues/3901#issuecomment-874517933, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHQ7DETQHQRLS3FLSPBPKH3TWKUDTANCNFSM4HEO4XJA.

rryan commented 3 years ago

Browser security restrictions only allow us to download and save something using the system dialogues. There is no way to download and write something to the HD "in the background", for obvious security reasons. If this would be possible without user consent, every page could save maleware to the users disk. ...

That's the reason why we need browser AddOns to save to disk without dialogues. .. And even with an AddOn the browser restricts the save action to the browser Downloads directory and subdirectories thereof.

Ahh sorry, I think I was being imprecise. I meant the image would be stored in TiddlyWiki as normal, not as a separate file on disk. This flow works in single-file mode today:

Drag image into single-file TW.
Hit import on import dialog.
In a new WikiText or Markdown tiddler, embed the image by tiddler name.

IIUC, at this point the image isn't "on disk" at all, it's being served from memory by TW? I was simply proposing, it would be nice if we could avoid popping the import dialog when you drag an image into the editor textarea. Dropping anywhere else in TW would work as normal.

rryan commented 3 years ago

I believe the original requirements for this issue have been met in #5699 and it can be closed. I haven't seen this issue before, otherwise it would have been closed with that PR.

🎉 fantastic. It works perfectly in the prerelease. Sorry for not noticing this! I will file a separate issue for markdown support.

pmario commented 1 year ago

@FelixFurtmayr @Jermolene ... IMO this issue can be closed. The PR #5699 works as described in the OP. See: https://github.com/Jermolene/TiddlyWiki5/issues/3901#issuecomment-874517933

Jermolene commented 1 year ago

Thank you @pmario

TiddlyWiki / TiddlyWiki5