RFC(?): Hide `rotate pixels` module in the modules panel

[victoryforce]

CONS:

• We lose the ability to turn off this module in the modules panel and see the image from the Super-CCD camera in the form of a beautiful rectangle standing on the corner.

PROS:

• More screen real estate in standard module layouts, as a result of removing the module header from the panel.
• A module with no controls, but which can nevertheless be selected and expanded, is at least surprising, if not annoying, because of its absolute lack of usefulness.
• The era of Super-CCD models from one camera manufacturer has passed so long ago that probably 99.9% of users (if not more) don't even understand what we are talking about. For them, this module in the modules panel is just a rectangle that takes up space there for no clear reason and therefore adds to their anxiety because they cannot understand what purpose this module is there for.

[victoryforce]

Setting the flag to hide a module from the panel is obviously safe. So we don't need to push the change six months ahead because there's not enough time to evaluate and field-test the safety of the change. I don't think it takes that long to make decision about safety.

It's really about whether there's any reasonable need to show this module in the panel or not.

I agree that showing in GUI even a module that has no controls can still make sense IF we can benefit from disabling such a module, or creating another instance, or moving it to another place in the pipeline. But this is not the case with this module. It already has the IOP_FLAGS_ONE_INSTANCE flag. There's also no point in turning off the module (and having the image standing on the corner) or moving it around in the pipeline.

@TurboGit What's your take on this?

[TurboGit]

My take on this is that I'm ok, but the dt philosophy is to show everything. Sure it is safe, but I want to have more feedback on this. Sure pushing this for 6 months again is long... but we've lived with that for far longer, so let not rush and have a proper discussion amongst devs.

[victoryforce]

My take on this is that I'm ok, but the dt philosophy is to show everything.

We already have exceptions, so I wouldn't call it philosophy. We have hidden modules "finalscale" (hidden from the very beginning) and "display encoding" (hidden when its controls and most of its functionality moved to the "output color profile" module).

[victoryforce]

The only philosophy related to modules is to never remove module code from the program so as not to break old edits.

Also, we have 17 hidden modules due to the deprecated status (that's almost every fifth one!). So we definitely don't have a philosophy like "show everything".

I don't understand why we can deprecate a module with controls to hide it because we don't want users to use it anymore, but we can't hide the module simply because it's meaningless to show it.

Also, when we justify obviously bad parts of the UI by saying that's the way we do things, that's just bad UI design, not philosophy. Philosophy doesn't require a rectangle in the module panel that doesn't serve any purpose.

[jenshannoschwalm]

1. About the "show everything" policy, For me this not about being deprecated or not. We show all currently supported modules even if they can't be applied due to technical reasons. Just think of all raw space modules when developing a non-raw file. We have "not applicable" notes plus a tooltip explaining why this is not possible.
2. Still i agree here on making this module hidden as it is soooo specific. We also have other sensor variants like 4channel bayer and don't expose that.