Cannot symlink file if two geeqie instances are running

[mowgli]

I noticed that the File → Create symbolic link menu entry does not work
from a second instance of geeqie, started while another is already
running. It seems that geeqie starts a helper which tries to talk to the
running instance and then talks to the wrong one.

Reported by: nijel

[mowgli]

Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606115

Original comment by: nijel

[caclark]

Fixed in commit 6902246 at geeqie.org.
A second instance cannot be started. Use File/New Window instead.

[tomaszg7]

That is really not a solution, it broke more than it fixed. You made Geeqie silently exit without giving a reason when one attempts to start a new instance. For example, when you have Geeqie already running and you click on an image, nothing will happen. That is both confusing and counterproductive. I don't even see a command line option to work around the problem.

I think some kind of solution would be to make Geeqie pop out a new window automatically when one tries to start a new instance. It would be even better if the behaviour would be configurable, e.g. if user could choose if geeqie image.file should pop a new window or display image in the existing one. I don't see how anyone would expect Geeqie to silently die in this situation.

[caclark]

In the next few days I will make some more commits involving --remote commands and layout window identifiers.
One item included will be a --remote command to open a new window. That will enable a new window to be opened in the initial geeqie instance whenever a second call to geeqie is made.

[tomaszg7]

Still it would be a tremendous complication. Instead of geeqie image.file, you would have to write geeqie --remote --open_new_window --with_image image.file. That's why I believe it should be a default behaviour when an instant is already active. Just like it works with e.g. firefox and many other apps.

[caclark]

It isn't possible to open a new window in the original instance without using the --remote facility (as far as I can see).
When you execute a --remote command, a second instance is created, but all it does is send the command to the first instance, and then terminates.
So what I intend is to include an call to --remote --new-window in that newly amended section of main - that will cause a new window to be opened without the user having to type anything other than "geeqie".

[Also whenever I open an image file from a file manager with right-click open-with, the image is opened in the existing instance. This is because the .desktop file aliases "geeqie" to "geeqie -r" (ok, it isn't an alias, but it has the same effect)]

[tomaszg7]

Ah, great. That's all I meant. But I think it is possible to open a new window using --remote:

view:<FILE> open FILE in new window

However by default it opens "undecorated" window - without menu bar, file browser and so on.

BTW. It is not explicitly stated in geeqie's help and remote help output that geeqie -r <FILE> is a correct command. It only lists geeqie -r file:<FILE> or geeqie -r File:<FILE>

[caclark]

Commit 01fd562 at geeqie.org contains the changes

[tomaszg7]

Now it's much better, however cluttering window title with window ids is not an elegant solution. Only a handful people will probably use the new --id command, so it might be a good idea to make it configurable (maybe even disabled by default). Maybe even window title could be configurable in a similar way as overlay. That's something e.g. GIMP does.

[caclark]

configurable in a similar way as overlay. That's something e.g. GIMP does.

There is a "Pimp my Gimp" webpage! Who says programmers have no sense of humour. Maybe there should be a "Geek my Geeqie" page.

Commit fcf4c37 at geeqie.org makes the display of ID selectable. Off by default.

[tomaszg7]

Didn't you delete by mistake the line
options->save_dialog_window_positions = FALSE;
from options.c?

[caclark]

Thanks.
Committ 379823d at geeqie.org