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.


Gimp-developer mailing list

Reply via email to