Bug Hunting Session
Bug 87714 - CONTEXT MENU: Better integration with image editing apps
Summary: CONTEXT MENU: Better integration with image editing apps
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Context-Menu
  Show dependency treegraph
 
Reported: 2014-12-25 17:40 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-06-13 14:50 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-12-25 17:40:26 UTC
As LO does not have image editing capabilities, it would be better to have direct edit linking between LO and other image editing applications (primarily open source ones), rather than simply having 'Edit with External Tool' (.uno:ExternalEdit) load up the image in its default viewer, as most default viewers dont have editing capabilities.

So i'd like to suggest that LO check for the following list of image editors

== Linux ==

GIMP - /usr/bin/gimp
Pinta - /usr/bin/pinta
Showfoto - /usr/bin/showfoto
gThumb - /usr/bin/gthumb

== Windows ==

GIMP
Pinta
Showfoto
Paint - c:\system32\mspaint.exe
Paint.Net
Photoshop

== Mac OS X ==

GIMP
Pinta
Showfoto
Paintbrush - http://paintbrush.sourceforge.net/
Photoshop
Pixelmator

With the ability to detect these external editors, we could have an edit image context entry like this.

Edit Image With
  GIMP
  Pinta
  --
  Default Viewer
Comment 1 A (Andy) 2014-12-25 19:34:38 UTC
Great idea, because for me EDIT WITH EXTERNAL TOOL opens the standard windows photo viewer, where I have no editing capabilities and therefore I never use this function yet.
But would it also be possible that you could select between the different installed software instead of only select out of a preselected software list, because then it is not unlikely that LO does not list the right programme, because there are so many existing programmes besides Jay's list like PhotoFiltre, LightZone, ViewNX, XnView, Microsoft Picture Manager, Aperture, Photoscape, etc.  In addition, I don't think it is good to focus mainly on open source software.  Therefore, best it would be if LO would detect on its own all installed graphic programmes and offer them, otherwise the list should be extended.
Regarding Photoshop there is also a whole family (Ps, Lithroom, Elements).
Comment 2 Adolfo Jayme 2014-12-27 02:17:23 UTC
(In reply to A (Andy) from comment #1)
> Great idea, because for me EDIT WITH EXTERNAL TOOL opens the standard
> windows photo viewer, where I have no editing capabilities

Yes, but if you ever right-clicked an image in Windows Photo Viewer you could have realized that the context menu it contains an “Open With” item. And as the program’s name says, it is a *viewer*. Why should you have editing capabilities there?
Comment 3 A (Andy) 2014-12-27 10:19:49 UTC
(In reply to Adolfo Jayme (UX) from comment #2)
> (In reply to A (Andy) from comment #1)
> > Great idea, because for me EDIT WITH EXTERNAL TOOL opens the standard
> > windows photo viewer, where I have no editing capabilities
> 
> Yes, but if you ever right-clicked an image in Windows Photo Viewer you
> could have realized that the context menu it contains an “Open With” item.
> And as the program’s name says, it is a *viewer*. Why should you have
> editing capabilities there?

Well, of course I know that the Windows Photo Viewer is only a viewer and has no editing capabilities and this is from my point of view exactly the inconsistency in LO and what I wanted to say and as I understood Jay.  The LO context menu says EDIT WITH EXTERNAL TOOL and not OPEN WITH EXTERNAL TOOL.  And as a user if I see/select EDIT I expect that I can edit it directly with an image editor and not maybe only open it and maybe later edit it after further mouse clicks.  Otherwise, we should maybe rename it to OPEN WITH EXTERNAL TOOL then this would from my point of view be more consistent, because this could then be a viewer and also an image editor.
As you wrote Windows Photo Viewer also uses the term "Open with" and we use Edit With, but in real we have to admit that is actually currently only an Open With?

But from my point of view I would prefer to have the possibility to open an image editor directly from LO, because I don't need a simple viewer, because I can see the image already in LO, but I can not really edit it there.  But if I edit it in the image editor then the changed image must also appear in LO (is this already the case?).  

Is my understanding right, that you want to keep that it could be opened with the windows photo viewer?  And if yes, what would you then think about a renaming to "Open With External Tool"?  What is your opinion?
Comment 4 Yousuf Philips (jay) (retired) 2014-12-27 11:04:41 UTC
(In reply to Adolfo Jayme (UX) from comment #2)
> Yes, but if you ever right-clicked an image in Windows Photo Viewer you
> could have realized that the context menu it contains an “Open With” item.
> And as the program’s name says, it is a *viewer*. Why should you have
> editing capabilities there?

Yes i have to do this run around also on linux as it opens with gThumb. As it is a viewer, LO shouldnt be loading it into such a program when the entry says 'Edit with External Tool'.
Comment 5 Adolfo Jayme 2014-12-27 13:49:40 UTC
(In reply to Jay Philips from comment #4)
> Yes i have to do this run around also on linux as it opens with gThumb. As
> it is a viewer, LO shouldnt be loading it into such a program when the entry
> says 'Edit with External Tool'.

And why not fix the command’s label instead? I agree it’s misleading.
Comment 6 V Stuart Foote 2014-12-27 15:16:05 UTC
No--the action needs to to be labeled "Edit" showing the result of "external" manipulation will be written back into the LibreOffice ODF if changes are made. Need to keep that distinction clear.

Regards which helper--presently LibreOffice simply honors per user the OS assigned default application--if you want to be able to edit, set the file association on the OS to an appropriate editor, i.e. JPEG --> GIMP, PNG --> GIMP, SVG --> Inkscape, etc.

Otherwise, most folks will have a Viewer rather than an Editor selected as default for their OS.

Point is that is it user controlled and easily done from the OS file association, not LibreOffice. And in fact you can even adjust things so that the "external" program is LO Draw, if that has the functions you need.

That said, I do like to idea of allowing LibreOffice to catalog the helper files installed to perform the view/edit--and making that list available for selection from n a drop down--for alternatives to using the user set default.

In that context it would be a reasonable enhancement--just a fair bit more work.
Comment 7 Yousuf Philips (jay) (retired) 2014-12-27 16:29:49 UTC
Yep the main problem is that most users have images associated with a default viewer and not editor, so we have to help them out and have LO point to suitable editors. Most users dont want images associated with an editor, as they just want to preview the image. Imagine having to open GIMP or Photoshop every time you tried opening a JPG. That would drive me crazy, primarily because GIMP takes 10 seconds to load. :D

I believe it should be simplest to get working on Linux as everything is dumped in /usr/bin/. With Windows we could test the default install location of the applications, but some users change that path, so it would be more suitable to check the registry (e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\Photoshop.exe\shell\open\command\, HKEY_LOCAL_MACHINE\SOFTWARE\paint.net [TAREGETDIR]). I have no clues about OSX. :D
Comment 8 A (Andy) 2014-12-27 17:30:38 UTC
(In reply to Jay Philips from comment #7)
> Yep the main problem is that most users have images associated with a
> default viewer and not editor, so we have to help them out and have LO point
> to suitable editors. Most users dont want images associated with an editor,
> as they just want to preview the image. Imagine having to open GIMP or
> Photoshop every time you tried opening a JPG. That would drive me crazy,
> primarily because GIMP takes 10 seconds to load. :D

I agree, this is exactly the case for me and most of my friends.  I work mainly with two - three image editors.  But as standard for previews I want to have the windows photo viewer, because to load images in the image editors would take me several seconds.  Therefore, JPGs are linked to the photo viewer.  Only if I want to edit images I open the image editors directly or I open the images with them (for normal daily editing as in LO JPGs and for more sophisticated things RAWs, but which are not yet supported by LO).
Comment 9 Cor Nouws 2014-12-28 20:17:19 UTC
TL-DR ..
What about Tools > Options > Editors ... a field where one or more (separated) applications can be given?
Parallel with Tools > Options > E-mail ..
Comment 10 Yousuf Philips (jay) (retired) 2014-12-28 21:33:42 UTC
(In reply to Cor Nouws from comment #9)
> What about Tools > Options > Editors ... a field where one or more
> (separated) applications can be given?

Yes i think it would be good to have such a section to allow users to add additional editors not automatically detected (Andy had a long list), but we should do some automatic detection (even if it is just one per OS - GIMP [linux], paint.exe [Windows], Not sure what [OSX]), just like we do with java detection.
Comment 11 Yousuf Philips (jay) (retired) 2015-01-02 20:28:10 UTC
Maybe the simplest thing is to show the Open With list of the particular image type provided my the OS.
Comment 12 Robinson Tryon (qubit) 2016-08-25 04:21:36 UTC Comment hidden (obsolete)
Comment 13 Heiko Tietze 2017-11-28 13:15:21 UTC
(In reply to Yousuf Philips (jay) from comment #11)
> Maybe the simplest thing is to show the Open With list of the particular
> image type provided my the OS.

The default graphics editor is defined on Windows at HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\edit\command but there isn't such an export variable or the like in Linux. The info for the Open With menu is extracted from <app>.desktop at /usr/share/applications or ~/.local/share/applications/ where MimeType defines for what file type this program is applicable. Not sure how macOS handles this task but likely in the same way.

Putting all together I think Cor's suggestion from comment 9 is the easiest way - and perhaps a nice easyhack with a higher difficulty. Ideally we get a command .uno:ExternalEditor, which is disabled when the option is not set. It opens the program parametrized with the internal image. That could be tricky.