Modulegroups regressions

[wpferguson]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

I always work with the active modules tab selected with all modules displayed.

This is the first time I've used darktable in a while and now it

• always displays the tab next to active modules when a new image is loaded
• switching to the active modules tab shows the active module
• clicking again to show all modules has no effect
• now there is a right click to show a popup to select all modules. This is a default behavior change with no warning/discussion.
• when you click it, it still doesn't show all modules.

Steps to reproduce

1. Load an image in darkroom
2. click on the active modules to display the active modules
3. click the active modules to display all modules
4. notice display doesn't change
5. switch to a new image
6. notice active modules isn't display, instead the first tab is displayed
7. click on the active modules tab to display the active modules
8. right click on the active modules tab and check the checkbox to display all modules
9. Notice all modules are not displayed
10. Go to next image and do all of this again :-(

Expected behavior

Should behave the way it does in 5.6

Logfile | Screenshot | Screencast

No response

Commit

Tried to bisect but there are so many bad commits in the gtk4 stuff you can't get darktable to compile (I gave up after 5 bad commits in a row)

Where did you obtain darktable from?

self compiled

darktable version

5.7.0+411~g5aee192e7a

What OS are you using?

Linux

What is the version of your OS?

Ubuntu 22.04

Describe your system

No response

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

Nvidia 3070 latest drivers

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

I looked back through the commit log for modulegroups.c and most of it is gtk4 changes

My editing workflow is based on the active module group with all modules displayed, so currently darktable is broken for me.

[wpferguson]

@Arecsu I think this is probably related to the gtk4 work

bad commit:

commit e3458e7
Author: Arecsu alejandro9r@gmail.com
Date: Sun Jul 26 22:44:50 2026 -0300

gtk4-prep: IOP module event controllers

[wpferguson]

@TurboGit I'm somewhat concerned by this issue. My understanding was the gtk4 changes were changing the gtk3 controls to the gtk4 equivalents. I didn't expect random changes to default behaviors. I did a quick look at modulegroups.c and there were chunks of logic removed that had to do with functionality and not controls. I'm guessing AI is making the changes, but it seems that more oversight/testing may be required.

[Arecsu]

I'd love to see the chunk of logic that got removed that had to do with functionality, it would be really helpful. If possible as well, what does account for random changes to default behaviors. Thanks

[jenshannoschwalm]

@wpferguson just noting we also had "my" c2bf7c1

[TurboGit]

@TurboGit I'm somewhat concerned by this issue. My understanding was the gtk4 changes were changing the gtk3 controls to the gtk4 equivalents.

Yes and no. We cannot change to Gtk4 code but remove the deprecated Gtk3 code to be Gtk4 compliant. Of course no regressions are expected, but this is difficult as the equivalence of the Gtk API is not guaranteed and some part needs quite some rewriting. That's why I have merged this early in the release cycle to ensure that all remaining glitches are fixed for 5.8 final release.

It reminds me too that I should not merge new Gtk4 prep changes close to the release.