New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inserting image link issues #112

Closed
cyotek opened this Issue Feb 13, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@cyotek

cyotek commented Feb 13, 2016

Hello,

Couple of minor issues I noticed when dragging images from file explorer to MDE:

  1. When inserting file paths, MDE chooses to insert absolute paths, even if the source image is located in the same folder as the MD document. Would be much more helpful if these were relative - I honestly can't think of a single reason why you would want a full path "hard coded" into a document
  2. After choosing an option (well, I say option but I've only ever used Insert Path) the menu remains open. Again, I can't really see you choosing multiple options for the same file
  3. It would be helpful if MDE was fully activated after dropping a file - for example try dropping an image file into a Word document. Word will insert the image and then fully bring itself to the foreground etc. I think this is more convenient. On the occasions where I'm dragging multiple items, I just tile windows side by side.
  4. Speaking of multiple items, if you drag multiple image files in a single operation, MDE ignores all bar the first
  5. Finally, a minor enhancement. I have no interest in Imgur, data URI's, or whatever the odd looking local file is. I create and process my images as separate entities and I want to link them in MD files, simple as. It would be nice if you could specify a default behaviour, so that when I drag and drop a file, a (relative ;)) link is created without any further interaction. I suppose if you wanted to be awesome, you could add an override key (File Explorer's right click drag is a good example) where the original menu would then be present for the one off scenarios you want to do something different.

(OK, so that's more than a couple - maybe I should have created separate issues, but don't want to spam. Also didn't think of testing the multiple file drag until I was halfway through writing the ticket)

@mike-ward

This comment has been minimized.

Show comment
Hide comment
@mike-ward

mike-ward Feb 13, 2016

Owner

This is awesome feedback. I'll address the issues individually a bit later but just wanted to acknowledge the thoughtful feedback.

Owner

mike-ward commented Feb 13, 2016

This is awesome feedback. I'll address the issues individually a bit later but just wanted to acknowledge the thoughtful feedback.

@mike-ward mike-ward added the bug label Feb 14, 2016

@mike-ward

This comment has been minimized.

Show comment
Hide comment
@mike-ward

mike-ward Feb 15, 2016

Owner
  1. Agree, paths should be document-relative.
  2. The menu remaining is a bug. Not my intention.
  3. Agree, app should fully activate
  4. Didn't consider multi-file support. What if there are multiple file types?
  5. Probably just add a settings option (file only)
Owner

mike-ward commented Feb 15, 2016

  1. Agree, paths should be document-relative.
  2. The menu remaining is a bug. Not my intention.
  3. Agree, app should fully activate
  4. Didn't consider multi-file support. What if there are multiple file types?
  5. Probably just add a settings option (file only)

@mike-ward mike-ward added the confirmed label Feb 15, 2016

@cyotek

This comment has been minimized.

Show comment
Hide comment
@cyotek

cyotek Feb 16, 2016

For 4, I did a test with non-image types and noted that MDE opened the file for editing, even if it couldn't possibly edit it (I tried dropping a text document followed by a shortcut). Maybe if a document is already open dropping any sort of file should just create a link (either image or just a standard link - you could either be lazy and have a predefined list of image extensions, or you could query HKEY_CLASSES_ROOT\.<Extension> and look the mime type or perceived type to decide what to do)

So, if it's a mix of content types (or more than one file in the drop) then I would link them all. If it's a single non-image file then that's a different story. Personally, I'd rather it linked - if I want to open a new document I am explicit in my intent, either by Control+O, or opening the file from explorer etc). But other users may like the open document on drag behaviour so maybe it's time for another hidden setting?

As for 5, that is fine with me.

cyotek commented Feb 16, 2016

For 4, I did a test with non-image types and noted that MDE opened the file for editing, even if it couldn't possibly edit it (I tried dropping a text document followed by a shortcut). Maybe if a document is already open dropping any sort of file should just create a link (either image or just a standard link - you could either be lazy and have a predefined list of image extensions, or you could query HKEY_CLASSES_ROOT\.<Extension> and look the mime type or perceived type to decide what to do)

So, if it's a mix of content types (or more than one file in the drop) then I would link them all. If it's a single non-image file then that's a different story. Personally, I'd rather it linked - if I want to open a new document I am explicit in my intent, either by Control+O, or opening the file from explorer etc). But other users may like the open document on drag behaviour so maybe it's time for another hidden setting?

As for 5, that is fine with me.

mike-ward added a commit that referenced this issue Feb 18, 2016

mike-ward added a commit that referenced this issue Feb 18, 2016

mike-ward added a commit that referenced this issue Feb 18, 2016

mike-ward added a commit that referenced this issue Feb 18, 2016

@mike-ward mike-ward added the fixed label Feb 18, 2016

@mike-ward mike-ward closed this Feb 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment