In light of the no-security-updates status of webkit-gtk, I thought it wise to disable all in-process web browsing in gimp. This seemed to be mostly a matter of not using the help browser. So I tried that: in Preferences|Help System I selected "Use the online version" from the "User manual" selector, and "Web browser" from the "Help browser to use" selector. I also purged the gimp-help-en package. I am disappointed, however: Choosing the Help|Help menu item results in a message box saying: "Could not open 'http://docs.gimp.org/2.8/en/gimp-help.xml' for reading: Operation not supported Perhaps you are missing GIO backends and need to call GVFS?" That message sure seems like it's still trying to read the file in-process. I thought it would simply execute sensible-browser with the URL as an argument. Not surprisingly, I get the same message when I select the Help|User Manual|Basic Concepts menu item. When I select the Help|GIMP Online|Main Web Site menu item, I get a different message box: "GIMP Message Calling error for procedure 'plug-in-web-browser': Operation not supported GIMP Message Execution error for 'Main Web Site': Error: ( : 1) Procedure execution of plug-in-web-browser failed: Operation not supported" Dear Maintainer(s), what is going on?
All of the gimp help stuff still needs the index files from somewhere, and to get them from the Internet requires gvfs-backends (a suggested package on gimp). I agree that the error message could certainly be better.
On Sun, 26 Oct 2014 21:52:20 +0000, Ari Pollak <ari@debian.org> wrote: Ari> All of the gimp help stuff still needs the index files from Ari> somewhere, and to get them from the Internet requires gvfs-backends Ari> (a suggested package on gimp). I agree that the error message could Ari> certainly be better. I have a few questions, then. 1. Does this mean webkit is still used even if I choose "Use the online version" for "User manual" and "Web browser" for "Help browser to use"? I hope not, because that would mean to browse gimp help at all I'd be forced to use a potentially insecure package. 2. Would it make sense to split the index files from gimp-help-* and put them into either a new package, or one of gimp, gimp-help-common? Looks like having the indexes but not the actual content locally may be a quite desirable setup. 3. Reading the GIMP upstream installation notes I see that libcurl can be configured as an alternative to gvfs for remote files. Why isn't that done in Debian? I think lots more users have curl/libcurl already installed than gvfs. Please feel free to reassign / retitle or similarly mangle the bug, or even close it and tell me how to redirect the discussion. Just please do _not_ say "Everybody must use webkit and gvfs, and that's that."
No. 2. Would it make sense to split the index files from gimp-help-* and You're the first one to ask for that in the 6 years since we started building with gvfs support, so that seems like overkill. If you want contextual help, you can install gvfs-backends; otherwise you can browse the docs manually. Upstream made the help index an external dependency so that it could be updated on a separate schedule from the main gimp package, and I won't argue with that. gvfs is much more featureful than libcurl, since it lets you open files from more than just HTTP and FTP. It's also optional and Just Works for people with GNOME installed, which is the target environment of GIMP. do _not_ say "Everybody must use webkit and gvfs, and that's that." Nobody has to use webkit or gvfs to use gimp, they just won't be able to open remote files or use contextual help. We've also stopped building with webkit for a few months; see #639761.