juv-studios / one Goto Github PK

Related to #2.

Initially, I wanted to use modules due to the benefits it provides - fast compilation, internal implementation details can be hidden from the outside etc... However C++/WinRT and the Windows SDK still don't support consuming APIs in the form of modules. While you can definitely import our modules in your project and still consume Windows APIs by including the appropriate header,
you can't use a precompiled header anymore. This means if you've lots of source files including the same header, you'll experience slow compilation, defeating the reason why I adopted modules in the first place. Our main target is C++ XAML apps and disabling precompiled headers isn't feasible.

I personally have two projects in such app projects - a core project with modules enabled, and a UI project with a precompiled header. However, splitting it into parts isn't really convenient. We can't really wait for modules to be adopted by Windows/WinRT (when?), so should I provide both a module and header for everything?

Summary

The NavigationView control isn't as easy to use as the Pivot control, but the Pivot control has outdated styles and limited functionality.

Provide a new control called PivotView that has a similar API to that of Pivot but provides most of the same functionality that NavigationView.

Features needed

• Automatic navigation on item click. Should it be based on page type and frame navigation like in this example or be like Pivot where the content is set on an item instead?
• Swipe with touch to flip between items.
• Built-in back/forward navigation stack.

Moved from Azure Boards. Original creation timestamp: 2022-07-10 21:38 +05:30.

Today one has to use the underlying APIs to switch view models (Full screen/compact overlay), but those aren't particularly convenient, so provide a way to easily switch or toggle between them through the ViewReference class.

Moved from Azure Boards. Original creation timestamp: 2022-01-02 21:00 +05:30.

Today, to consume OneToolkit WinRT APIs from C++/WinRT, you've to manually include the generated projection headers. Previously the OneToolkit.h header file included all of them, however, now I'm considering moving away from headers and using modules instead. The problem is that C++/WinRT doesn't yet support consuming projection headers as a module, and since it defines macros, causes too many warnings when you try to export them from a module. Find a way to consume those APIs defined in projection headers directly by importing the module.

Moved from Azure Boards. Original creation timestamp: 2022-01-12 18:34 +05:30.

Today OneToolkit uses XML comments for C++ APIs. Switch to Doxygen style comments since it's supported in more IDEs compared to XML comments, which is only supported by Visual Studio I believe.