darktable icon indicating copy to clipboard operation
darktable copied to clipboard

Bugfix: Make darktable 4.6 supporting GIMP

Open jenshannoschwalm opened this issue 1 year ago • 6 comments

The GIMP darktable loader does some regex searching after calling darktable --version, this expects

  1. "this is darktable ..." as the initial string, in master we have "darktable ..."
  2. "Lua support enabled" somewhere following

We might want to make the GIMP team aware of the textual changes but until that has been fixed upstream we make sure we use the old style if we use the --version switch. EDIT: discussion with gimp team started

Fixes #15968

jenshannoschwalm avatar Dec 27 '23 20:12 jenshannoschwalm

Even the last line Lua is needed:

this is darktable 4.7.0+77~gc634e7a95f-dirty
Copyright (C) 2012-2023 Johannes Hanika and other contributors.

Compile options:
  Bit depth              -> 64 bit
  Debug                  -> DISABLED
  SSE2 optimizations     -> ENABLED
  OpenMP                 -> ENABLED
  OpenCL                 -> ENABLED
  Lua                    -> ENABLED  - API version 9.2.0
  Colord                 -> ENABLED
  gPhoto2                -> ENABLED
  GMIC                   -> ENABLED  - Compressed LUTs are supported
  GraphicsMagick         -> ENABLED
  ImageMagick            -> DISABLED
  libavif                -> ENABLED
  libheif                -> ENABLED
  libjxl                 -> ENABLED
  OpenJPEG               -> ENABLED
  OpenEXR                -> ENABLED
  WebP                   -> ENABLED

See https://www.darktable.org/resources/ for detailed documentation.
See https://github.com/darktable-org/darktable/issues/new/choose to report bugs.
Lua support enabled

I'm ok to merge into 4.6.1 (only) to fix GIMP support but not in master where I do prefer waiting for GIMP loaded to be fixed.

TurboGit avatar Dec 29 '23 08:12 TurboGit

Fine with me. I would suggest to offer a darktable --gimp-support switch simply returning "OK" ? Would check with the gimp team?

jenshannoschwalm avatar Dec 29 '23 09:12 jenshannoschwalm

Fine with me. I would suggest to offer a darktable --gimp-support switch simply returning "OK" ? Would check with the gimp team?

Would certainly be better to have such option as we would avoid in the future to break things again.

TurboGit avatar Dec 29 '23 09:12 TurboGit

For me it's ready for 4.6 or would you prefer a "decent" 4.6 PR?

BTW i opened a ticket at GIMP

jenshannoschwalm avatar Jan 02 '24 19:01 jenshannoschwalm

My idea was to wait and add here the --gimp-support option otherwise when GIMP implements the new way darktable 4.6.x won't work anymore. So maybe better wait for GIMP devs feedback. If no decision taken when we do the 4.6.1 release we will merge this.

TurboGit avatar Jan 03 '24 08:01 TurboGit

Agreed.

jenshannoschwalm avatar Jan 03 '24 08:01 jenshannoschwalm

A small note to confirm that we'd be very happy for a dedicated flag. See the discussion here: https://gitlab.gnome.org/GNOME/gimp/-/issues/10572

In particular, we are discussing with @jenshannoschwalm a possible evolution of having this flag producing structured syntax to allow for easier evolution. And this even evolved further with some of the contents being the CLI options to use, so that it's controlled on darktable side rather than hardcoded in the GIMP plug-in.

This way, it would make you much more free to have things evolve and GIMP would not break when you change something; nor would our plug-in need to be updated when you add new interesting features we should use.

Jehan avatar Jan 11 '24 02:01 Jehan

Reading thru the GIMP thread, it is starting to sound like the flag should be a new feature for 4.8 vs a 4.6.1 fix. They might benefit of using darktable-cli

gi-man avatar Jan 13 '24 22:01 gi-man

How to proceed on this? Let's see how fast the gimp people can integrate the new darktable gimp API?

jenshannoschwalm avatar Feb 02 '24 19:02 jenshannoschwalm

Given that 4.6.1 is targeted a bit after Feb 15th I think this should go into 4.6.x branch.

TurboGit avatar Feb 03 '24 17:02 TurboGit

Maybe a minor compared to the things you guys are dealing here, but just let you know:

  • dt.bldr.sh https://github.com/jade-nl/dt.bldr is relying on this version string to
  • and stumbled when "This is" disappeared.
  • If I am not mistaken, the current implementation might be more robust but I am not 100% sure

AxelG-DE avatar Feb 12 '24 17:02 AxelG-DE

Sorry for not reviewing this sooner on our side. We are currently releasing a dev version of GIMP with a lot of color-management related change which is one of the test focus right now. I'll be able to review whatever needs to be reviewed for the GIMP-darktable integration when it's all settled down (in a few days).

Or else, I just trust you to do the right thing (it's good too 😉).

Jehan avatar Feb 12 '24 17:02 Jehan

@Jehan : I'm cutting the sources for the release in 5 days, this PR will go into 4.6.1 at this stage. So GIMP stable release will be able to use darktable as it was before.

We have now merged in master the --gimp option with the discussed support and this will be available in darktable 4.8 on June 21st.

TurboGit avatar Feb 12 '24 17:02 TurboGit

Manually merged in 4.6.x branch.

TurboGit avatar Feb 15 '24 18:02 TurboGit