Add install script with GIMP version detection

[StarlitLuna]

This PR is a sort of continuation of #190 because it seems that one never got any changes to address PR feedback.

I based this branch off of the one by @oxidworks and iterated on it by:

detecting whether flatpak is installed first (and prefer the flatpak version) then fall back for native detection.

If gimp is installed, then we query gimp itself to ask for the registered config directory. This has the added side effect that the query itself counts as a first run of GIMP if it has never been run, so this technically eliminates the need for the user to run GIMP first before installing PhotoGIMP if installed through the installer.

I tested this on a fresh install of gimp via a devcontainer.

Another improvement this adds is that technically the flatpak and native install can share the same config directory (confirmed on fedora 44 at least) so it didn't seem ideal to me to rely on assumptions about the flatpak config being in ~/.var which was not true for me for example.

I also modified the installer to only install the flatpak launcher and icons if we are installing to the flatpak version.

@gabrielalmir I think this approach resolves your review feedback items in #190. For the 3rd, I removed the version thing from gimp-3.0 so that it launches without specifying a specific minor version which works for me I think this is what you meant.

closes #166 closes #181

[gabrielalmir]

Hi @StarlitLuna, thanks for continuing the work from #190 and for taking the previous feedback into account. Querying GIMP directly for its config directory looks like a good improvement, especially across different packaging methods.

I noticed a few cases that should be fixed before merging:

• The script should confirm that the detected installation is actually GIMP 3.x. Right now, gimp or the installed Flatpak could still point to GIMP 2.10, and the script would copy GIMP 3 configuration files into that profile.
• It should stop if GIMP is already running, since GIMP may overwrite the configuration when it exits or the installer may modify the profile while it is still in use.
• If both Flatpak and native versions are installed, it would be better to ask which installation should be used instead of always preferring Flatpak.
• A short README section explaining how to run the installer and where the backup is created would also help users.

The general direction looks good. Once these cases are addressed, I think the installer will be in good shape for approval. Thanks again for working on this!

[StarlitLuna]

@gabrielalmir Addressed your feedback in the latest commits:

• Found a function to help with the version check on SO and now we ensure version number is 3 or higher
• We check the installation source for whether or not its running via pgrep or flatpak -ps depending on which source
• We prompt the user to select flatpak (recommended) or native if both are installed (confirmed on my devcontainer where both are installed)
• For the readme part, I agree we should do this but I think it should be a follow up PR. Since the installer script doesn't technically require you to run gimp once anymore, I think it makes more sense for you to decide how you want to handle the readme changes. I.e. do we show the installer as a secondary installation option? Do we remove the old manual instructions? Do we do something else?
  • Alternatively if you want to include the readme update in this PR, could you make the changes to it? edits by maintainers should be enabled
  • Incidentally, the script's output already tells the user where the files are installed to and the backup installation location

Edit:
Added some comments to the detect function to explain my thought process a little bit and added .devcontainer to .gitignore so anyone testing with devcontainers can set theirs up without needing to worry about not committing them.

[oxidworks]

Hello. Author of #190 here. For context: the changes for the review were finished. I just wasn't confident enough in them to publish :-) And I think querying gimp-directory directly is a good move. Two things from testing it:
for cmd in gimp gimp-3.2 gimp-3.0 returns on the first match, so a gimp that still points to 2.10 wins over a gimp-3.0 sitting next to it. The versioned names in that list exist for exactly that case, but they are never reached:

Your version of GIMP 2.10 is not supported.
Please install GIMP 3.x, start it once, then run this script again.

Reproduced with stubs on PATH, gimp reporting 2.10.36 and gimp-3.0 reporting 3.0.4. With gimp removed the same script completes normally. Continuing the loop instead of returning when the detected version is below 3.0 would reach the versioned binary as intended.

Second: pgrep -x "$GIMP_COMMAND" matches the name from command -v, usually gimp. The distro desktop entry launches the versioned binary (Exec=gimp-2.10 %U here), and a process is named after the name it was invoked with, not the symlink target. So GIMP started from the menu isn't matched and the guard passes.

[StarlitLuna]

Hello. Author of #190 here. For context: the changes for the review were finished. I just wasn't confident enough in them to publish :-) And I think querying gimp-directory directly is a good move. Two things from testing it: for cmd in gimp gimp-3.2 gimp-3.0 returns on the first match, so a gimp that still points to 2.10 wins over a gimp-3.0 sitting next to it. The versioned names in that list exist for exactly that case, but they are never reached:

Your version of GIMP 2.10 is not supported. Please install GIMP 3.x, start it once, then run this script again.

Reproduced with stubs on PATH, gimp reporting 2.10.36 and gimp-3.0 reporting 3.0.4. With gimp removed the same script completes normally. Continuing the loop instead of returning when the detected version is below 3.0 would reach the versioned binary as intended.

I moved gimp to last on the loop so that gimp gets selected only when no gimp-3.2 or gimp-3.0 installs are available.

Second: pgrep -x "$GIMP_COMMAND" matches the name from command -v, usually gimp. The distro desktop entry launches the versioned binary (Exec=gimp-2.10 %U here), and a process is named after the name it was invoked with, not the symlink target. So GIMP started from the menu isn't matched and the guard passes.

I'm not able to reproduce this. I installed a gimp rpm, ran it from my desktop menu and the pgrep command detected that gimp was running.

[gabrielalmir]

Hi @StarlitLuna, thanks for addressing the previous feedback. The version check, the installation selection when both native and Flatpak versions are available, and moving the generic gimp command to the end of the detection order are good improvements.

I tested the native and Flatpak installation paths with stubbed commands. The basic installation works, but I found a few cases that should be fixed before merging:

• The restore command only copies the backup over the current configuration. Files added by PhotoGIMP that were not present in the backup remain in the profile, so it does not fully restore the previous state. It may be safer to move the current configuration aside and then recreate it from the backup.
• For Flatpak installations, the script overwrites ~/.local/share/applications/org.gimp.GIMP.desktop, but this file is not included in the backup. An existing launcher or user customization would be lost. The installer should either back it up or install a separate PhotoGIMP desktop file.
• The native process check is still not reliable across packaging methods. pgrep -x "$GIMP_COMMAND" may look for gimp while the actual process is named gimp-3.0 or another versioned name. Also, if pgrep is unavailable, the installer currently prints an error but continues as if GIMP were not running.

It would also be good to use ${XDG_DATA_HOME:-$HOME/.local/share} for the desktop and icon destinations, but I think that and the README update can be handled as follow-up improvements.

The general direction still looks good. Once the restore behavior, launcher backup, and native process detection are addressed, I think the PR will be ready for another pass. Thanks again for working on this!

[StarlitLuna]

Hi @gabrielalmir in order of appearance:

1. I don't know what restore command you're talking about here, the installer doesn't include one as far as I can tell. The backup getting restored is a manual process still, all the installer does is let the user know where the backup is. I believe adding an uninstall script should be what would handle using the backup to restore the original config and uninstall PhotoGIMP which would be out of scope for this PR.
2. I'll add the original desktop launcher to the backup directory.
3. As I mentioned in my last reply, I wasn't able to reproduce this issue. Running any version of gimp whether it's gimp or gimp-3.0 gets detected for me. If you can give me replications steps to actually encounter this issue that would be more helpful. I changed the command to use this pgrep 'gimp|gimp-3\.[0-9]+' instead of the detected command anyway though in case that makes it safer.

I also made these changes:

• The backup directory now includes the config directory itself inside a more general GIMP backup folder, along with any pre-existing icon or desktop launcher file(s).
• The native gimp detection tries to find an install location instead of looping through just 3 random potential command strings, ignoring any gimp that's version lower than 3.0. If any are installed it then selects a 3.x version or just gimp if that is the only gimp native binary. The latest installed native version is preferred.

[StarlitLuna]

@gabrielalmir any update on this? I'd like to close this out.

[gabrielalmir]

Hi @StarlitLuna, thanks for addressing the previous feedback and for your patience while I reviewed the latest changes.

The updated native detection, running-process checks, and backup handling resolve the main concerns from my previous reviews. The installer is now in good shape, and I’m approving the PR.

There is still a possible edge case when identically named GIMP binaries exist in multiple directories in PATH: the script scans a full path but later invokes the selected binary by name. If this becomes relevant in practice, we can improve it in a follow-up by retaining and invoking the full binary path. I don’t consider this necessary to block the current PR.

Thanks again for continuing the work from #190 and seeing this through!