gimp2 now drags in an entire web browser (epiphany)

[ewen-naos-nz (Ewen McNeill)]

As of the most recent MacPort of gimp2 (2.8.18_1, ​changeset 153690), gimp2 seems to have acquired a bunch of extra dependencies (40+ new ports dragged in on my system just on going from _0 to _1).

This appears to be a result of now depending on epiphany, a fairly full featured web browser with 300ish dependencies (recursively; some commonly installed, others not). It seems excessive to require an entire specific web browser with audio, video, etc, functionality be installed just to be able to install a graphics program (which does neither audio nor video). Particularly since pretty much every system it is installed on via MacPorts will have at least one working web browser already installed (Safari, if nothing else).

Currently I can't see a way in the portfile to opt out of having epiphany force installed. Could one be provided? AFAICT help_browser was optional before. Or alternatively the help browser just be a simple external "open URL with HTTP MIME Type handler" tool, rather than a full web browser?

Thanks,

Ewen

[dbevans (David B. Evans)]

Hi, Ewen. Ever since I added the dependency on epiphany, I've been expecting this ticket.

If you've read the changeset description, you know the motivation for this change. In the new webkit-gtk free approach, GIMP just calls gtk_show_uri which is pretty much the "open URL with HTTP MIME Type handler" approach you recommend, using glib's GIO component. Basically any app that says it can handle the URL in it's desktop file will do. I just picked epiphany because it's the preferred browser in the GNOME environment and it uses webkit2-gtk rather than webkit-gtk.

The problem is that if one were to omit the runtime dependency on epiphany or some similar browser, when trying to access GIMP help, the user would receive an obnoxious error message of the form "operation not supported". Then I'd get another ticket saying GIMP help is broken and that would be correct. And I really didn't want to add a note saying that help is broken but you can fix it by installing epiphany or the like.

At any rate, I'm working on a patch to the GIMP code that should help the situation. The patch adds additional code that does a macOS style open URI call if the existing call to gtk_show_uri fails. This should open the help page in Safari or whatever default macOS web browser you're using on your system. Then the dependency on epiphany should be able to be safely removed without breaking the help functionality and users can see the help in whatever web browser they normally use.

Should have this ready and tested in the coming week. Since this is not really a defect but an irritation, I'm relabeling your suggestion as enhancement until then.

Thanks for your input. At least I know someone down your way is using GIMP.

[ewen-naos-nz (Ewen McNeill)]

Thanks for the prompt reply and detailed explanation.

I'm pleased to hear that you're already planning/working on something along the lines I had in mind -- ie, running the macOS open on the text. Based on some quick testing here the "macOS style open" could just be a trivial shell command that runs open /path/to/file.html, and the default browser should open (without requiring dependencies). The .html extension appears sufficient to trigger that.

And if you're concerned the type might not be auto-detected I think it'd be okay to force Safari to be the default help browser, eg:

open -a Safari /path/to/help/file

which would ensure that anything that worked in Safari would open in Safari. (I don't see a particular need to reimplement the open command when it already exists for this use case -- there's no particular performance issue for instance.)

Thanks for the work keeping gimp installable in MacPorts.

Ewen

[dbevans (David B. Evans)]

Replying to macports@…:

Thanks for the prompt reply and detailed explanation.

I'm pleased to hear that you're already planning/working on something along the lines I had in mind -- ie, running the macOS open on the text. Based on some quick testing here the "macOS style open" could just be a trivial shell command that runs open /path/to/file.html, and the default browser should open (without requiring dependencies). The .html extension appears sufficient to trigger that.

And if you're concerned the type might not be auto-detected I think it'd be okay to force Safari to be the default help browser, eg:

open -a Safari /path/to/help/file

which would ensure that anything that worked in Safari would open in Safari. (I don't see a particular need to reimplement the open command when it already exists for this use case -- there's no particular performance issue for instance.)

Agreed, just need to do it programmatically from GIMP's generic web-browser plugin.

Actually, the URI passed is of the form ​http://path/to/help/file or ​file://path/to/help/file depending on whether your preferences are set to online or local help so file extensions are immaterial. This works correctly with Safari, Chrome and Firefox on my system.

Thanks for the work keeping gimp installable in MacPorts.

You're entirely welcome, I'm just glad that some one is paying attention :-)

Dave

[mopihopi]

Cc Me!

[dbevans (David B. Evans)]

Fix committed in r153733. Hard runtime dependency on epiphany or any other GNOME/GTK web browser removed and GIMP web browser plugin patched to fall back to macOS default web browser if no GNOME/GTK browser is available. Help functionality tested successfully with epiphany and midori (MacPorts GNOME/GTK) and Safari, Firefox and Google Chrome (macOS).

This should ensure that the HTML help docs are viewable regardless of what's installed on the computer and without specifying any particular external browser.

Also fixes the +quartz upgrade issue in #52549 which was caused by the runtime dependency on epiphany which, itself, does not build +quartz due to various +x11 only dependencies.