imageop: fix blank module instance names when not on top of history

[da-phil]

Currently, when you have IOP modules with custom names, they disappear once you go back in editing history, switch back to lighttable and open the same image again, see screencast:

Screencast.from.2026-07-26.13-15-29.mp4

The reason: _iop_panel_name() skipped painting the header label whenever history_end < the number of history entries, so every module's instance name stayed blank when an image was opened with its history slider below the top of the stack. multi_name is already restored per history position by dt_dev_pop_history_items(), so the label is correct at any position.

After the fix:

Screencast.from.2026-07-28.22-32-53.mp4

CC: @TurboGit
It might be good to get your feedback on this change, as you added it a long time ago in commit e93ec95
I assume you treated the panel name as the module's current identity and you didn't want it flickering/blanking during history navigation, so the guard froze the labels while browsing a non-top state. This was solving a cosmetic concern (stable names during scrubbing) in a way that both displayed stale names and left names permanently blank on a non-top open. Since multi_name is always kept correct for the current position, unconditionally painting it is both simpler and more accurate — which is what the change does.

Disclaimer: this work has been co-created with Claude.

[TurboGit]

Really strange, indeed the comment is clear but I don't remember why this was done! Fixing something? No idea now but you proposed change look good to me.

One issue though, if you have history:

10 local constrast - toto
09 exosure
08 local contrast
07 AgX

Say you are on 10, the module is labeled "local contrast - toto" fine.

Now move directly to 07, the module is still labeled "local constrast - toto". This is probably because there is no more local contrast on the history and so the module is disabled. Worth fixing as part of this PR to be fully consistent.

[TurboGit]

BTW, worth testing with multiple instances to be sure there is no corner case explaining the current code.

[da-phil]

Really strange, indeed the comment is clear but I don't remember why this was done! Fixing something? No idea now but you proposed change look good to me.

One issue though, if you have history:

10 local constrast - toto 09 exosure 08 local contrast 07 AgX

Say you are on 10, the module is labeled "local contrast - toto" fine.

Now move directly to 07, the module is still labeled "local constrast - toto". This is probably because there is no more local contrast on the history and so the module is disabled. Worth fixing as part of this PR to be fully consistent.

I cannot reproduce this issue, see screencast:

Screencast.from.2026-08-03.23-41-41.mp4

[da-phil]

BTW, worth testing with multiple instances to be sure there is no corner case explaining the current code.

Works like a charm, I couldn't find an issue. Essentially renaming a module is a dedicated entry in the history, and if you go back in your history, the renaming is reverted, exactly what I'd expect.

[TurboGit]

I cannot reproduce this issue, see screencast:

Because my description is not precise enough :)

The num 11 must be disabled, see:

• So you are on 14 - module is "Contraste local - toto"
• You click directly on 11 - module is still "Contraste local - toto"

As there is not more "Contrast local" in the history, so module should be just "Contraste local"

[da-phil]

The num 11 must be disabled, see:

Hmmm, turns out I cannot disable actions in the history on current master (with my fix applied).
I would just click on the power button symbol, correct?

[Arecsu]

The num 11 must be disabled, see:

Hmmm, turns out I cannot disable actions in the history on current master (with my fix applied). I would just click on the power button symbol, correct?

You mean, the power icon to the right of each element in the history? They just reflects the state of the module that produced that history entry. They go like enabled normal, disabled a bit dim along with the text label.

I would argue the UI/UX of this power icon being there is weird if they are in every single element whether they are enabled or disabled, and we already have the text labels changing opacity as well.

Besides that, to sum it up, no, these power icons do nothing. I have to confess I'm deeply paranoid now about any of those things after my event controllers PR, and I had to do a research to come up with that answer 🤣

[da-phil]

I cannot reproduce this issue, see screencast:

Because my description is not precise enough :)

The num 11 must be disabled, see:

* So you are on 14 - module is "`Contraste local - toto`"

* You click directly on 11 - module is still "`Contraste local - toto`"

As there is not more "Contrast local" in the history, so module should be just "Contraste local"

You're right, I can reproduce this behavior, this is really weird...
I'll also try to address this glitch.

[da-phil]

@TurboGit I think I was able to fix the issue, I pushed another commit

[da-phil]

@Arecsu

I would argue the UI/UX of this power icon being there is weird if they are in every single element whether they are enabled or disabled, and we already have the text labels changing opacity as well.

I know this is a tangent to the scope of this PR but I'd agree, I don't like those power icons either, they suggest a possible interaction in a UX context, which they are not, hence they can easily confuse users.

[TurboGit]

Works for me now, thanks! The fix is clean and simple.