P: Dehaze slider behaves as if it is in the Effects panel

[Victoria Bampton LR Queen]

[Update: When the Dehaze slider was moved into the Basic panel, several aspects of the slider didn't get correctly updated for the new location:

- The Effects panel toggle switch still disables the Dehaze slider.

- The "." and "," keyboard shortcuts skip over the Dehaze slider:
https://feedback.photoshop.com/photoshop_family/topics/if-the-effects-panel-is-disabled-the-dehaze-s...

- The SDK AP LrDevelopController.revealAdjustedControls(), used by MIDI controllers and such, still thinks the slider is in the Effects panel:
https://feedback.photoshop.com/photoshop_family/topics/if-the-effects-panel-is-disabled-the-dehaze-s...

-- John Ellis]

In Lightroom Classic 7.3 on macOS 10.13.4, if the Effects panel switch is toggled off, the Dehaze slider in the Basic panel also gets disabled.

[J453]

Thanks. The Engineers are looking into this issue for a fix in the next release.

[bhousto90]

Same for Windows 7

[Boudewijn Pelt]

Well, the Dehaze slider has moved, nice.
Unfortunatly it is bugged, if you use a plug-in, like LrControl for example, that modifies Dehaze with the option to reveal adjusted controls "LrDevelopController.revealAdjustedControls()", Lightroom reveals the effects panel, effectively hiding the Dehaze slider instead of revealing it.
So it looks like Lightroom "thinks" the Dehaze slider is still in the old location.

[ssoukup]

This issue was NOT replicated on my Lightroom Classic v7.3 on Windows 10 x64 bit Dell XPS 15 core i7-7700 laptop. Even if I disabled the Effects section by unchecking the Effects check mark I still had access to the Dehaze Slider on the Basic panel

[Samoreen]

I can see this bug in Windows 10 with version 7.3.1. Once again, this raises the same returning question : how could this escape a simple quality control ?

Also, this is a clear indication about the user interface management. If a setting belonging to a given panel can be disabled when another panel is disabled, there's obviously something wrong in the way the state of the various UI elements is managed. There are other old bugs (still not fixed) that are giving exactly the same signal.

The UI elements state must be managed globally in order to avoid inconsistencies. This is a classical issue in software design and the methodology to avoid this is known since a long time. Back to school... Or quit subcontracting to offshore developers.

[johnrellis]

After the slider was moved from the Effects panel to Basic, someone forgot to update the "enabled" attribute of the slider to no longer refer to the setting of the Effects on/off switch.

[Butch_M]

'Someone forgot?' ....

Well ... someone also forgot what QC/QA is as well.

But when you have a bountiful pay-to-play beta testing pool (a group most other billion dollar software developers would refer to as 'customers') I guess you don't have to put as much emphasis on attention to detail.

I don't expect perfection, but this sort of thing shouldn't have escaped even a modest check and balance system to follow-up when moving tools around in the UI layout.

I applaud the team and management for responding to and implementing such changes to smooth out end user workflow efforts ... but ... the details do matter and should be child's play for engineers of such caliber that work on these changes.

[John_Hoffman]

Good morning. I think there is a bug in 7.3.1 relative to the Move Between Sliders "." (Period key) shortcut. It skips over the Dehaze slider.

[johnrellis]

My testing shows this has been fixed in LR 7.4: The "." and "," shortcut keys properly move to and from the Dehaze slider; the Effects panel toggle doesn't grey out the slider; and the SDK's LrDevelopController.revealPanel() and .revealAdjustedControls() behave properly with respect to the slider.