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
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).
(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?
(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?
(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'.
(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.
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.
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
(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).
TL-DR .. What about Tools > Options > Editors ... a field where one or more (separated) applications can be given? Parallel with Tools > Options > E-mail ..
(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.
Maybe the simplest thing is to show the Open With list of the particular image type provided my the OS.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
(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.