leyoda/winit
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Winit Features and Scope (#695)

Browse source 
* Add initial draft of SCOPE document

* Rephrase/rename feature tiers

* Rename to FEATURES and add a few annotations

* Fix API Reworks table

* Add more annotations

* Some phrasing

* Split compat matrix into seperate section, to be moved into wiki

* Mention compatibility in CONTRIBUTING

* Remove some discuss annotations

* Apply review changes and rename child windows feature to popup windows

* Update based on discussion

* Add issue for Android HiDPI

* Update FEATURES.md

* Update FEATURES.md

* Update PULL_REQUEST_TEMPLATE.md

* Update PULL_REQUEST_TEMPLATE.md

* Reformat FEATURES.MD

* Remove comments

* Improve formatting and add guide for extending #Features
This commit is contained in:
Osspial 2019-04-13 18:57:08 -04:00 • committed by Victor Berger
parent 94f998af0a
commit e579a03035
3 changed files with 216 additions and 21 deletions
Download patch file Download diff file Expand all files Collapse all files

27
CONTRIBUTING.md
View file

@ -1,28 +1,10 @@
# Winit Contributing Guidelines
## Scope
[See `FEATURES.md`](./FEATURES.md). When requesting or implementing a new Winit feature, you should
consider whether or not it's directly related to window creation or input handling. If it isn't, it
may be worth creating a separate crate that extends Winit's API to add that functionality.
Winit aims to provide a generic platform abstracting the main graphic platforms (Windows, macOS, X11,
Wayland, Android, iOS and the web platform via Emscripten).
Most platforms expose capabilities that cannot be meaningfully transposed to the others. Winit does not
aim to support every single functionality of every platform, but rather to abstract the set of
capabilities that is common to all platforms. In this context, APIs exposed in winit can be split into
different "support levels":
- Tier 1: features which are in the main scope of winit. They are part of the common API of winit, and
are taken care of by the maintainers. Any part of these features that is not working correctly is
considered a bug in winit.
- Tier 2: some platform-specific features can be sufficiently fundamental to the platform that winit can
integrate support for them in the platform-specific part of the API. These features are not considered
directly handled by the maintainers of winit. If you have a strong incentive to have such a feature
integrated in winit, consider implementing it and proposing yourself to maintain it in the future.
- Tier 3: these features are not directly exposed by winit, but rather can be implemented using the
raw handles to the underlying platform that winit exposes. If your feature of interest is rather
niche, this is probably where it belongs.
The exact list of supported Tier 1 features is tracked in this issue:
[#252](https://github.com/tomaka/winit/issues/252).
## Reporting an issue
@ -44,6 +26,9 @@ When making a code contribution to winit, before opening your pull request, plea
- you left comments in your code explaining any part that is not straightforward, so that the
maintainers and future contributors don't have to try to guess what your code is supposed to do
- your PR adds an entry to the changelog file if the introduced change is relevant to winit users
- if your PR affects the platform compatibility of one or more features or adds another feature, the
relevant table in the wiki should be updated
***//TODO: LINKY***
Once your PR is open, you can ask for review by a maintainer of your platform. Winit's merging policy
is that a PR must be approved by at least two maintainers of winit before being merged, including