Simultaneous runs of geeqie interfere with each other

[dkogan]

ISSUE TYPE

• Bug Report

GEEQIE VERSION

Geeqie 1.5.1+git20201108-5dc8b463

gtk3

OS / DISTRIBUTION

Debian/sid

SUMMARY

Same as #676. I run geeqie to look at some images. While that is up, I run geeqie again in another shell to see some other images, and the second instance doesn't show me the images I asked for

STEPS TO REPRODUCE

1. cd directory1
2. geeqie directory11/image1.jpg. The window comes up showing me image1.jpg
3. In another shell. cd directory2
4. geeqie directory22/image2.jpg. The window comes up showing me directory22/image2.jpg. This is correct
5. Close this window and instead do geeqie directory22/image2.jpg directory22/image3.jpg

At this point a new window comes up, but it's not showing me either of the images I asked for. Instead it's showing me the first image in directory2 (not directory2/directory22).

Can we PLEASE disable the multiple-windows-one-application thing, at least optionally? In addition to causing bugs such as this, it's also not interacting with the terminal in ways I would expect: in steps 4 and 5 above I get the terminal prompt back immediately, NOT after the new geeqie window is closed. This breaks very common workflows. For instance I might do this:

while true do; run some program that generates an image; geeqie image; done

I want the program to run, then I look at the output. When I'm done looking at the output I want the program to run again to produce new output. If the geeqie command returns me to the terminal while the window is still open, it's going to start computing the new output while I'm still looking at the image, and then it will try to start up a new geeqie while I'm still looking at the previous image. This is not right. I'd love an option to turn the remote off.

Thanks a ton for working on this!

[caclark]

Can we PLEASE disable the multiple-windows-one-application thing, at least optionally?

The option is geeqie -n --new-instance

Note that there is only one geeqierc.xml file. You might need to set XDG_CONFIG_HOME if you want totally separate runs - but that will create other problems.

[dkogan]

Oh, that is VERY helpful. Thank you.

I'm looking at geeqierc.xml. It looks like it's storing window geometry and preferences settings, so the independent geeqie invocations would clobber each other's data. I think this is probably OK if geeqie only wrote CHANGES into that file, not STATE. It's currently writing state, so this sequence is doing the wrong thing:

1. Start geeqie 1
2. Start geeqie 2
3. In geeqie 2 change anything that ends up in the geeqierc.xml. For instance, turning on the sidebar with Ctrl-k
4. geeqie 2 hasn't written the settings yet, so a 3rd geeqie instance doesn't have the sidebar enabled
5. Exit geeqie 2. It now writes the settings, so a 3rd geeqie instance launched now DOES have the sidebar
6. Exit geeqie 1. The original geeqie now writes its state to geeqierc.xml, even those items that haven't changed. So the sidebar setting goes back off

This is unexpected because the last thing the user did was to turn off the sidebar, and exiting the unrelated geeqie 1 flipped that setting back.

I think an easy way to fix this would be to write into geeqierc.xml when settings are updated, and not when geeqie exits.

Thank you again.

[caclark]

This is unexpected because the last thing the user did was to turn off the sidebar, and exiting the unrelated geeqie 1 flipped that setting back. I think an easy way to fix this would be to write into geeqierc.xml when settings are updated, and not when geeqie exits.

The config. file has two sections: a single <global> section and a layout section containing one or more <layout> defines.

Each window has a unique ID. Each new window is allocated an ID starting with the characters lw. These windows are assumed to be temporary. When you close a single window, it is gone forever.

If you quit Geeqie, all open windows will be saved, with each window having its own <layout> section in the config. file. On next start, the layout of all windows will be restored.

If you rename a window to something other than lw...., its layout will always be remembered e.g. I have one labelled "maps" and another labelled "exif".

[dkogan]

Adding a note here to continue the report piggybacked at the end of https://github.com/BestImageViewer/geeqie/issues/863. I'm seeing a version this issue again. Don't know about what parts are significant, but here's the recipe (can probably simplify it). I'm at https://github.com/BestImageViewer/geeqie/commit/955709eb5885dd130cc47aee493d193df982a3de

1. First window: geeqie -n /tmp/a.png. Note I'm asking for no remote here

2. Second window: geeqie /tmp/b.png /tmp/c.png. Remote kicks in, new window comes up showing some other image, that's not a or b or c, the geeqie process I just executed exits immediately and so on.

Is that what we expect from the current geeqie? I mostly haven't seen these issues recently since I run with an alias "geeqie" = "geeqie -n", but when running from source I execute ./geeqie, and the alias doesn't kick in, and I see these again.

[caclark]

I still do not see this effect. There must be another factor influencing this.

[dkogan]

I just tried this again, with the latest build of geeqie (pulled just now). This is 100% reproducible on my end. Do we expect the remote to no longer be confusing things? I aliased it away earlier, so I don't see the problems anymore. Just stumbled on this again accidentally earlier because accidentally bypassed my alias.

I just made sure the extra files in the directory aren't confusing it: removed all but the 3 files in question, and a "0.jpg" which is displayed even though it shouldn't be. I also made sure shell aliases aren't the issue.

[caclark]

Perhaps I am misunderstanding the problem. This is the sequence I executed: geeqie -n /tmp/a.jpg & geeqie /tmp/b.jpg /tmp/c.jpg And attached is a screenshot of the result.

[dkogan]

That's what I'm doing. But the second command shows an image that's not any of these 3. I'm running from source, so it's ./geeqie. And it's my own images, obviously. But it should the be same, otherwise.

This was an issue with the remote earlier. Do we think it was fixed?

[caclark]

This was an issue with the remote earlier. Do we think it was fixed?

I have lost track of too many things on this project :-( Whatever the problem was, please remind me what it was.

Re. the above problem, if the second call loads a default directory, that means that main.c did not find the requested file - but with the latest sources, that should result in a warning pop-up message. Try running the second call as geeqie --version to see what you are executing. If that is no help, run the second call as geeqie --debug=1. That will produce all the debug calls within main.c

[dkogan]

Thanks for the suggestion. This issue was 100% reproducible, even with rebuilding the sources, but now it all works again. If it comes up again, I know how to debug.

And I looked at the older issues to remember the progress of this. #676 is the earlier report that was fixed. THIS one (#823) is a new report with a very similar issue that I guess was never officially fixed, but I can't reproduce it exactly anymore, so maybe this issue should also be closed. However, in trying to reproduce it, I do see other weirdness regarding the remote. Essentially this:

1. geeqie a.jpg
2. geeqie b.jpg in another shell. This triggers the remote, and opens another window that's a part of the same process
3. 'q' to quit. My expectation was that it would only close the one window I just opened with the command I typed, but it closes both. I guess it's debatable
4. Both windows are now closed. I now geeqie a.jpgagain. Instead of getting one window to show me a.jpg, I get two windows. They show different things, depending on the details of what I was looking at earlier

I'm running with geeqie -n all the time now, so I don't see these issues if I don't go looking for them. So maybe we can just close this.

Thanks for maintaining geeqie