Skip to content

Commit

Permalink
Syncing content from committish release/1.4.1
Browse files Browse the repository at this point in the history
  • Loading branch information
reunion-maestro-bot committed Oct 24, 2023
0 parents commit 702b954
Show file tree
Hide file tree
Showing 11,755 changed files with 2,534,632 additions and 0 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
46 changes: 46 additions & 0 deletions .vsconfig
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
{
"version": "1.0",
"components": [
"Microsoft.VisualStudio.Component.NuGet",
"Microsoft.VisualStudio.Component.Roslyn.Compiler",
"Microsoft.Component.MSBuild",
"Microsoft.NetCore.Component.SDK",
"Microsoft.Net.Component.4.7.SDK",
"Microsoft.Net.Component.4.7.TargetingPack",
"Microsoft.Net.Component.4.7.2.SDK",
"Microsoft.Net.Component.4.7.2.TargetingPack",
"Microsoft.Net.Component.4.8.SDK",
"Microsoft.Net.Component.4.8.TargetingPack",
"Microsoft.VisualStudio.Component.Roslyn.LanguageServices",
"Microsoft.VisualStudio.Component.SQL.CLR",
"Microsoft.VisualStudio.Component.CoreEditor",
"Microsoft.VisualStudio.Workload.CoreEditor",
"Microsoft.VisualStudio.Component.VC.CoreIde",
"Microsoft.VisualStudio.Component.Windows10SDK",
"Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
"Microsoft.VisualStudio.Component.Windows10SDK.19041",
"Microsoft.VisualStudio.ComponentGroup.MSIX.Packaging",
"Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
"Microsoft.VisualStudio.Component.VC.Tools.ARM64",
"Microsoft.VisualStudio.Component.VC.ATL",
"Microsoft.VisualStudio.Component.Windows10SDK.18362",
"Microsoft.Component.NetFX.Native",
"Microsoft.VisualStudio.Component.TextTemplating",
"Microsoft.VisualStudio.ComponentGroup.UWP.NetCoreAndStandard",
"Microsoft.VisualStudio.Component.Graphics",
"Microsoft.VisualStudio.ComponentGroup.UWP.Xamarin",
"Microsoft.VisualStudio.ComponentGroup.UWP.Support",
"Microsoft.VisualStudio.Component.UWP.VC.ARM64",
"Microsoft.VisualStudio.Component.VC.Tools.ARM",
"Microsoft.VisualStudio.ComponentGroup.UWP.VC",
"Microsoft.VisualStudio.Workload.Universal",
"Microsoft.VisualStudio.Component.NuGet.BuildTools",
"Microsoft.VisualStudio.Component.VC.ATL.ARM64",
"Microsoft.VisualStudio.Workload.VCTools",
"Microsoft.VisualStudio.Component.VC.Runtimes.ARM64EC.Spectre",
"Microsoft.VisualStudio.Component.VC.Runtimes.ARM64.Spectre",
"Microsoft.VisualStudio.Component.VC.Runtimes.x86.x64.Spectre",
"Microsoft.VisualStudio.Component.VC.ATL.Spectre",
"Microsoft.VisualStudio.Component.VC.ATL.ARM64.Spectre"
]
}
40 changes: 40 additions & 0 deletions .vsconfig_buildtools
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
{
"version": "1.0",
"components": [
"Microsoft.Component.MSBuild",
"Microsoft.Component.NetFX.Native",
"Microsoft.Net.Component.4.6.1.TargetingPack",
"Microsoft.Net.Component.4.7.2.SDK",
"Microsoft.Net.Component.4.8.SDK",
"Microsoft.NetCore.Component.Runtime.3.1",
"Microsoft.NetCore.Component.Runtime.5.0",
"Microsoft.NetCore.Component.SDK",
"Microsoft.VisualStudio.Component.CoreBuildTools",
"Microsoft.VisualStudio.Component.NuGet.BuildTools",
"Microsoft.VisualStudio.Component.Roslyn.Compiler",
"Microsoft.VisualStudio.Component.TextTemplating",
"Microsoft.VisualStudio.Component.UWP.VC.ARM64",
"Microsoft.VisualStudio.Component.VC.ATL",
"Microsoft.VisualStudio.Component.VC.ATL.ARM64",
"Microsoft.VisualStudio.Component.VC.CoreIde",
"Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
"Microsoft.VisualStudio.Component.VC.Tools.ARM64",
"Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
"Microsoft.VisualStudio.Component.Windows10SDK",
"Microsoft.VisualStudio.Component.Windows10SDK.19041",
"Microsoft.VisualStudio.Component.Windows10SDK.18362",
"Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
"Microsoft.VisualStudio.ComponentGroup.UWP.BuildTools",
"Microsoft.VisualStudio.ComponentGroup.UWP.VC.BuildTools",
"Microsoft.VisualStudio.Workload.MSBuildTools",
"Microsoft.VisualStudio.Workload.ManagedDesktopBuildTools",
"Microsoft.VisualStudio.Workload.UniversalBuildTools",
"Microsoft.VisualStudio.Workload.VCTools",
"Microsoft.VisualStudio.Component.VC.Runtimes.ARM64EC.Spectre",
"Microsoft.VisualStudio.Component.VC.Runtimes.ARM64.Spectre",
"Microsoft.VisualStudio.Component.VC.Runtimes.x86.x64.Spectre",
"Microsoft.VisualStudio.Component.VC.ATL.ARM64",
"Microsoft.VisualStudio.Component.VC.ATL.Spectre",
"Microsoft.VisualStudio.Component.VC.ATL.ARM64.Spectre"
]
}
9 changes: 9 additions & 0 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Microsoft Open Source Code of Conduct

This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).

Resources:

- [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/)
- [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
- Contact [[email protected]](mailto:[email protected]) with questions or concerns
65 changes: 65 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Contributing to the Windows UI Library

We welcome your input and contributions to all aspects of WinUI, including bug reports, doc updates, feature proposals, and API spec discussions.

This document contains general guidance. More specific guidance is included in the documents linked below.

Note that all community interactions must abide by the [Code of Conduct](CODE_OF_CONDUCT.md).

## How we work with contributions

Contributions from the community in the form of feature requests and bugs are handled according to our [contribution handling](CONTRIBUTION_HANDLING.md) guidelines.

## New contributors

We mark the most straightforward issues with labels. These issues are the place to start if you are interested in contributing but new to the codebase.

* [good first issues](https://github.com/Microsoft/microsoft-ui-xaml/labels/good%20first%20issue)
* [help wanted](https://github.com/Microsoft/microsoft-ui-xaml/labels/help%20wanted)

Another great way to help is by voting and commenting on feature proposals:

* [feature request](https://github.com/Microsoft/microsoft-ui-xaml/labels/feature%20request)

## Code contribution guidelines

### Proposing new public APIs or UI

Please follow the [New Feature or API Process](https://github.com/microsoft/microsoft-ui-xaml/blob/main/docs/feature_proposal_process.md) before adding, removing, or changing public APIs or UI.
All new public APIs, new UI, or breaking changes to existing features **must** go through that process before submitting code changes.
You don't need to follow that process for bug fixes or other small changes.

### Contribution bar

The WinUI team accepts code changes that improve WinUI or fix bugs, as long as they follow the processes outlined below and broadly align with the [Windows App SDK feature roadmap](https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md).

While we strive to accept all community contributions that meet the guidelines outlined here, please note that we may not merge changes that have narrowly-defined benefits due to compatibility risks and maintenance costs. We may also revert changes if they are found to be breaking.

### Contributor License Agreement

Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

### Copying files from other projects

The following rules must be followed for PRs that include files from another project:

* The license of the file is [permissive](https://en.wikipedia.org/wiki/Permissive_free_software_licence).
* The license of the file is left intact.
* The contribution is correctly attributed in the [3rd party notices](NOTICE.md) file in the repository, as needed.

## Documentation and usage samples

You can also read and contribute to the WinUI documentation here:
https://learn.microsoft.com/en-us/windows/apps/winui/winui3/

You can find usage examples of the controls available in WinUI in the WinUI 3 Gallery app:
https://github.com/microsoft/WinUI-Gallery/

which can also be installed from the Windows Store:
https://www.microsoft.com/p/winui-3-controls-gallery/9p3jfpwwdzrc

## API spec discussions

Before new features are added to WinUI, we always perform a thorough API review and spec discussion. This can range from a single new API to an entire new control featuring dozens of new APIs. Joining such a spec discussion is a great opportunity for developers to help ensuring that new WinUI APIs will look and feel natural. In addition, spec discussions are the follow-up to feature proposals and will go into much finer details than the initial proposal. As such, taking part in these discussions gives developers the chance to be involved in the complete development process of new WinUI features - from their initial high-level inception right down to specific implementation/behavior details. These discussions take place in the WInUI repository, i.e. this repository.
72 changes: 72 additions & 0 deletions CONTRIBUTING_feedback_and_requests.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# Contributing ideas, feedback, and requests

The WinUI team greatly values public feedback. We combine this feedback with our own internal strategy goals, weighing it alongside our existing commitments, resources, and private partnerships, to deliver maximum value for you.

The guide below outlines how you can formulate this feedback for maximum effect and influence on WinUI's direction.

## Phrasing constructively

When experiencing a pain-point, it can be natural to focus on the negatives and resolving things from the perspective of the negative. However, telling the team what you'd like to *prevent* is less helpful and actionable than telling the team what you'd like to *achieve*.

Your feedback is most effective when it is a constructive call to action on the team, and is clear and detailed – especially on the "why" so that we can make sure whatever it is that we arrive at together appropriately focuses on your goal and your intended outcome from start to finish.


**Examples of constructively phrased feedback:**

Instead of:

- The state of the platform is disappointing. I am not going to consider WinUI until my trust has been earned.

Try this:
- Deprecation of past frameworks has left me burned. The following would go a long way in earning my trust because my company is trying to launch an app next year and will need it supported for at least 5 more:
- OSS
- High-confidence 5-year roadmap
- Guaranteed support timeline

This feedback provides clear actionable items that the WinUI team can take into consideration and address.


## Sample areas where your feedback can have large impact

- ### Features
- It's very helpful to specify the "why" behind your request, even if it seems obvious. Comparisons can help, but shouldn't replace explanation.
- Ex: "I need `<`feature`>` so that I can achieve `<`goal`>`. Otherwise, I have to `<`alternative`>`."

There are also usually great opportunities to have feature-related impact in our [spec repo](https://github.com/microsoft/microsoft-ui-xaml-specs/tree/main). Here, you can give direct feedback and help shape the new features and APIs that we're currently building.

- ### Future/Roadmap
- We strive to be transparent about our [product roadmap](https://aka.ms/winui3/feature-roadmap). Great examples of feedback to help us achieve this are:
- "I'd like to know the roadmap through `<`timeframe`>`. Otherwise, I can't do `<`goal`>`. "
- "The roadmap `<`certain aspect - e.g., changes too much, not detailed enough, etc.`>`prevents me from being able to do `<`goal`>`. If you would instead `<`proposed alternative`>`, that would result in `<`clear benefit`>`."

- ### Ecosystem
- It's helpful to be complete in explaining what another solution achieves for you and why it is important to you.
- Ex:"I'd like WinUI 3 to work with `<`framework, language, library, technology, etc.`>`. Without this, I can't do `<`goal`>`."

- ### Prioritization within WinUI
- There is often trade-off required when adjusting priorities - please be clear in comparing what is more important vs. less important to you, and the reason why.
- Ex: "I think `<`specific area or feature set`>` should be prioritized before `<`other specific area or feature set`>` so that I can achieve `<`goal`>`. Without this, I have to `<`alternative`>`. "

- ### Engagement
- Engagement includes feedback about learning materials and resources. It is always helpful to know where you prefer to be engaged and how you prefer to learn.
- "I would like to hear more about `<`specific topic`>` in `<`resource`>` so that I can achieve `<`goal`>`."
- "`<`Resource`>` could be more inclusive and accessible if you considered `<`alternative`>` because `<`benefit`>`. Have you considered making these changes?"

Many of the resources we provide are also open source themselves! It can sometimes be more effective to leave feedback on the more specific repo. This includes:
- [documentation](https://github.com/MicrosoftDocs/windows-dev-docs)
- [website (`gh-pages` branch of this repo)](https://github.com/microsoft/microsoft-ui-xaml/tree/gh-pages)
- [WinUI 3 Gallery (sample app)](https://github.com/microsoft/WinUI-Gallery/tree/main)


- ### Team Process
- Team process includes feedback about our repo and overall communication. Suggestions for improvement and proposed alternatives are very helpful here.
- Ex: "`<`specific aspect of team process - e.g., response frequency, format`>` of the repo is making it hard for me to achieve `<`goal`>`. Please consider doing `<`alternative`>` instead because that would help `<`action`>`"


## Mutual respect

We strive to be respectful & empathetic toward each other, and we extend this to our fantastic community as well.

Our conduct guidelines help to ensure that discourse and feedback follows this same pattern of respect & empathy, and they also make it clear that non-constructive or hostile feedback is unacceptable. By following these guidelines, we can all enjoy the mutual respect that each WinUI team member, and each community member, deserve.

Refer to our [conduct guidelines](CODE_OF_CONDUCT.md) for more guidance here.
55 changes: 55 additions & 0 deletions CONTRIBUTION_HANDLING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# WinUI Repo Contribution Handling

The WinUI repo is intended as a place for the WinUI team to gather community feedback, discuss issues with the community, and provide insight into bug fixes that the team is working on before updates are released. Here, we'll outline how we handle feature requests and bugs that the community opens.

## Issues

Feature requests and bugs are tracked as GitHub issues.

For reporting security issues please see the [Security Policy](SECURITY.md).

For all other bugs and general issues please [file a new issue](https://github.com/Microsoft/microsoft-ui-xaml/issues/new/choose) using the Bug Report template.

Please file questions and discussions as discussions, not issues.

## Feature Proposals

Feature proposals for WinUI 3 are categorized based on the likely timeframe in which the feature team can consider them.

1. Short-term, less than a year
2. Long-term, not likely in the next year

All feature proposals are automatically categorized as long-term and unlikely to be considered, although the WinUI team might change the priority based on customer and business needs. If the WinUI team does close a feature proposal, we will indicate the reason why and how it fits into our plans. Closing a proposal does not mean that the team will never consider it. We encourage the community to add comments or interact with a proposal at any time, even a closed one, to signal its importance to the team.

### Feature Planning

Our long term vision for WinUI is to be the best UX/UI native framework for Windows PCs that provides premium visuals, motion, accessibility, usability, and support for all input modalities.

The current details of what we plan long-term are shaped by evolving priorities that are subject to frequent change and are often confidential based on business and customer needs. However, we are happy to share our immediate plans for what's coming next in the next major release once the feature list is ready. Additionally, preview and experimental releases provide opportunities for the community to see what's new and what's changing on a more frequent basis.

For more info about our longer-term planning, see the [Windows App SDK feature roadmap](https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md). This page will be updated generally right after a major release, when the features for the next release are solidified enough to share.

## Bugs

### WinUI 2

The WinUI team is currently spending its time on WinUI 3. To help with this focus, new bugs filed against WinUI 2 are closed in this repo unless they're a security issue or are business critical.

### WinUI 3

WinUI 3 bugs are triaged and prioritized based on how much the bug impacts one or more of the following criteria. If a bug has lower impact, it is less likely to be considered for fixing.

- Reliability
- Data corruption or loss
- Functionality (such as a major regression)
- Security
- Compatibility with applications
- User experience/usability
- Performance
- Compliance (such as legal compliance)
- Accessibility
- Build and deployment

Bugs filed in relation to preview and experimental releases are triaged with the same criteria as stable releases and are intended to assist in identifying and fixing those bugs before they make their way to a stable release.

Bugs filed on GitHub will be automatically mirrored to our internal bug tracking system and updates to them are automatically mirrored back to GitHub with appropriate tags. This way, the bugs we're working on and their progress are transparent. The only information we will reflect from our system externally is the state and release of the bug, not all the fine details; if a bug is resolved or closed, that's reflected on GitHub, and as bugs are worked on, the release for that fix will be reflected with a milestone on GitHub.
Loading

0 comments on commit 702b954

Please sign in to comment.