On Sun, Feb 06, 2005 at 01:52:40AM +0100, Sven Neumann wrote:

department. What I would like to suggest today is to merge the gimp-remote functionality into the gimp binary. This would eliminate the confusion about which binary to use. It would also give us the chance to reimplement gimp-remote in a less akward way and to integrate gimp-win-remote, the win32 implementation of gimp-remote.

A thing to remember is that even when it is folded into the main gimp binary it still needs special command line switches (otherwise gimp will run into the same problems as mozilla/firebird etc. which often have frontend shell scripts that mistakenly try to contact a running mozilla instance, which only works in single-machine, single-user configs (fixed in debian, btw, but many distros still do this)).

Sven Neumann wrote:

Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine.

I don't know about problems on multi-user machines, but I've had problems when I tried to display Mozilla instances running on different machines in the same X session. IIRC there was even a problem running an MS Windows native Mozilla together with a Unix-mozilla via Cygwin's X server.

Sven Neumann wrote:

Hi,

Roel Schroeven writes:

Would you mind to explain what sort of problems that would be? If we need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine.

I don't know about problems on multi-user machines, but I've had problems when I tried to display Mozilla instances running on different machines in the same X session.

Of course you can't load a local file into a gimp instance running on a different machine but on the same X server. That's not any different to the current situation though. And it would probably be possible to design the remote protocol in a way that avoids this problem. So we can only improve things.

I think we're not talking about the exact same thing.

What I mean is this: suppose you have a remote instance of the Gimp running, and then you want to open a local file in the Gimp. I think a new, local instance should start to open that file, since the remote one can't load that file. But if the remote protocol just looks for a gimp window, it will try to use the existing gimp instance to open the file. Unsuccessfully.

On Sun, Feb 06, 2005 at 02:51:05PM +0100, Sven Neumann wrote:

Would you mind to explain what sort of problems that would be? If we

mozilla ./file

=> file not acesssible (permission denied, other user, inaccessible dir) => file not accessible (different machine) => file not acesssible (different filesystem view)

Assuming that a process has exactly the same view of the filesystem as any other is in general not true. Comparing hostnames helps somewhat in the first case.

There was a debian bug about this against mozilla, but as it is solved, it's archived and I couldn't find it anymore. So at least some people found that annoying enough to have it fixes. (I found it pretty annoying, but didn't file it as a bug report because I thought I would be alone in that opinion :)

Such automatic behaviour presumes single-user (everything is readable to the gimp user) and single-machine (no remote display) configurations, whcih are pretty common nowadays, but universities and other big instalations still often have highly networked environments where this behaviour is annoyung, especially, if, as in the case of mozilla, you couldn't switch it off.

need special command-line switches, we can as well stick to the current solution. As far as I know, the remote feature of mozilla

If the only reason to fold it into the main binary is indeed to get this automatic (but annoying) behaviour, then indeed I see no reason to stick to it. Rifght now, gimp-remote and gimp do semantically very different things. Folding them into the same binary (without different switches) makes behaviour of gimp rather underterministic, especially for scripts etc., and personally I don't think it's worth it.

The best thing would be to have gimp-remote automatically start a background instance of the gimp (as it already does). That way one gets these semantics:

gimp - start a new editing session, return when closed gimp-remote - make sure a session is already running, return immediately

And only the second alternative might run the risk of the file not being accessible.

However, the recent trends in GUIs under unix *is* towards single-user-single-machine configs (witness the problems gnome/kde/debian pose in these environments), so you might just ignore these reasons, assuming that such configs will die out.

works by looking for a mozilla window in the current X session. I don't see what problem that could cause on a multi-user machine.

It's pretty annoying if you have to kill mozilla if you want to look at a file in networked or multi-user environments. With gimp, you have the choice.

On Sun, Feb 06, 2005 at 08:41:30PM +0100, Sven Neumann wrote:

Of course you can't load a local file into a gimp instance running on

This is, of course, possible, but not with the current gimp-remote, and it's probably not that desirable t make it run.

a different machine but on the same X server. That's not any different to the current situation though.

It's very different, the current situation "just works" when invoking gimp. With your proposed change it simply doesn't work.

That *is* a big difference in my book.

And it would probably be possible to design the remote protocol in a way that avoids this problem. So we can only improve things.

I don't thin it is in general. It's possible t ake it work in, say, most circumstances, but I don't think the current behaviouor is so annoying as to make failures acceptable.

On Mon, Feb 07, 2005 at 12:16:33AM +0100, Sven Neumann wrote:

new, local instance should start to open that file, since the remote one can't load that file. But if the remote protocol just looks for a gimp window, it will try to use the existing gimp instance to open the file. Unsuccessfully.

Yes, I understood that. And I said that we already have exactly this problem with the current implementation, so it can probably not become worse.

Daniel mentioned problems that could be caused by moving the gimp-remote functionality to the gimp binary. I asked him to explain what kind of problems that would be. I don't know why you answered to this question since it appears that your answer was unrelated.

I am sorry to get off-topic, but in your recent posts (weeks) you became very very unfriendly towards other people who want to be helpful. I find his answer very related, as he explained a problem that your proposed change would result in, which is basically what you asked.

Now, if you don't want to hear about problems, why are you asking in the first place?

On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann wrote:

Hi,

writes:

Would you mind to explain what sort of problems that would be? If we

mozilla ./file

=> file not acesssible (permission denied, other user, inaccessible dir) => file not accessible (different machine) => file not acesssible (different filesystem view)

Assuming that a process has exactly the same view of the filesystem as any other is in general not true. Comparing hostnames helps somewhat in the first case.

I see the point. But it would be trivial to take care of this, wouldn't it? The remote protocol would have to check if the instance of gimp that is already running on the current X server is a local process or not. Did I miss something obvious?

I think the behavior should be as follows:

By default, gimp should try to connect to a running instance, but *only* if it's on the same machine and running as the same user. gimp --remote (or if argv[0] == gimp-remote) should always attempt to connect to a running instance, and honor the args that the current gimp-remote has. And gimp --new-instance always starts a new instance.

The default in absence of a command line argument should be controlled by an environment variable, for people with uncommon setups (like, differing filesystem views).

That should make everyone happy.

-Yosh

On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann wrote:

Hi,

writes:

Would you mind to explain what sort of problems that would be? If we

mozilla ./file

=> file not acesssible (permission denied, other user, inaccessible dir) => file not accessible (different machine) => file not acesssible (different filesystem view)

Assuming that a process has exactly the same view of the filesystem as any other is in general not true. Comparing hostnames helps somewhat in the first case.

I see the point. But it would be trivial to take care of this, wouldn't it? The remote protocol would have to check if the instance of gimp that is already running on the current X server is a local process or not. Did I miss something obvious?

Yes, you miss the first and last error causes given above. A "local" process proves nothing about file accessibility.

Think about it, X11 is a networked environment. Processes share an X-display, but not the filesystem view. Linux for example provides each process with it's own filesystem view, and this is expected to be used more and more in the future.

The only save protocol would be to tansfer the file contents and name through the x-server (a selection for example), and keep the gimp-remote around to receive the file on saves, which is an awkward solution.

I think having the option of using "gimp-remote" with clearly defined limitations (same filesyetm view required) and using "gimp" to ensure correctness is preferable over some heuristic that gets it right for 95% of the users or so. What advantage does an integrated solution bring? As far as -i can see, it's only badly written programs that mindlessly use "gimp" when they should offer the option of using either gimp or gimp-remote.

On Sun, Feb 06, 2005 at 08:08:29PM -0800, Manish Singh wrote:

I think the behavior should be as follows:

By default, gimp should try to connect to a running instance, but *only* if it's on the same machine and running as the same user. gimp --remote (or if argv[0] == gimp-remote) should always attempt to connect to a running instance, and honor the args that the current gimp-remote has. And gimp --new-instance always starts a new instance.

The default in absence of a command line argument should be controlled by an environment variable, for people with uncommon setups (like, differing filesystem views).

That's a very good approach, as it can be configured system-wide and without requiring commandline args.

That should make everyone happy.

It certainly would make me happy.