Hi,

it's about time to finally get rid of gimp-remote. I recently had the opportunity to make myself familiar with D-Bus. That allowed me to write a patch that builds the gimp-remote functionality into the gimp binary. I have attached it to bug #52866
(http://bugzilla.gnome.org/show_bug.cgi?id=52866). The patch needs some minor improvements before it can go into the trunk, but it is basically working. Your review is appreciated.

I would like to get the D-Bus names and methods right from the start so that we don't have to change this later. Let me give a short explanation of the current approach so that you can easily review it:

What the patch does is to let GIMP register at the session bus under the name 'org.gimp.GIMP'. It then registers an object under the path '/org/gimp/GIMP'. This object provides the interface 'org.gimp.GIMP'. This interface currently provides a single method 'Open' that takes an array of URIs.

Now when the gimp executable is launched with filename or URI arguments, it checks if the service 'org.gimp.GIMP' exists on the session bus. If it exists, it just calls the 'Open' method and exits.

There are a few things that we probably should address:

(1) We might need a way to override this behaviour. Under certain circumstances it might be useful to have multiple instances of GIMP running. A command-line option could be added to enforce this.

(2) What should happen if gimp is already runnning and gimp is launched again but with no files or URIs on the command-line? IMO it would be best if gimp exported a method to the bus that allows the toolbox to be raised. Instead of launching a second instance, we could just raise the first one then. Does that make sense?

(3) Should gimp-remote still be built and installed even if the d-bus functionality is built into the gimp exectuable? The patch currently doesn't change this, it just removes the reference to gimp-remote from the gimp.desktop file.

Sven

Hi,

On Fri, 2007-01-19 at 08:48 -0800, William Skaggs wrote:

(3) Should gimp-remote still be built and installed even if the d-bus functionality is built into the gimp exectuable? The patch currently doesn't change this, it just removes the reference to gimp-remote from the gimp.desktop file.

My understanding is that d-bus doesn't work on MS Windows yet.

Sure, but how is that related? There are other platforms where it is also likely not going to be available. My question was about what to do when dbus-glib bindings are detected at configuration time. We could decide not to install gimp-remote under these circumstances. We could also argue that people have gotten used to gimp-remote. And that it doesn't hurt to build and install it no matter if the gimp executable has similar built-in functionality or not.

Sven

Hi,

On Fri, 2007-01-19 at 10:05 +0100, Alessandro Falappa wrote:

(3) Should gimp-remote still be built and installed even if the d-bus functionality is built into the gimp exectuable? The patch currently doesn't change this, it just removes the reference to gimp-remote from the gimp.desktop file.

IMHO yes.

May I ask why that's your opinion?

Sven

Hi,

On Sun, 2007-01-21 at 20:14 +0100, Alessandro Falappa wrote:

If there's no mean to detect d-bus availability one can leave the choice between using either the new code or gimp-remote to the user via configure switches.

We can detect the availability of the dbus-glib bindings at build time. But there is still the possibility that no dbus daemon is running in the session where gimp is being used.

Sven

Hi,

On Fri, 2007-01-19 at 09:30 +0100, Sven Neumann wrote:

There are a few things that we probably should address:

(1) We might need a way to override this behaviour. Under certain circumstances it might be useful to have multiple instances of GIMP running. A command-line option could be added to enforce this.

There is --new-instance (or just -n) now for this purpose.

(2) What should happen if gimp is already runnning and gimp is launched again but with no files or URIs on the command-line? IMO it would be best if gimp exported a method to the bus that allows the toolbox to be raised. Instead of launching a second instance, we could just raise the first one then. Does that make sense?

GIMP now exports two methods. "Open" takes an array of URIs or filenames. It silently does nothing if that array is empty. "Activate" raises the toolbox. The method names are inspired from libguniqueapp but if anyone wants to come up with something better, I am open for suggestions.

(3) Should gimp-remote still be built and installed even if the d-bus functionality is built into the gimp exectuable? The patch currently doesn't change this, it just removes the reference to gimp-remote from the gimp.desktop file.

For now gimp-remote will continue to be built and installed. I hope that it can be deprecated in the next release.

Sven