Basic organization of solution / folders

[Arlodotexe]

Cleanup and organization of the solution and folders to more closely match the existing toolkit. Quick PR to get everyone in sync with the changes.

Closes #7

[michael-hawker]

GitHub kind of mangles what these changes are, what's a quick overview of the old/new structure?

To clarify too, the existing setup is mean to be one 'experiment' which we'd have multiple copies of, not to be "a sample app" all-up for instance. i.e. the sample app project here is the sample app project specific to the CanvasLayout experiment.

So is the intent is that our root starts at src? Part of the reasoning I figured we'd start at the top-level per experiment was that it'd make it easier for folks to find each experiment in the repo. Maybe we just chop the redundant parts?

_build_
_common_
CanvasLayout
CanvasView
...
NodeGraph
...

(And everything would just be under the namespace/package name CommunityToolkit.Labs.Uwp.<ExperimentName> - It'd also make the url for these like https://github.com/CommunityToolkit/Labs.UWP/tree/main/ to match.)

And then each experiment folder would have:

src
samples
docs
unittests
uitests

Thoughts?

[Arlodotexe]

To clarify too, the existing setup is mean to be one 'experiment' which we'd have multiple copies of, not to be "a sample app" all-up for instance. i.e. the sample app project here is the sample app project specific to the CanvasLayout experiment.

I see, I had assumed this would be a single app that could "hoist" and display one (or more) experiments from separate projects, rather than having a separate app for every experiment. Esp. since you mentioned showing them in a list.

I'm on board with slimming folder names down from namespaces to experiment names.

[shweaver-MSFT]

Opinions incoming. Let me know what you think:

Here is what the folder structure looks like with your changes:

Here is the inside of the src foulder:

Comments:

• I think the src folder name is too simplistic. I find labels like Features or Labs or Projects more obvious.
• The solution file in the src folder should probably go away, and each Labs project should have its own folder and sample solution.
• The uber sample that shows all sample should be more top level, and not nested in the src folder. It is not a feature project set itself.
• Introduce a build or Common folder to store common configuration.
• Introduce a Template folder to hold the code for the labs project template. This is a project that can be copied, and perhaps a VSIX project can go here.
• Only files left in the root should be solution wide items, like the .gitignore and README, etc.

[XAML-Knight]

(And everything would just be under the namespace/package name CommunityToolkit.Labs.Uwp.< ExperimentName >

Assuming there would then also be the same distinction for Uno:

• CommunityToolkit.Labs.Uno.Exp1
• CommunityToolkit.Labs.Uno.Exp2
• etc

[michael-hawker]

Like that @shweaver-MSFT!

So at the root you'd see something like:

• _build_
• _common_
• _template_
• CanvasLayout
• CanvasView
• ...
• .gitignore
• Directory.build.Props
• Directory.build.Targets
• license
• readme
• ...
• AllExperimentsSamples.sln

Then the template and each experiment would be:

• Library
• Samples
• Documentation
• UnitTests
• UITests
• ExperimentName.sln

[shweaver-MSFT]

@michael-hawker, any concern with having all the labs in the root versus a Labs or Projects folder? I worry as we progress the root will fill up fast with any number of labs projects. Might look bloaty

[Arlodotexe]

@michael-hawker, any concern with having all the labs in the root versus a Labs or Projects folder? I worry as we progress the root will fill up fast with any number of labs projects. Might look bloaty

I second putting them under a "Labs" folder. Will be cleaner, and easier for any scripts to find all of them.

[Arlodotexe]

I've pushed changes based on the feedback, here's what the folder structure looks like now.

[michael-hawker]

Cool, so in the end our root will be:

• build
• common
• Labs
• template
• misc files...

Sounds good!

[shweaver-MSFT]

The casing is a bit mismatched. Does that matter?

[Arlodotexe]

The casing is a bit mismatched. Does that matter?

Do you mean in this folder or something else?

[shweaver-MSFT]

They're lower case in the labs project, and I guess I just expected to see pascal case.

[michael-hawker]

Assuming there would then also be the same distinction for Uno:

• CommunityToolkit.Labs.Uno.Exp1
• CommunityToolkit.Labs.Uno.Exp2
• etc

Hopefully in the future when we get to looking at how Uno fits in here, we just abstract as much as we can away, but otherwise it'd be contained within the 'samples' folder for each component. Though again, hopefully we have enough common infrastructure that propping this up isn't in the way of each experiment and just a way for us to consume it.

[michael-hawker]

Oh just noticed getting a build error:

Both in experiment solution and all-up when trying to run sample app

[Arlodotexe]

Oh just noticed getting a build error:

Both in experiment solution and all-up when trying to run sample app

Thanks, I've added Microsoft.UI.Xaml to the UWP props and made sure it all builds okay

[michael-hawker]

Yeah, I've confirmed if you re-add the project reference it should all work in both solutions again.

Though the deploy for the all-experiments was unchecked:

{4E3BF20D-27D9-49C7-8C60-0314A13A7885}.Debug|Any CPU.Deploy.0 = Debug|x64

[michael-hawker]

Looks like we're missing the Deploy for every other case but this one in the {4E3...885} guid Debug/Release. Man I wish solution files weren't such a pain...

[Arlodotexe]

Interesting. Is still lets the user select and deploy x86, x64 and ARM, is this a problem?