Activate 100% zoom limit again

[da-phil]

Activate 100% scroll limit again and also make scroll limit configurable through config parameter darkroom/ui/constrain_zoom, which is TRUE by default, keeping the previous
behavior:

• zooming in is limited to 100%
• zooming out is limited to screen-fit

This is an effort to satisfy both use-cases discussed in #21027.

Disclaimer: this work was co-created with Claude.

[da-phil]

It would be great to receive a review from @dterrahe, as he wrote most of the GTK touchpad / mouse input code and introduced the constrain flag.

I'm not sure if we use the constrain flag in the right way which was intended. My understanding was that it constrains the zoom levels in the following way:

• limit zoom to "fit to screen" when zooming out
• limit zoom to 100% when zooming in

Please correct me if this assumption was wrong.

[da-phil]

@TurboGit let's wait merging this PR, I wanted to know if there is a simpler solution to re-activating the zoom limit, see message: #21027 (comment)

I'm not very happy with the current approach in this PR, which is a kind of a hack to limit zooming. It does not work well, when you do the following:

• zoom in to 100%
• press CTRL and zoom in one more step to >100%
• try to zoom in again -> you'll then fall back to 100% again

I believe only reverting #21011 will bring back the old behavior.

CC: @masterpiga

[da-phil]

I pushed a proper fix by revering #21011 and reverting my previous approach of introducing a hard limit and break the soft-steps.
Now it also works properly for pinch-zooming.

The more I deal with this functionality and code, the less I like it. But let's keep this well-known behavior for release 5.6 and keep the discussion in #21027 going ;)
If we would change it, we might also need to update some docs over at https://github.com/darktable-org/dtdocs.

[jenshannoschwalm]

1. I just checked latest version of this PR and for me it works!
2. If this is ok for @TurboGit to be merged i would prefer the commits to be squashed so one commit for possibly need to bisect.
3. I think the darkroom/ui/constrain_zoom misses a restart hint.
4. We now have (too) many options in misc->interface. Maybe a new tab would be preferable including all thouse mouse behaviour related stuff? "Mouse interface" maybe?

[da-phil]

2. If this is ok for @TurboGit to be merged i would prefer the commits to be squashed so one commit for possibly need to bisect.

Works for me, will do.

3. I think the darkroom/ui/constrain_zoom misses a restart hint.

Ah, I see, I didn't pay attention to this little detail in the data/darktableconfig.xml.in file. Will add it then.

4. We now have (too) many options in misc->interface. Maybe a new tab would be preferable including all thouse mouse behaviour related stuff? "Mouse interface" maybe?

Also sounds good, but I think this should be scoped out for this PR into a separate one, right?

[TurboGit]

@da-phil : Do not squash the revert though.

[jenshannoschwalm]

Also sounds good, but I think this should be scoped out for this PR into a separate one, right?

yup.

[da-phil]

@TurboGit is the PR tag "default-behavior-change" even correct, given that we keep the same behavior as in the previous release?

[da-phil]

@TurboGit @jenshannoschwalm I pushed a new commit with the DT_SIGNAL_PREFERENCES_CHANGE approach, however it does not seem to work for me, can you help me pointing out the issue?
The new callbacks are never called, no matter how often I change both params.

[TurboGit]

Let me have a look...

[da-phil]

4. We now have (too) many options in misc->interface. Maybe a new tab would be preferable including all thouse mouse behaviour related stuff? "Mouse interface" maybe?

After another look and knowing how it works I fully agree and would propose the following steps:

• if interface related settings are only relevant for one DT module (e.g. lighttable / darkroom) move those settings inside this respective menu (e.g. prefs="lighttable" section="interface" and prefs="darkroom section="interface")
• consolidate config callbacks a little bit, I think we have way to many callbacks flying around everywhere

[wpferguson]

After another look and knowing how it works I fully agree and would propose the following steps:

if interface related settings are only relevant for one DT module (e.g. lighttable / darkroom) move those settings inside this respective menu (e.g. prefs="lighttable" section="interface" and prefs="darkroom section="interface")
consolidate config callbacks a little bit, I think we have way to many callbacks flying around everywhere

How about we make that a separate PR? PRs that grow in scope tend to not end well.

EDIT: Also, if we are talking about messing with callbacks this should probably be for 5.8 and not something we try and shoehorn into 5.6.

[da-phil]

After another look and knowing how it works I fully agree and would propose the following steps:

if interface related settings are only relevant for one DT module (e.g. lighttable / darkroom) move those settings inside this respective menu (e.g. prefs="lighttable" section="interface" and prefs="darkroom section="interface")
consolidate config callbacks a little bit, I think we have way to many callbacks flying around everywhere

How about we make that a separate PR? PRs that grow in scope tend to not end well.

EDIT: Also, if we are talking about messing with callbacks this should probably be for 5.8 and not something we try and shoehorn into 5.6.

I never said this should be part of this PR, as I agree with you about not blowing up the scope of this PR, it seems @TurboGit is in favour of doing it though: #21031 (comment)

I'm fine either way but would also prefer a separate PR.

[TurboGit]

I never said this should be part of this PR, as I agree with you about not blowing up the scope of this PR, it seems @TurboGit is in favour of doing it though: #21031 (comment)

I'm fine either way but would also prefer a separate PR.

Yes, this change should be part of another PR and probably for 5.8.

[TurboGit]

Works for me, thanks: