darkroom: add visible drag handle to reorder processing modules

[stnKrisna]

Expose a grip handle at the left of each reorderable processing module header so the module-reordering interaction is discoverable. The handle is a dtgtk button carrying the same iop dnd target as the existing whole-header drag source, so it routes through the identical dt_ioppr_move_iop_* machinery without duplicating any ordering logic.

Whole-header dragging is preserved unchanged and existing users keep their current interaction. The handle is hidden for IOP_FLAGS_FENCE modules (demosaic, gamma) which cannot be moved, and is exempt from the header-button auto-hide/dim preference so the affordance stays visible.

This change improves the discoverability and usability of processing-module reordering by adding a clear visual drag affordance and more explicit drop-position feedback.

Modules can already be reordered, but the current interaction is easy to miss unless users already know that dragging is supported. A visible drag handle makes this capability self-explanatory, reducing reliance on documentation or prior knowledge:

• Makes module reordering immediately discoverable for new users.
• Reduces accidental or confusing drag interactions.
• Improves usability without introducing a new ordering mechanism or changing the underlying pixel pipeline logic.

[wpferguson]

I'm not sure this should be more discoverable. The people that tend to need it are more experienced and have reached a point they understand the pixelpipe and what reordering does. They are also experienced enough to know how to do it.

If you make it easy, then you're going to have new user's arranging the pixelpipe in the order they want to use the modules which is going to lead to horrible edits and LOTS of issues.

I think this is a really BAD idea.

[da-phil]

• Makes module reordering immediately discoverable for new users.

I agree with @wpferguson, this is a functionality which actually shouldn't be discovered by new users early on, due to ramifications and complications involved. It's an expert feature and hiding it from the "normal" UI is not a bad thing IMHO. It just tempts beginners to play with something which is not necessary for most use-cases and then we end up with potential bug reports because they get unexpected results. I don't think it's worth it.

• Reduces accidental or confusing drag interactions.

I don't see how this reduces accidental drag interactions. If you actually engage in a drag interaction the current UI/UX already communicates the intent, so it also cannot be confusing IMHO.

• Improves usability without introducing a new ordering mechanism or changing the underlying pixel pipeline logic.

Honestly, I didn't understand this point. Do you want to elaborate more?

[anoderay]

I also think that this adds visual clutter not worth the issue it sets out to address.

[TurboGit]

I also agree, this take spaces on the header line and not useful as it is an advanced feature.