fix: scroll to correct module when navigating from Quick Access Panel

[vtyrtov]

When clicking 'go to full version' in the Quick Access Panel, the view would sometimes scroll to a wrong module (though the correct tab was always selected). This happened because dtgtk_expander_set_expanded() was a no-op when the target module was already expanded, leaving stale _last_expanded and _start_pos values from a previous expansion. The _expander_resize callback would then either skip scrolling or scroll to the wrong widget.

Add an 'else if(expanded)' branch that updates scroll tracking even when the expander state hasn't changed. Setting _start_pos.height to 0 ensures _expander_resize detects a size change and triggers scrolling.

Fixes: #19692

[TurboGit]

Do you have a reproducer? Seems like it needs some special procedure as not reproducing in all cases.

As we are at it, while testing I found another issue worth fixing at the same time.

• In Darkroom's preferences allow to expand multiple modules
• In Darkroom tone group expands multiple modules including exposure.
• Go to quick access panel, find exposure and click on go to full version button.

See that it moves to tone tab but all modules (except exposure) are collapsed. Seems like this violate the preference. Can you have a look at this? TIA.

[vtyrtov]

Yes, reproduces here.
My workflow: Quick Access → presets → then full modules as needed.
This annoyed me since late last year; finally fixing it.
Found it while preparing the PR.

Will check the second issue too.

[vtyrtov]

I've updated the PR to address both issues.

Reproducer for the scroll-to-wrong-module bug:

1. Open an image in darkroom, work with a module (e.g. exposure) — this gives it focus and GTK_STATE_FLAG_SELECTED.
2. Switch to another image.
3. In the Quick Access Panel, click "go to full version..." for a different module (e.g. filmic rgb or color balance rgb).
4. Observe that the view scrolls to the previously focused module (exposure) instead of the target.

The root cause is twofold:

• dtgtk_expander_set_expanded() was a no-op when the target module was already expanded, leaving stale scroll tracking data (_last_expanded, _start_pos).
• _expander_resize() checked height_changed before _last_expanded, so modules with stale GTK_STATE_FLAG_SELECTED (left over from previous images) could steal the scroll target.

Preference violation fix:

Good catch — _basics_goto_module() was hardcoding collapse_others=TRUE, ignoring the darkroom/ui/single_module preference. Fixed to read the preference and only collapse others when single-module mode is enabled.

Testing note:

I've tested the scenarios above and they are resolved, but the interaction between async tab switching (g_main_context_invoke), GTK state flags, and scroll targeting is fairly complex. There may be additional edge cases I haven't covered — any extra testing would be appreciated, especially around:

• Switching between images with different active modules, then using QAP
• Using QAP right after darktable startup (before any module has been focused)
• Modules that appear in multiple group tabs

If you find a scenario that still misbehaves, please let me know and I'll investigate.

[TurboGit]

Tested with different scenario, working on my side now. Thanks!