Skip to content

Commit

Permalink
Update roadmap.md
Browse files Browse the repository at this point in the history 
Updating Roadmap.md based on progress on open sourcing additional 9 binaries
  • Loading branch information
@grubioe
grubioe authored May 22, 2019
1 parent 15b0559 commit ba91ee7
Showing 1 changed file with 14 additions and 13 deletions.
27 changes: 14 additions & 13 deletions roadmap.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,8 +16,8 @@ As we complete those goals, we'll update our roadmap to include additional featu
| Milestone | Date |
|---|---|
|Initial launch of WPF for .NET Core repository (beginning with System.Xaml)|Dec 4, 2018|
|Add adequate tests that enable validating and merging community PRs|Early 2019|
|Roadmap update for feature focus areas|Early 2019|
|Add adequate tests that enable validating and merging community PRs|Continues thru 2019|
|Add remaining WPF for .NET Core components to repository|Continues thru 2019|

## Porting Status
Expand All @@ -27,16 +27,25 @@ The port from WPF for .NET Framework is still in progress. All components appli
### Currently Available
* Components:
* [System.Xaml](src/Microsoft.DotNet.Wpf/src/System.Xaml)
* [WindowsBase](src/Microsoft.DotNet.Wpf/src/WindowsBase)
* [PresentationCore](src/Microsoft.DotNet.Wpf/src/PresentationCore)
* [PresentationFramework](src/Microsoft.DotNet.Wpf/src/PresentationFramework)
* [PresentationBuildTasks](src/Microsoft.DotNet.Wpf/src/PresentationBuildTasks)
* [DirectWriteForwarder](src/Microsoft.DotNet.Wpf/src/DirectWriteForwarder)
* [ReachFramework](src/Microsoft.DotNet.Wpf/src/ReachFramework)
* [System.Windows.Input.Manipulations](src/Microsoft.DotNet.Wpf/src/System.Windows.Input.Manipulations)
* [UI Automation assemblies](src/Microsoft.DotNet.Wpf/src/UIAutomation)
* [UIsAutomationClient](src/Microsoft.DotNet.Wpf/src/UIAutomation/UIAutomationClient)
* [UIAutomationClientSideProviders](src/Microsoft.DotNet.Wpf/src/UIAutomation/UIAutomationClientSideProviders)
* [UIAutomationProvider](src/Microsoft.DotNet.Wpf/src/UIAutomation/UIAutomationProvider)
* [UIAutomationType](src/Microsoft.DotNet.Wpf/src/UIAutomation/UIAutomationTypes)

* Tests:
* [DrtXaml](src/Microsoft.DotNet.Wpf/test/DRT/DrtXaml)

### In Progress
Note: This list is in rough priority order and may change.
* Components:
* `WindowsBase`
* `PresentationFramework`
* `PresentationCore`
* `PresentationBuildTasks`
* `WindowsFormsIntegration`
* `System.Windows.Controls.Ribbon`
* `WPF Themes`
Expand All @@ -46,22 +55,14 @@ Note: This list is in rough priority order and may change.
* `PresentationFramework-Classic`
* `PresentationFramework-Luna`
* `PresentationFramework-Royale`
* `UIAutomation`
* `UIAutomationClient`
* `UIAutomationClientSideProviders`
* `UIAutomationProvider`
* `UIAutomationTypes`
* `WPF Extensions`
* `PresentationFramework-SystemCore`
* `PresentationFramework-SystemData`
* `PresentationFramework-SystemDrawing`
* `PresentationFramework-SystemXml`
* `PresentationFramework-SystemXmlLinq`
* `System.Windows.Input.Manipulations`
* `System.Windows.Presentation`
* `PresentationUI`
* `ReachFramework`
* `System.Printing`
* `PenIMC_cor3`
* `WpfGfx_cor3`
* `PresentationNative_cor3`

This comment has been minimized.

Sign in to view

Copy link
@weltkante

weltkante Sep 27, 2019

@grubioe it has been asked why PresentationNative_cor3 was removed from the roadmap. Might have been a mistake?

This comment has been minimized.

Sign in to view

Copy link
@grubioe

grubioe Sep 30, 2019

Author Contributor

@weltkante - PresentationNative_cor3.dll was initially added to the roadmap as part of the full list of DLLs. It was removed because it contains code that is a copy of a closed-source Windows component. It should never have been in the list in the first place.

This comment has been minimized.

Sign in to view

Copy link
@nsivov

nsivov Sep 30, 2019

@grubioe does that mean PresentationNative_cor3.dll will remain a part of Core/WPF distribution and will only be distributed as a binary, under what license/terms of use? How does that align with the license covering WPF source repo?

This comment has been minimized.

Sign in to view

Copy link
@weltkante

weltkante Sep 30, 2019 •
edited
Loading

Yes, the licensing question would be interesting. Could you deploy it with custom WPF builds or only with official WPF builds? I was looking forward to attempt modding WPF for usage in games. Having no standard UI framework available in game engines is a pet peeve of mine and when WPF was announced for open sourcing I had hopes to make it useable for this scenario. WPF without text processing would be pretty useless though.

This comment has been minimized.

Sign in to view

Copy link
@richlander

richlander Sep 30, 2019

Member

There is no licensing concern. I'll explain:

  • The WPF repo is not affected because the source in question isn't present. Open source can depend on closed source. That's always been the case and isn't an issue. It is the closed source terms that are important, and I'll touch on that next.
  • The .NET Core distributions for Windows use the .NET Library License. It enables you to do all the things I expect you want.
  • The .NET Core distributions for Windows already contain closed source -- I believe a single component that is used for Windows PDB reading/writing and that is owned by another team. So, there is a precedent for that, and this is the primary reason why the .NET Library License is used for Windows distributions. Linux and macOS binary distributions use MIT.

0 comments on commit ba91ee7

Please sign in to comment.