RSS/Atom feed Twitter
Site is read-only, email is disabled

replacing gimp-remote

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

9 of 9 messages available
Toggle history

Please log in to manage your subscriptions.

replacing gimp-remote Sven Neumann 19 Jan 09:30
  replacing gimp-remote Alessandro Falappa 19 Jan 10:05
   replacing gimp-remote Sven Neumann 19 Jan 20:30
    replacing gimp-remote Alessandro Falappa 21 Jan 20:14
     replacing gimp-remote Sven Neumann 22 Jan 08:27
  replacing gimp-remote Sven Neumann 23 Jan 08:59
replacing gimp-remote William Skaggs 19 Jan 17:48
  replacing gimp-remote Michael Natterer 19 Jan 18:11
  replacing gimp-remote Sven Neumann 19 Jan 19:42
Sven Neumann
2007-01-19 09:30:23 UTC (about 17 years ago)

replacing gimp-remote

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

Alessandro Falappa
2007-01-19 10:05:47 UTC (about 17 years ago)

replacing gimp-remote

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.

I agree: from a translator point of view I would find useful the capability of launching two GIMP instances with different locales (from two terminals with a properly set LANG environment variable)

(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?

Yes. Would this behaviour cope also with an instance running in a workspace not currently displayed ?

(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.

William Skaggs
2007-01-19 17:48:38 UTC (about 17 years ago)

replacing gimp-remote

Sven 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.

-- Bill


______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

Michael Natterer
2007-01-19 18:11:30 UTC (about 17 years ago)

replacing gimp-remote

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

Sven 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.

And so doesn't gimp-remote -> no regression :)

ciao, --mitch

Sven Neumann
2007-01-19 19:42:41 UTC (about 17 years ago)

replacing gimp-remote

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

Sven Neumann
2007-01-19 20:30:29 UTC (about 17 years ago)

replacing gimp-remote

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

Alessandro Falappa
2007-01-21 20:14:55 UTC (about 17 years ago)

replacing gimp-remote

Il giorno 19/gen/07, alle ore 20:30, Sven Neumann ha scritto:

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?

Misunderstanding of question from my side. I actually meant "yes, the new d-bus approach should be preferred over gimp-remote".
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.

Cheers. --
Alessandro Falappa
web: http://www.falappa.net

-- Alessandro Falappa
web: http://www.falappa.net

Sven Neumann
2007-01-22 08:27:35 UTC (about 17 years ago)

replacing gimp-remote

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

Sven Neumann
2007-01-23 08:59:35 UTC (about 17 years ago)

replacing gimp-remote

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