-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update swatches after Replace command #1265
Update swatches after Replace command #1265
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this one line should be added to updateItemColor
instead of here because you'll always want the object colors to match the palette colors. Unfortunately this is not sufficient to close #1055 as far as I can tell. @Jose-Moreno can probably weigh in on this more, but it seems that it does fix the replace command updating the color on both bitmap and vector layers, and it updates the other mode or other scaling. It does not update the name (and I don't think it should so that's fine).
However, in the last post in #1055 brings up an issue with the palette updating that has not been addressed here yet, and that is the real-time updating. When you have a vector layer active and you change the color in the color box, it will automatically update the active palette color. However, the color palette widget does not update to reflect this. Personally, I don't think changing the color should update the palette unless the replace command is used to prevent accidental changes, but I think this behavior is something we need to discuss.
I've moved the function so the palette and object are updated almost simultaneously. |
@scribblemaniac Hmm I think partly due to the discussions that took place in #732 and #755 the result was commit da990cc made by chchwy, but that behavior was not ideal, so later on @candyface implemented #961 which allowed for both bitmap and vector layers to alter colors in the palette separately. So after that the real time update of swatches for vector layers was removed because of that, but I agree that it wasn't 100% clear if it was a by-product or an intentional removal 🤔 I personally would like that updating the swatch updates it in real time for vector only, however I'm also thinking that considering the replace command was implemented to deal with the color swatch state update, it would not be coherent if we revert back to the real-time update despite being a more intuitive way of previewing the changes when using a vector workflow. If I were to be totally honest, for me the way it should work is where the Bitmap palette behavior is always static and vector is always dynamic, so there's contrast between the two workflow "modes" How swatches behave In relation to applied colors on canvas
How swatches behave In relation to the Color Inspector / wheel:
Proposal *: For vector swatches, they could change real-time through the color inspector but only when specifically modifying the selected active swatch through the select color dialog. While it would be similar to the previous behavior, in order to give coherence to the replace command and avoiding changing the swatch inadvertently, -which was the main problem for users before it was excised mainly because people are accustomed to select the color first and then change it but didn't pay attention to the layer they were on- we could make this real-time update to happen only in this sort of "edit mode" for swatches that is the Select Color dialog. In Harmony for example you can only change the color when you double click the swatch to "edit" and it will bring a panel similar to the color selector we already have in Pencil2D. So in Pencil2D If you select the color using the Inspector / Wheel first, you could right click, press replace swatch and all is good. But if you select the color swatch and then change the color in the inspector, then double click the swatch (or use a new command called Edit), the current color RGB values would be returned to the selector dialog to avoid retyping / re-selecting the color (this would also work when you select the swatch once, then double click so the starter color would be that of the swatch) Then using the Select Color dialog slider, the rgb input boxes or if you picked a pre-defined color this would update the color in real time on canvas. Lastly if you press cancel it would default back to the previous color the swatch had recorded (not the one on the inspector necessarily). |
I think I understand what you're writing @Jose-Moreno, but it's not easy for me. As said before, I've never worked with ToonBoom or other software, and I try to make sense in behaviour that I don't understand. |
So - what can we agree upon in this issue? How and when should vector swatches be updated? |
This has been sitting for too long, so I'll join in. I believe the functionality we want is:
Any thoughts? |
@pencil2d/developers My proposal: The swatch will not change unless you use the replace command, which will then affect vector strokes. With this change, you won't be able to see immediate color changes to a stroke on the vector layer anymore, you'd have to use the replace command specifically for that to happen. is that what we want? |
…vector strokes - Ensures that only by explicitly using the 'replace' command, attached vector strokes will change - Fixes a bug that would detach a vector stroke from the palette
@MrStevns Sorry!!! I honestly never saw this before until @J5lx pointed out today 🤦♂️ AFAIK part of this has already been implemented (the not updating the vector strokes) The behavior you presented is exactly what we ended up discussing after some time, so with the proper updating to the current master I think it can be merged in the way you explained. |
The proposed changes has been added to the PR, it's ready to be reviewed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please merge at your own discretion. Thank you for taking care of this!
I am a little confused over this PR.
it closes #1055 , but it only contains one new line of code. I feel I've overlooked something.
I've tested it several times though, and it seems to work.