FR: Local Adjustments -> Ability to move/change spot order.

[jade-nl]

The request:

I would like to see a possibility implemented to move created spots up or down in the list (assuming there are 2 or more spots).

Had a look on RawPedia and on GitHb and this one hasn't come up yet.

The reason why:

The created spots are handled in the order from first (top) to last and all the following spots do influence, or use, the previous spot(s). This can, and in general is, a good thing but it can also be a hindrance.

I ran into the following situation while playing around:

• first spot was used to brighten the face/hat of the subject
• second spot was used to completely change the colour of the dress
• third, fourth and fifth excluding spots where needed to counter some colour leakage from second spot.
• sixth spot targeted some of the green field the subject was in.
• etc.

Two of these excluding spots also, partially overlapped with the first spot and thus negated the brightening of the face/hat.

It would have been nice to be able to select the first spot and move it in between spot 5 and 6.

OK, maybe I should have thought about this before applying the spots, but stuff like this happens and this isn't the only scenario, I can think of a few more that aren't exclusion related.

I do realise that this has impact on the way spots interact but I do believe that that is something the user should be aware of, is part of the power of LA and not in any way blocking for this request.

The current "work-around":

At the moment you can apply a work-around (sort of) by duplicating the spot in question (first spot in above example), replacing (the actual spot, which is shifted slightly when duplicating) in the original place and then deleting the original spot. The duplicate will be put at the bottom. This will solve the afore mentioned excluding spot problem, but one might not want to have the duplicated spot at the very bottom.

[ff2000]

I think I mentioned this once in a report here. I also proposed to be able to actively assign excluding spots to normal spot so it isn't automatically determined (overlap). No idea where this was, unfortunately.

[jade-nl]

If I understand @Desmis correctly this needs to be picked up by someone that has experience in GUI programming.

Yesterday I ran into this again, not the first time since filing this FR, and reached a point where I decided to spend an afternoon to create a solution for this: A (Linux) script that can take care of this.

So just in case people stumble upon this FR hoping for a solution, here's, a hopefully temporary, one: rtsm.sh

[Lawrence37]

It might actually be pretty easy to implement this, except it may interfere with some work being done by @Pandagrapher.

[jade-nl]

@Lawrence37 : Thanks for pointing out #5410, missed that one while initially searching for duplicates.

I do hope work is picked up on this one again, been kinda quiet for a long time, especially if it possibly stops others implementing GUI related changes.

[Pandagrapher]

It might actually be pretty easy to implement this, except it may interfere with some work being done by @Pandagrapher.

I have paused my work on the #5410 issue. The problem is that the implementation of EditWidget class does not help to manage widget overlay built from several elements (circles, lines, ...). According to me, before spending hours to improve the Locallab GUI, times need to be spent on improving the EditWidget class first (and honestly, as there is a risk of regression, I am not motivated to work on it if v5.9 is not released first).