[Windows - Request for Test] Open Infinite Error Windows from Eyedropper #3288

Development Debugging
,
1

Dear (windows) friends,

would you please test the fixed behavior described in the issue with the dev build
https://ci.appveyor.com/api/buildjobs/cctv7pxaq7ijd23t/artifacts/SynfigStudio-1.5.2-testing-2024-06-09-win64-7cfc0.zip (link expires July 9)

and report for have confirmation that it works fine for you.

The user on GitHub who originally reported doesn’t show a lot of activity and we may be waiting for long before his answer :stuck_out_tongue:

Thanks to you in advance and to @rodolforg for his dedication for improve our favorite software :slight_smile:

2 Likes
2

I can’t reproduce the described bug with the linked test build.
After moving the bitmap layer, color dialog still applies changes to the previously selected region layer unlike in 1.4.4.

I even tried to delete the region layer after color dialog was open and still no error messages, it just silently ignored the fact that layer was deleted. So I guess bug is resolved.

2 Likes
3

And if you edit color after layer deletion? Any error is raised?

4

Nope, nothing. It functions as if the layer was still there and when you click “Close”, the dialog window closes as normal without affecting anything.

3 Likes
5

Ugh.
I got an error.
If user deletes the layer, s/he can use the dialog without problems (pointless, but no problem) Except if s/he tries to undo. Then inocuous undo happens

6

You mean that undo history gets polluted with color choices and user can no longer undo layer delete operation?

Well, it’s what we get for letting user communicate with the main window while upper dialog window is still opened. I always wondered why Synfig doesn’t block interaction with the main window until the color (or any other important dialog window) is opened.

7

Well I suppose if there are no use-cases that require the color dialog not be “modal” (freezes the other parts of the program). The this should be quite easy to do.

8

There is at least a use case :stuck_out_tongue:
When selecting foreground/background color it doesn’t matter (and it is stopped).
But when you change the color from the properties, you can see in live preview the changes on the canvas :wink:

Peek 2024-06-14 17-48

1 Like
9

when you change the color from the properties

Oh yes I do that a lot. I don’t know how I missed that xD.

10

I wasn’t thinking about “completely freezing” the rest of the program, that would be of course bad. My idea was to disable the user input for the canvas window. It would still refresh and accept changes from dialog but won’t accept mouse clicks and key pressed until user closes the top dialog window.

11

I think that the idea was to be able to change the color of different layers at the same time, without to close and reopen selecting the color property:
Just change of layer and go to the color field of the dialog then press Enter, the 2 layers are the same color now.
You can of course change of color using a standard name like lavender, silver, pink …

It speeds the workflow, the only annoying part is the logging of action of change of color … which can be “muted” as when we simply assign a color as fore/background color in the Toolbox

Peek 2024-06-14 22-01

2 Likes
12

We can do it by selecting multiple layers
too =]

1 Like
13

So we no longer discussing the bug but rather if the old behavior was intentional? I never used it myself, was always changing color of multiple layers by selecting them first and then opening color dialog (like rodolforg mentioned).

I can see that if you want to set different colors on a lot of different layers, then this functionality would be useful but I can’t think of a practical example for that.

14

I can make it not react to pollute the undo action history if the layer is deleted.

But I think it would be better if it closes automatically if that happens to the layer. However, I’m struggling to do it in an ‘elegant’ way, and keep stuff independent.