-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Split out input controls from core #3727
Split out input controls from core #3727
Conversation
Thanks RosarioPulella for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
@RosarioPulella is that not built on top of the Layout changes? #3714 |
@michael-hawker nows its based off #3714 |
Yup, we'll see if that fixes it... 🤞 |
Almost there, forgot to add a Smoke Test project, so we got no updates in the baseline for the new package... |
@RosarioPulella think my last commit should fix the smoke test build? To reference another XAML based control package in another, there's the hack that we needed to apply like we did in the Markdown package. Since that wasn't there it couldn't be loaded properly in the Smoke Test (it's why we added them). Anyway, I rejigged the Input package to only rely on the Primitives package, so that also solves it as they don't have XAML. Only thing missing was the As I was checking the style though I noticed the ColorSliders within the ColorPicker weren't working though. Not sure if that happened in the move or somewhere since their PR (the code hasn't changed itself). Basically when you click on the slider the little round selector doesn't follow like it should... Something we should look into, but at least we should be able to get numbers in the morning first... 🤞 |
(Otherwise we need to apply Markdown package csproj patch to be able to reference Core.) TODO: Only thing that this leaves us though is a missing DropShadowPanel for the ColorPicker... But I think it might be ok?
Can you further describe the behavior you saw. For me the circles seem to be tracking just fine, at most I can say that they seem to jump around a bit if I move very fast on the picker, but on the slider it seems to be tracking well. |
Merging this as we've been poking at it a bit and will continue fixing thing forward in the dev branch. |
Quick test to evaluate the footprint of this individual control on the package. Based off PR #3727 Comparing against #3733, wondering if it's this single API or not that has an effect, as everything else seems rather common or using other things already being used in other APIs in the Toolkit... Updated as we identified the custom caching in #2486 is the culprit to the application footprint. Reverting to just use System Cache with the applied fix still to evaluate final impact again with compiled dlls. This should save around **675kb** to optimized app footprint. Also Fixes #3741 removing unused element.
Step towards #3594
Split out Input controls (
ColorPicker
,RadialGauge
,RangeSelector
,RemoteDevicePicker
,TokenizingTextBox
) fromCore
PR Type
What kind of change does this PR introduce?
What is the current behavior?
What is the new behavior?
PR Checklist
Please check if your PR fulfills the following requirements:
Other information