Describe the bug
---This bug only occurs to me sporadically---
Similar thing happens in color zones and contrast equalizer.
e.g. I wanna increase the blues in the sky, I use color zones to darken the blues and increase the saturation of the blues. Usually at the end of the editing process or close to the end...
What then happens after I activated color zones and it is maybe already in the lightness, the active curve is actually the one from saturation.
As I said above, have similar experiance with contr. EQ. I wanna adjust luma, but it reacts on chroma, even though luma is the active tab
It is a little bit similar than what happened time ago to #5466
Expected behavior
The tab which is activated should represent the active curve of the module (or vice versa)
Screenshots

Platform (please complete the following information):
I reproduce this on color zones on ArchLinux on the same release. It seemed for a while as if I had a consistent way to reproduce it then I changed tab and it was ok again. Could this be related to the changes in #5661 @dterrahe? I'm just guessing because it was the last thing that might have messed with these notebook tabs.
I'm looking into this. #5661 didn't really touch much of the logic, just refactored some setup calls, so I would be surprised.
I guess somewhere the tab gui_data_t _thinks_ we're on gets out of sync with the tab that is actually active. Rather than forcing them back in sync, I'd rather figure out where it goes wrong and fix that. First need to reliably reproduce...
Could it be this is a long standing issue? I'm not going to ask AlexG to bisect without a sure-fire reproduction.
Yes it could be a long-standing issue. I spent a while on it yesterday and I've been unable to come up with a reliable way to reproduce it. I'll give it another try some time today.
I'm seeing the problem; it's just that when entering darkroom, gui_init doesn't successfully set the desired tab (which was stored in plugins/darkroom/colorzones/gui_channel & plugins/darkroom/atrous/gui_channel).
gtk_notebook_set_current_page probably doesn't reliably work in gui_init (since the widget hasn't yet been added to the gui), so this may have to be redone in reload_defaults. One of the ugly hacks that's unfortunately necessary. I'll submit a patch hopefully shortly (if it works...)
As usual, it turns out I _did_ break it in #5661. The
gtk_widget_show_all(GTK_WIDGET(gtk_notebook_get_nth_page(c->channel_tabs, c->channel)));
_was_ required. Or at least the simpler version
gtk_widget_show_all(GTK_WIDGET(c->channel_tabs));
So I put those back. Also in rawdenoise, where it wasn't as obvious, because the selected page didn't get saved. Only someone who had manually (permanently) set it in plugins/darkroom/rawdenoise/gui_channel would have noticed.
I'm now updating that setting when leaving darkroom, so it'll be sticky like in the other two.
I do keep breaking things when cleaning up, but unfortunately there is so much boiler plate that got copied over everywhere without any good reason and that nobody dares to touch afterwards (because, you know, it might break things) and that makes it harder to make improvements later. I'm very grateful to @AxelG-DE for catching much of the breakage (and @elstoc to trace it back to me). In the end, I do think code quality improves as, like here, I try to put back simpler/more readable/maintainable code.
Most helpful comment
As usual, it turns out I _did_ break it in #5661. The
gtk_widget_show_all(GTK_WIDGET(gtk_notebook_get_nth_page(c->channel_tabs, c->channel)));_was_ required. Or at least the simpler version
gtk_widget_show_all(GTK_WIDGET(c->channel_tabs));So I put those back. Also in rawdenoise, where it wasn't as obvious, because the selected page didn't get saved. Only someone who had manually (permanently) set it in
plugins/darkroom/rawdenoise/gui_channelwould have noticed.I'm now updating that setting when leaving darkroom, so it'll be sticky like in the other two.
I do keep breaking things when cleaning up, but unfortunately there is so much boiler plate that got copied over everywhere without any good reason and that nobody dares to touch afterwards (because, you know, it might break things) and that makes it harder to make improvements later. I'm very grateful to @AxelG-DE for catching much of the breakage (and @elstoc to trace it back to me). In the end, I do think code quality improves as, like here, I try to put back simpler/more readable/maintainable code.