I am an I do. Install gvfs as we speak.

This might be related to https://bugs.launchpad.net/ubuntu/+source/samba/+bug/858247
I am using OS X 10.8 Mountain Lion.

The "need to install GVFS?" phrase is from the Gimp error, not my own comment.

Yeah, I know. I have tested it myself, and cannot get it to work no matter the configuration. I'm looking into other options, as well.

This is a multi-part issue.
1. There is no gimp documentation installed.
This means that trying to load local documentation doesn't work.

2. There is no help-browser installed.
This means that even if there was documentation installed, it would still try to open it the the users default browser.

The reason why gvfs isn't working is beyond me. This affects "File"-"Open Location" as well.

Webkit-gtk is as stubborn as ever, and is proving difficult to build.

The documentation itself is proving difficult to install.

This affects the function 'File/Create from webpage...', too. It appears in the Windows and Linux builds and takes a snapshot of a webpage. The respective plug-in common/web-page.c relies on Webkit, like the aforementioned functions.

After installing GIMP 2.8.4-no-python for OS X 10.6.8, I tried to open help files. The message reads, "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 install GVFS?"

Please either provide an installable help file for Mac OS X, or re-establish the link to online help that was available in GIMP Mac OS X 2.8.0p1. Thank you.

In 2.8.14 my patches have been adopted, so this bug is fixed. The bug report could be closed.

We should still check if it works on master, where GIO/GVFS are a mandatory
dependency, and where you patch wasn't applied.

For what purpose is GVFS needed? AFAICS it makes much trouble on OS X to get it up and running. From OS X point of view it's useless as opening images from remote locations works already without installing GFVS. 
Please don't make it a mandatory dependency as this will bring GIMP more away from being 'native' on the Mac platform and only forces the OS X builds to imitate a more or less complete Linux desktop environment within the app bundle. All this functions are already a part of OS X and IMO GIMP should use the system provide APIs as far as possible. Being 'native' on a Mac is, IMO, more than a menubar at the top or 'without X11'.

In master, all file operations are ported to GIO, so GVFS is used under
the hood. GIMP should not use the system provided APIs where possible,
this should be the *absolute* exception and only be used where unavoidable.
GIMP should use abstraction layers like GLib, and have as little platform
specific code as possible.

So you prefer to reinvent the wheel just for the sake of some 'platform independent code' - which means in this situation: the Linux and open source specific code and way of doing it - instead of using already available functionality. There are so many #ifdef conditional compile statements in the sources. why not make the use of GVFS platform specific?

The bug report says, that File -> Open Location doesn't work.

Well,in my builds, File -> Open location works. Without GFVS installed. And I've just written a small plugin which to implements File -> Create -> From webpage without the need of GFVS or a separate compiled webkit . So even the second bug in this report is fixed. Again, why reinventing the wheel?

I never got GFVS working on the Mac for GIMP. Unless I or somebody else will find a reliable way to get a working GFVS implementation on OS X, you will loose functionality which currently works without GFVS. So, what's the advantage of using GFVS on OS X?

FWIW, I too have never been able to get GVFS to work 100% on osx, even with jhbuild. The more libs I bundled, the more complex the entire thing got. You can see it in the osx bundle, most of the gimps had GVFS disabled. GVFS pulls in at least these deps, perhaps more.

libsecret
sqlite
libgcrypt
libgpg-error
libsoup
glib-networking
gnutls
libproxy
nettle
gmp

We don't neccessarily need to use GVFS. On Windows, GIO used native API
calls directly to implement for example HTTP. This won't give us stuff
like sftp:// and other protocols implemented by GVFS backends. In any case,
if we add #ifdefs for OSX, we should do it where it belongs, which is in
GIO, but not in GIMP.

If there is anything missing or broken, let's fix GVFS and DBus.

Fixing GIO might be good, if it really would be done, but don't make GVFS mandatory.
Why forcing OS X to use some other platform specific code to access remote files, if there already is an OS X provided library and API? This will break GIMP for ages on OS X. From my experience there will be no developer who is willing to port GVFS seamlessly to OS X. Why? No core GVFS developer has the need to get a Mac up and running, and no OS X developer has a need to get GVFS working in his application, because there's absolutely no need for it on OS X. And these some folks like Daniel, Sven, Clayton and me, well, can't already get it working.

But what may come is just another dirty hack to use some undocumented APIs as it has been done in the official gtk-mac-integration library. 

And again, currently accessing remote files works by using the OS X provided libcurl. Don't break this.

And please, don't use DBus and don't make it mandatory. This is Linux specific too. On OS X use Apple events. Don't force an OS X application to not use Apple events. This would really be counteractive to a more Mac like integration of GIMP.

Nevertheless, if you go further in this direction, it would be easier to set up a virtual Linux machine on OS X just to run GIMP. The VM has everything you prefer right out of the box. GIO/GVFS, DBus, Gtk-print, LCMS2, working command line passing, working color picker, the latest and greatest libpng, libjpeg and have every OS X core technology and system features and APIs squeezed out. Have you every seen the power of Quartz drawing routines or the new SIMD code in the vImage API? Try any 1$ photo manipulating app from the Mac App Store and you'll be astonished by the speed of graphics manipulation. Compare this to GIMP and GEGL. Trying to develop a platform independent generic graphic library is a noble goal, but what if some platform already has outstanding APIs for graphics? 

So please don't make GVFS mandatory. And never DBus. An application running on multiple platforms should IMO make as much use of platform specific features, APIs and interfaces as possible and not force all platforms to behave as one.

Seems we have a clash of philosophies here. GIMP's policy was always to
use as little platform specific code as possible. Instead, we use abstraction
layers like GTK+ and GLib which in turn do the platform-specific part for
us. GTK+ and GLib were in fact originally created by GIMP to do just that,
and I don't see it changing.

Simone, is there a reason why your code changes aren't in the libraries that GIMP uses? I'm with mitch here, I think they'd belong there.

I don't know the reason. 

Sven commited my code to fix the 'Help-not-working' part of this bug report. So it's already there (and doesn't use GVFS). 

BTW, the fix is just one line to call with a Cocoa API call and some 5 to 10 lines of wrapper C code. So, why do I need to compile a bunch of libraries to get the GVFS code to work? Sven already tried that. With no success. GVFS is a beast on OS X.

The 'File -> open location not working' part is really easy to fix if you compile with OS X provided libcurl (set the corresponding env vars, and use the configure options --with-libcurl --without-gvfs) and, well, I fixed the "File -> create - From webpage' by simply using a python script named 'webkit2png'. ( http://www.paulhammond.org/webkit2png ) ok, ok, I haven't already published this patch, so this is the cause why it's not in master or in 2.8 ...

So, I really don't why it's necessary to make GVFS or DBus mandatory on OS X. Can you tell me?

If we add this to GIMP directly, then GIMP will be the only app that has it. If it is in GVFS, there can - and hopefully will - be other users.

Plus, we can make sure that the GIMP code itself can be reasonably maintained by someone who doesn't have any OSX-specific knowledge, just of the abstraction libraries that make such things transparent.

The concept your are proposing, to make use of native code in GIMP for anything that a platform might provide, seems very unmaintainable for me. 

That's even a problem right now - if people use your builds and turn to us for help, we can't really be sure if what they're seeing is a bug or an intentional change. This should be better now, with many of your changes having been brought back - although I didn't follow this closely, and I hope that we didn't introduce too much platform-specific code for this?

Come on, the fix for Help-not-working is one line to call a Cocoa API. This one line of code replaces the need to call a GTK / GIO /GVFS function. Why should this be done in some underlying library? Why should one need to compile a bunch of libraries just to use one call of a Cocoa API?

That's the line:

urldata = [NSData dataWithContentsOfURL: url];

Should one seriously port this one line to some library and force other GTK-to-OS X application developers to compile (and possibly fix) round about 7 Linux specific libraries?

Please don't make GVFS or DBus mandatory on OS X.

Well, I don't call this philosophical but efficient.

And, I know, it's really hard to answer user questions for different platforms or different builds. But AFAICS many bug reports or postings on mailing lists are about 'Why does GIMP not behave like an OS X application? Why is there a different print dialog, a different color chooser, other shortcuts, not working drag and drop, no dock menu ...?

And from a developer's point of view: If you're delegating the effort to make an app platform independent, you, IMHO, don't face reality. There are only very few developers who care about platform independent code. 'Platform independent' here means 'runs on Linux, OS X and Windows'. Take a look at GTK. It's about 20 years old. And, does it support core features of OS X like ColorSync, printing, networking or SIMD optimized graphics manipulation routines? So, do you really think, that there might be some developers who will port GVFS, DBus or GEGL to use OS X APIs just for the sake of replacing one line of Cocoa API code? I don't.

Again, please don't make GVFS or DBus mandatory on OS X.

BTW, I know that it's a problem to answer questions from users, if they are using another build. I've done that for years, when I had to answer mails of users who used builds from MacPorts, HomeBrew or even tried to compile from the 'official' sources. 

And finally, IMO there's still much Linux-specific code, but, I'll try to change this :-)
(FYI, I was on Linux from 1995 up to 2006 ...)

We don't plan to make GVFS/DBus mandatory, GIO is doing that, and GIMP
master is almost fully ported to GIO. The file-uri plug-in is gone
for good, and replaced by calls to GIO which do not require ifdefs all
over the place.

I don't really understand what the problem with that is. There is windows
specific code in GIO and it doesn't use GVFS on windows. On OSX, the same
could be done, or we simply build and bundle GVFS. Where is the problem?

Again, adding platform specific ifdef code should be the exception,
because it's just not maintainable. What do you do with such a piece
of code if you are changing the code around it?

The problem is that I don't know anybody who got GIO/GVFS up und running on OS X or has  successfully included it in a Mac application bundle. And as I already have written, I can't imagine any Mac developer who is willing to port a low level Linux library to use Cocoa high level and application centric APIs. Do you know Linux developers who are able to get GIO / GVFS tu use Cocoa APIs?

Sorry, I'm not a core GIO / GVFS developer, so I can't do the job. And I don't want to dive into GIO / GVFS just to get one line of objective C code using Cocoa replaced with pure C and Linux specific libraries.

The one line is one line only in 2.8, in master all file I/O in app/
is ported to GIO, and the file-uri plug-in is gone. We're not going
to add ifdef code all over the place, we use GIO, which is part of
GLib.

Generally, we port GIMP to platform-specific API only as temporary hacks
to get things done and working, and try to use GLib and GTK+ otherwise,
because they are GIMP's abstraction "platform". That platform needs to
be ported to specific operating systems.

Some way (with GVFS or without), GIO will be made to properly support
URIs other than file:// on OSX, GIMP is not the only project which
needs this, so it's going to happen.

So well, I finally see you're right. We have a clash of philosophies.

But, one last question:
Does master run as an OS X bundle and can access remote files?

Not yet, but it will.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/420.