-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Add new ColorView & ColorPicker Controls #8215
Conversation
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
This was unused and is an unnecessary complexity
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
@maxkatz6 A full review was done of the bool properties. Since this is finalizing the API and different from WinUI a bit more time was spent on this. Please let me know if you (or anyone else reading this) agree or have questions/concerns. The main column to look at is the "New" one on the right. Some alternative ideas are listed to the immediate right of the "New" column but were decided against.
Edit: The name of the primitive is ColorSpectrum and the interface IColorPalette. So it makes sense to keep the existing color term in the name for those two (IsColorSpectrumVisible and IsColorPaletteVisible). IsColorSpectrumVisible also now matches WinUI again. Then to be consistent, IsColorComponentsVisible should be used for the third tab. So I ended up only changing ShowAccentColors to IsAccentColorsVisible (all others use "visible" and "is" terminology). |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
Personally, I don't have anything against of current naming in this PR, seems reasonable. |
Well, I thought about the property naming some more. The name of the primitive is ColorSpectrum and the interface IColorPalette. So yes, it makes sense to keep the existing color term in the name for those two. Then to be consistent, ColorComponents should be used for the third tab. So I might end up only changing ShowAccentColors to IsAccentColorsVisible (all others use "visible" and "is" terminology). I found another thing where the color previewed drop shadow should really be removed when accent colors are not shown. If you could pause auto-merge I'll try to make the changes within the next few days. |
@robloo paused |
@maxkatz6 Thanks, updates are made and this should be all set for now. I will make the next round of updates converting to |
You can test this PR using the following package version. |
Not sure what conflicts it is talking about unless it means the IntegrationTests failures. I merged in master branch with no issue. I'm assuming the IntegrationTests are still a WIP? Let me know how to proceed here. |
@robloo framework used for integration tests is very unstable, and it fails quite frequently. It's not yet solved, but PRs can be merged anyway, as it doesn't block merging. I can do it now, if you want to continue with control themes in another PR. |
Yes, that was my plan and I'm not sure when the other PRs will be completed. If you could merge this soon that would be great. Sorry for not being more clear about it. |
@robloo very beautiful and powerful color picker 👍 Can't wait to use it in v11.0 (I know I can use nightly builds, but they are breaking other things for me atm) I think we now should create the needed docs for it. I can support you here if you want me to. |
@timunie Thanks! Hope you find it useful.
I haven't forgotten about this and already started a draft of some ideas some time ago. However, there is no rush to complete it. As you know new docs are getting merged in right now. I will plan on finishing this up myself due to the nature of this control. Your review after the initial draft will be very useful though. |
What does the pull request do?
Adds the last two
ColorView
andColorPicker
controls (in the Avalonia.Controls namespace). These are stand-alone controls not based on WinUI code. This closes #4179.These are the final fourth and fifth major controls towards implementing the ColorPicker.
What is the current behavior?
Only the following primitives are implemented for color-related controls:
ColorSpectrum
spectrum #5743ColorSlider
ColorPresenter
What is the updated/expected behavior with this PR?
Adds the two remaining color-related controls completing the
ColorPicker
functionality.ColorView
This is the 'canvas' version of the control that does not have a drop down button. ColorPicker hosts this in a drop down button flyout.
ColorPicker
This is the main control to use for color selection and editing and appears as a drop down button.
Video.mp4
How was the solution implemented (if it's not obvious)?
This is a brand-new implementation and attempts to fix past wrongs with all past color pickers starting with the name.
ColorView
from the actualColorPicker
implemented in a drop-down.HsvColor
is heavily used in all controls and was also implemented into base Avalonia alongsideColor
andHslColor
. This simplified code-behind and also made binding of color between primitives and controls a lot more straightforward.HsvColor
along withColorSlider
together unlock a lot of power with this control compared to the one in WinUI (and enable it to be easily re-templated).SelectedIndex
andColorModel
allow customizing the control putting it in a pre-defined state. For example: the WinUI ColorPicker always defaults to RGB and this cannot be changed in code or XAML. This implementation does not have such limitations.Checklist
Added unit tests (if possible)?- Will be done later
Breaking changes
None
Obsoletions / Deprecations
None
Fixed issues
Closes #4179