Create an option to disable adaptive screen size triggers in the Navigation Pane Project Type

[qbss]

For new Features:

Other possible options would include creating a separate selection that doesn't have adaptive screen size triggers enabled for the hamburger meu or is commented out for ease of being customized.

[crutkas]

Hey @qbss can you fill out the bug in the body, the title should be short and understandable.

[mrlacey]

What's the goal behind this? Are there problems with the existing implementation or do you just want a different way of doing this? Is the aim to not have adaptation at all? Or is it just to make it customizable?
If it's to have customization, is not the existing implementation where you can just change the values as necessary not enough?

Other pages also include the adaptive size code. Should these be changed too?

notes Also: need to think about any necessary documentation additions or changes if doing this.

Could do this by making adaptive code a feature that gets added to all(?) pages if included. If just for this one page, could do it by adding an "extension" that is enabled by default. We've talked about having "extensions" on pages and features but this would be on the project type.

[qbss]

For more overall flexibility / simplicity in created projects, my idea was to have a separate hamburger menu project type template that doesn't include screen size adaptation and would default to using the following shellpage.xaml.cs settings:

(current narrow state page size settings) DisplayMode = SplitViewDisplayMode.Overlay; IsPaneOpen = false;

Projects such as simple full page webview apps don't really need any page size adapting since they already utilize the full page regardless of screen size or window size and using display modes such as the CompactInline Display mode reduces usable screen space in these cases.

Another option may be to use an (on by default) check box that would disable or comment out the current screen adaptation "SplitViewDisplayMode.CompactInline; & IsPaneOPen = False;" settings when unselected and use the (current narrow state page size settings) "DisplayMode = SplitViewDisplayMode.Overlay; & IsPaneOpen = false;" instead.

The current template is very limited / non flexible without commenting things out, removing unwanted things, and tweaking the display modes and such just to bring it back to a more simplified state. Too much of this type of thing and I tend to just start with a blank template / slate and add what I need instead.

Having a blank page project type that utilizes an app button bar with a settings page button and other selected page buttons could also be useful and bring more flexibility in creating projects. Of course all these things can be been done by just tweaking / changing the existing templates, but one of the main ideas with using a template based system is to help make the process easier, quicker, cleaner, etc..

[qbss]

Some tweaking / using some adaptation code may still be necessary to keep, such as on the settings page.

For example, when tweaking the a hamburger menu project type template to use the overlay display mode for all screen sizes, I then ended up with the "Settings" title text being on top of the hamburger button symbol. That is at least one project item that has potential alignment / overlapping placement conflicts.

[crutkas]

My gut here is this is documentation / up to developer.

We can only do so much before we get in the way. I feel this could get into the way for most. The resizes are pretty easy to remove for a developer but are extremely useful to include in the template.

[crutkas]

@qbss would you be interested in maybe helping out update the documentation for this?

[qbss]

OK, making a template w/o the adaptive screen size triggers included / active may have limited use and can be addressed by documentation / code comments instead. However and in my opinion, having multiple project style templates (more modular) would make creating various project types easier, faster, and provide more overall flexibility without having to spend much time researching things as needed and then removing / commenting out / modifying irrelevant template code that may not be wanted or needed.

Template 10 is an example of something I've never actually used in a production level project (other than viewing it as an example of how to do certain things) simply because it would have been too time consuming to tweak / modify vs just starting from scratch. This is not to say that I still couldn't find it useful for certain projects where a lot of boilerplate code (where it shines) is needed.

Although some more experienced level developers may not have an interest or find more templates useful to them, I think it would be very helpful to the newer entry level - junior level developers especially when initially getting started. The use of templates also helps encourage following best practices & frame works. The more experienced developers may view this as training wheels, but if they don't need it or find it useful, they don't have to use it either. Analytics and feedback would ultimately help determine what people would or wouldn't find useful overall.

Regardless of what is or isn't done, having good documentation and good comments in the code can certainly be very helpful. I think I will need to look at the existing documentation more in the first place :-), but I certainly don't mind helping where I can.

[mvegaca]

Navigation pane doc update on #2070 to include the section Remove adaptative behaviors from HamburgerMenu

[mrlacey]

Because it's not been stated above, switching the templates to use NavigationView rather than HamburgerMenu will also mean removing the adaptive triggers. Because of this it will remove the need to create any specific documentation on how to remove them manually.