styles module: hide option to create duplicate in darkroom view

[deekayhd]

Proposal for issue #20173:
Due to a recent change it is now possible to add styles module to the darkroom view. However, the option to create a duplicate before the application of the style does not work there.
Therefore, I propose to deactivate and hide the checkbox in the darkroom view.

Of course, it could be discussed, why this module can be used in darkroom, at all, as there is already the possibility to apply styles in the darkroom view via the quick access.

[TurboGit]

Looks good, just some style fixes. TIA.

[wpferguson]

Tested, works for me...

[deekayhd]

Tested, works for me...

Thanks for testing. :-)

[deekayhd]

Proposal for the release notes (if needed):
Fixes an inconsistency in the styles module UI when shown in the darkroom view. It is not possible to create a duplicate to which the style is applied, and the setting of the corresponding checkbox has just been ignored. To avoid confusion, the checkbox is now hidden in the darkroom view.

[Garry611]

I think I might have missed something in the discussion. The checkbox was reported as not working and instead of a modification to have it actually function and function correctly, the option selected was to hide the feature. I'm not sure other alternatives suggested to justify the removal provide the same workflow functionality.

[TurboGit]

The checkbox was reported as not working

It was not working intentionally, we don't create a duplicate from a style in darkroom. The darkroom is to work on a single picture, the one on the center area.

[TurboGit]

Something not working on my side. On lighttable select the duplicate checkbox in the module. Enter darktable, back to lighttable and see that the checkbox is visible but has not been selected.

[deekayhd]

Something not working on my side. On lighttable select the duplicate checkbox in the module. Enter darktable, back to lighttable and see that the checkbox is visible but has not been selected.

Yes, I also noticed that. See my last commit. Thanks for your thorough testing.

[dterrahe]

Alternatively, simplify the whole thing by not changing the active state of the toggle and making sure that it is ignored when in darkroom. This mean just adding dt_view_get_current() != DT_VIEW_DARKROOM && in the one case (in _entry_activated) where that currently isn't the case.

Then view_enter can simply do

gtk_widget_set_visible(d->duplicate, new_view->view(new_view) != DT_VIEW_DARKROOM);

[deekayhd]

Alternatively, simplify the whole thing by not changing the active state of the toggle and making sure that it is ignored when in darkroom.

I thought about that, too. But it seems safer to me to actually change the toggle. You never know what will be changed later in the module. Someone may see that there is a toggle in dt_lib_styles_t and check the state not thinking about the restriction in darkroom view. Yes, there is already a separate apply method for the darkroom, but with the current logic, it is more explicit.
Do you think my concerns are unjustified?

[dterrahe]

Do you think my concerns are unjustified?

Rather the opposite! I'm sure people will break things, no matter what you do...

[deekayhd]

I think I might have missed something in the discussion.

@Garry611 I can understand you confusion. However, my impression is that there is a consensus among the core developers who commented here (TurboGit, dterrahe, wpferguson), that the creation of duplicates is not wanted in the darkroom view. As TurboGit commented, in darkroom view you work on a single image. Application of a style to that image is completely fine, but creating other versions "under the hood" may also be confusing, as there is no other example for such an operation.
I understand, that the styles module initially was created for the lighttable view only. Then, someone had the idea to offer the utility modules in darkroom view, as well. In case of the styles module, however, there is already a different logic for the handling in darkroom, where the toggle for duplicate creation is simply ignored. So, the "actual" bug you found is that the toggle is visible, even though it is intentionally ignored.