You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Color Picker Should Default to the Current Code's Color Format #4978
The default colour picker next to Color classes will replace the current colour with Color.fromARGB regardless of whether the current colour format is Color(0xFFFFFFFF) or Color.fromRGBO.
changed the title [-]Colour Picker Does Not Account For Current Colour Format[/-][+]Color picker should default to the same color format as the current code[/+]on Feb 12, 2024
You can cycle through the different formats by clicking on the label - but I agree it would be nice if we ordered these so that the one using the same format was first in the set.
I have also previously encountered a bug in which the conversion may change the actual colour.
Specifically, converting rgba(r, g, b, 15) to rgbo format (which has 0-255, 0-255, 0-255, 0-1 range) ends up with rgba(r, g, b, 16) once you've cycled through all the colours.
changed the title [-]Color picker should default to the same color format as the current code[/-][+]Color Picker Should Default to the Current Code's Color Format[/+]on May 21, 2024
I tried implementing this, but unfortunately it doesn't work because of how VS Code uses the index of the current format when requesting new color presentations.
Eg. you have Color(0xff000000) and open the colour picker - we put that format first in the set. You drag around the colour picked and everything works fine.
Next, you click to change the format - which updates the document with the new format. Now, when VS Code asks us for presentations, we return them in a different order, because the document has a different format to originally. However, VS Code knows you are on "the second format" in the current open colour picker, so it shows the second result from the results (but we have put the current format first).
Since there is no state and we don't know the original format when you opened the colour picker, we can't make the order stable if we are adjusting it based on the current contents of the file.
I think the only way to allow this would be with some changes to VS Code to support us providing some description of the format (for example the constructor name without the args) so that it could match them up and keep the format consistent itself.
Activity
[-]Colour Picker Does Not Account For Current Colour Format[/-][+]Color picker should default to the same color format as the current code[/+]DanTup commentedon Feb 12, 2024
You can cycle through the different formats by clicking on the label - but I agree it would be nice if we ordered these so that the one using the same format was first in the set.
Number-3434 commentedon May 21, 2024
I have also previously encountered a bug in which the conversion may change the actual colour.
Specifically, converting
rgba(r, g, b, 15)torgboformat (which has0-255, 0-255, 0-255, 0-1range) ends up withrgba(r, g, b, 16)once you've cycled through all the colours.DanTup commentedon May 21, 2024
@Number-3434 can you reproduce this? Could you file a new issue about that specifically?
[-]Color picker should default to the same color format as the current code[/-][+]Color Picker Should Default to the Current Code's Color Format[/+]DanTup commentedon May 27, 2025
I tried implementing this, but unfortunately it doesn't work because of how VS Code uses the index of the current format when requesting new color presentations.
Eg. you have
Color(0xff000000)and open the colour picker - we put that format first in the set. You drag around the colour picked and everything works fine.Next, you click to change the format - which updates the document with the new format. Now, when VS Code asks us for presentations, we return them in a different order, because the document has a different format to originally. However, VS Code knows you are on "the second format" in the current open colour picker, so it shows the second result from the results (but we have put the current format first).
Since there is no state and we don't know the original format when you opened the colour picker, we can't make the order stable if we are adjusting it based on the current contents of the file.
I think the only way to allow this would be with some changes to VS Code to support us providing some description of the format (for example the constructor name without the args) so that it could match them up and keep the format consistent itself.
DanTup commentedon Jul 31, 2025
I'm cleaning up the issue tracker and closing some issues that are unlikely to be fixed/implemented in the foreseeable future.
Since we can't resolve this issue without changes to VS Code, I'm going to close it. If this changes, we can re-open it.