Adding initial spec for Reunion Picker API. #99

ZenBird-zz · 2020-06-30T19:10:57Z

This is the high level specification for the File/Folder picker in Reunion. This initial draft includes the API of the proposed File/Folder picker.

mdtauk · 2020-06-30T19:26:45Z

Is this intending to be a wrap for the existing picker experiences, or will this be a new File/Folder Picking UI and UX which could be built in Xaml, and used by all lifecycles of WinUI and Reunion apps? #Resolved

ZenBird-zz · 2020-06-30T19:34:04Z

Is this intending to be a wrap for the existing picker experiences, or will this be a new File/Folder Picking UI and UX which could be built in Xaml, and used by all lifecycles of WinUI and Reunion apps?

This API will reuse some code from the existing experience. This will for the most part be a rewrite and hence will benefit from being built in Xaml. #Resolved

mdtauk · 2020-06-30T19:51:34Z

Is this intending to be a wrap for the existing picker experiences, or will this be a new File/Folder Picking UI and UX which could be built in Xaml, and used by all lifecycles of WinUI and Reunion apps?

This API will reuse some code from the existing experience. This will for the most part be a rewrite and hence will benefit from being build in Xaml.

Great to hear! File Picking dialogs are some of the most commonly seen UI (like the UAC prompt), and having them be modern and reflect the modern Shell and Fluent design will go a long way to making the whole OS feel more consistent.

I would like to see most things that are currently possible with the Win32 dialogs carried over, (with the relevant permissions dialogs).

The removal of outdated or undesirable extensibility and features should be considered, as Reunion and WinUI 3 are both opt ins, and so there is an expectation of code changes for the most part - but keeping existing code working should be a goal as much as possible. #Resolved

specs/Picker-API_spec.md

wjk

Some preliminary feedback.

Also, I just wanted to make sure that I can get a filesystem path out of the StorageItem (at least in a full-trust process) so I can use it with whatever API I need. The UWP storage subsystem is infamously slow and difficult to use (cf. #8). Thanks!

specs/Picker-API_spec.md

wjk · 2020-06-30T20:35:34Z

One other thought: I’m torn about the namespace Microsoft.Reunion.Storage.Pickers. I can think of three different responses to this:

Keep the Microsoft.Reunion part and have all other namespaces in this repo start with that string. Clunky, but much more consistent.
Change the namespace to Microsoft.Storage.Pickers, by analogy to Windows.Storage.Pickers.
Change the namespace to Microsoft.FilePickers or Microsoft.StoragePickers.

My personal namespace design principles lean heavily towards option 3. If it was my decision, every Reunion API would have a root namespace something like Microsoft.MultiWordDescriptionWithoutDots, with sub-namespaces under that namespace if required. While I understand the reasoning behind the choice of Windows.Storage.Pickers for the original API, parroting that design exactly (while removing the use of the reserved Windows namespace) I feel does a disservice towards reorganizing these APIs. WinUI 3, with its Microsoft.UI.Xaml namespace, is IMO a very bad choice of namespace, but it is of course too late to change that project. I am raising this early so we don’t make the same mistake. Thanks! #Resolved

specs/Picker-API_spec.md

jonwis

A great start! @ShawnSteele - can you help guide updates?

specs/Picker-API_spec.md

jonwis · 2020-07-16T20:17:18Z

specs/Picker-API_spec.md

@@ -0,0 +1,115 @@
+# Background
+
+The current FilePicker API for UWP has several limitations. Some of the top limitations 


How closely should we be following the .NET file open dialog?

Should we encapsulate the core "picking" experience (the list of folders / files) into a stand-alone control so that developers can build their own picker UI for when they need additional features? For example, Notepad customizes the standard Win32 dialog to add an "Encoding" drop-down; Photoshop adds a bunch of advanced options; etc. The control would of course only work within the constraints of whatever permissions the app had (eg, just Pictures library) but relieves the developer of having to do all the messy filesystem work and trying to copy the look and feel of the "real" dialog.

For example, Win32 apps can embed an Explorer control or use the ancient DlgDirListComboBox function.

Could we start off with enabling the Win32 file/folder picker dialog from UWP and then make improvements to provide a modern UI.

@zenbird the dialog needs to run out-of-proc in the broker in order to access the files and then grant them to the UWP process. So the existing dialogs can be used, but there still needs to be some code in the middle to jump over to the broker and back again. #Resolved

Should we encapsulate the core "picking" experience (the list of folders / files) into a stand-alone control so that developers can build their own picker UI for when they need additional features? For example, Notepad customizes the standard Win32 dialog to add an "Encoding" drop-down; Photoshop adds a bunch of advanced options; etc. The control would of course only work within the constraints of whatever permissions the app had (eg, just Pictures library) but relieves the developer of having to do all the messy filesystem work and trying to copy the look and feel of the "real" dialog.

The existing File Picker UIs will co-exist with the Reunion ones - so I don't think there is a huge need to support rendering of GDI elements.

Any new WinUI XAML based dialog, could support custom content, and the UIs get built with WinUI.
In fact I proposed that the main content region could display XAML content, as well as HTML, with OneDrive, Google Drive and Photos as examples.

The Photos example, being a WinUI app, could provide a picker UI that renders in the dialog.

As for the customisations made by Notepad and Adobe - I believe these use existing Win32 APIs for adding controls. So at least in the mockup designs I have worked on, I visualised these as a collapsible panel containing WinUI controls.

microsoft/microsoft-ui-xaml#2854

Then there is the question of whether this API makes its way to Xbox, Surface Hub and Hololens. I would initially suggest that the APIs should match all platforms, but with a different UI/UX to suit the platform - and any overrides such as file system restrictions

Correct. V0.5 of the picker will use the existing win32 dialogs until we figure out the details of the intermediate process that will "broker" the permissions.

In reply to: 488307896 [](ancestors = 488307896)

specs/Picker-API_spec.md

jonwis · 2020-07-16T20:28:26Z

specs/Picker-API_spec.md

+
+The goal of this API is to address the gaps in the existing File/Folder picker APIs. The API surface is similar to the existing
+Picker APIs in Windows SDK with additional methods to support File + Folder picker and multiple folder picker. The API removes the
+deprecated methods from Windows SDK.


When returned to an app, I assume the app has all the same access to these objects as if they'd been picked by the platform API instead? Future access, available through CreateFileFromApp/FindFirstFileExFromApp, etc. #Resolved

That's not the case now for the pickers and the behavior should remain the same. E.g. The items returned from the picker are available temporarily and are not available by PATH or any other means unless added to the MRU or FutureAccessList. In particular the implementation must NOT internally add items to either list as the contents of those lists are owned by the application - not the system. Though we may want to take the opportunity here to include the user intent that access is supposed to only be one time to and block adding the item to the MRU/FAL @ptorr-msft may have some thoughts on that as he's talked about that before. #Resolved

Though we may want to take the opportunity here to include the user intent that access is supposed to only be one time to and block adding the item to the MRU/FAL

This in turn begs the question: If you are blocked from adding a path selected via the picker to the MRU/FAL, then how are you supposed to populate those lists in the first place? (Especially in an AppContainer app, where the only way to get access to arbitrary paths is to use the picker.) This is a bizarre limitation, especially since the platform pickers don’t do this. If we go through with this idea, then apps will lose functionality by moving to Reunion. This does not sound like a good idea to me.

Since we're blue-skying here... the ultimate goal is for the duration of the consent to be specified by the user -- "Until I close the app" or "Always" or "Only when the app is in the foreground" etc. -- and also the scope of the grant (read-only vs. read/write) to be under their control. The apps should not be required to use FAL in order to maintain access once we do this; it should "just work."

I agree. The picker should return a vector if IStorageItem with no guarantees on the underlying object.

In reply to: 458438812 [](ancestors = 458438812)

mdtauk · 2020-07-17T01:19:13Z

Will this specification include the notion of WinUI/UWP apps acting as file providers, rendering UI within this new File Dialog?

The conversation here microsoft/microsoft-ui-xaml#2854 brought up apps like Camera which can appear within the Win32 file dialog, but which do not work very well today. #Resolved

specs/Picker-API_spec.md

smaillet-ms · 2020-07-21T23:05:00Z

specs/Picker-API_spec.md

+
+The goal of this API is to address the gaps in the existing File/Folder picker APIs. The API surface is similar to the existing
+Picker APIs in Windows SDK with additional methods to support File + Folder picker and multiple folder picker. The API removes the
+deprecated methods from Windows SDK.


That's not the case now for the pickers and the behavior should remain the same. E.g. The items returned from the picker are available temporarily and are not available by PATH or any other means unless added to the MRU or FutureAccessList. In particular the implementation must NOT internally add items to either list as the contents of those lists are owned by the application - not the system. Though we may want to take the opportunity here to include the user intent that access is supposed to only be one time to and block adding the item to the MRU/FAL @ptorr-msft may have some thoughts on that as he's talked about that before. #Resolved

specs/Picker-API_spec.md

usvoyager · 2020-07-28T18:49:31Z

specs/Picker-API_spec.md

+            String CancelButtonText { set; }
+            Windows.Foundation.Collections.IMap<String, String> FilterAndDescription{ get; }
+            PickerViewMode ViewMode;
+            StorageItemPickerKinds PickerKinds;


PickerKinds [](start = 35, length = 11)

ItemKinds #Resolved

soumyamahunt · 2020-07-29T04:36:56Z

I think another feature that can be added in reunion picker api is the choice to add custom options to picker dialog like Win32 apps Notepad and Microsoft Word do:

This can either be done in the same way PrintManager allows custom options or hosting custom xaml control in the picker dialog itself.

mdtauk · 2020-07-29T04:47:09Z

We were discussing implementing those custom items with a future File Picker Dialog.

microsoft/microsoft-ui-xaml#2854

ZenBird-zz · 2020-09-14T23:27:16Z

Currently this is not in scope. We can look to address this as part of future work.

In reply to: 659771383 [](ancestors = 659771383)

ZodmanPerth · 2020-09-24T03:17:28Z

Can we consider the case for using the FileSavePicker to allow the user to specify a filename in a folder location without allowing the "overwrite existing file" prompt? Some sort of boolean to control if selecting an existing files is allowed would be wonderful. #Resolved

Poopooracoocoo · 2020-09-29T05:37:14Z

so this is opt-in for apps? :( #Resolved

this really shouldn't be up to apps to choose. >:( #Resolved

ZenBird-zz · 2020-09-29T17:58:56Z

This is not going to replace the existing FilePicker api. Apps can choose to use this API instead of the existing FilePicker.

In reply to: 700438667 [](ancestors = 700438667)

mdtauk · 2020-09-29T18:02:06Z

Will this API apply to platforms like Xbox where file storage is handled differently?

ZenBird-zz · 2020-09-30T21:42:01Z

I am not aware of Reunion effort targeting platforms other than Desktop. Maybe @jonwis can comment on this.

In reply to: 700884503 [](ancestors = 700884503)

jonwis

Next up, @ShawnSteele

jonwis · 2020-10-05T16:24:32Z

specs/Picker-API_spec.md

+
+**3. Unable to specify an arbitrary start location for the picker.**
+
+   The existing File/Folder pickers do not allow the developer to specify an arbitrary start location (even if the app has access). Currently, the start location is limited to a set of predefined enum values.


Please line-wrap at 100 columns. VSCode has various Prettifier plugins that'll do that for you. #Resolved

jonwis · 2020-10-05T16:26:56Z

specs/Picker-API_spec.md

+APIs in the Windows SDK. The Reunion Picker API will supercede the existing APIs and add additional methods
+for the functionality: File and folder picker, Multiple folder picker.
+
+- Windows.Storage.Pickers.FileOpenPicker (https://docs.microsoft.com/en-us/uwp/api/Windows.Storage.Pickers.FileOpenPicker)


Make these real links, like [nice text](http://link/here) #Resolved

jonwis · 2020-10-05T16:27:39Z

specs/Picker-API_spec.md

+    if(0 < storageItems.Count)
+    {
+    }
+```


Markdown usually likes additional blank lines after headers and triple-ticks. If it's rendering don't worry about it. #Resolved

jonwis · 2020-10-05T16:28:21Z

specs/Picker-API_spec.md

+```c#
+    var picker = new StorageItemPicker();
+    picker.FiltersAndDescriptions.Insert("Images", "*.jpg, *.png");
+    picker.StartLocation = startLocation;


Expand sample to show the type of startLocation #Resolved

jonwis · 2020-10-05T16:29:02Z

specs/Picker-API_spec.md

+Picker APIs in Windows SDK with additional methods to support File + Folder picker and multiple folder picker. The Project Reunion APIs will supercede the Windows APIs.
+
+# Examples
+## Show file and folder picker


More descriptive title - "Pick specific images or a folder to open" #Resolved

jonwis · 2020-10-05T16:37:11Z

specs/Picker-API_spec.md

+            String CommitButtonText;
+            String CancelButtonText;
+            Windows.Foundation.Collections.IPropertySet FiltersAndDescriptions{ get; };
+            ViewMode PickerViewMode;


Should be PickerViewMode DefaultViewMode; instead ... the user can change the view mode during the pick operation, so either Default... or Initial... to say that it's the app's desired initial state, but not a requirement. #Resolved

jonwis · 2020-10-05T16:37:35Z

specs/Picker-API_spec.md

+# API Notes
+# API Details
+```c#
+    namespace Microsoft.Reunion.Storage.Pickers


Not sure this is the right namespace yet. #Resolved

Discussions to date have agreed namespaces shouldn't include 'Reunion' (or ProjectReunion) in their name, and recommended variants of existing APIs should use variants of existing namespaces but Microsoft. instead of Windows. e.g. Microsoft.Storage.Pickers

@jonwis docs\Coding-Guidelines.md makes no mention of namespace guidance. We should add it (in a new WinRT section)? #Resolved

jonwis · 2020-10-05T16:37:50Z

specs/Picker-API_spec.md

+```c#
+    namespace Microsoft.Reunion.Storage.Pickers
+    {
+        enum PickerViewMode


Should probably be StorageItemPickerViewMode ? #Resolved

jonwis · 2020-10-05T16:38:02Z

specs/Picker-API_spec.md

+            String SuggestedSaveFile;
+            String DefaultFileExtension;
+            Boolean MultiSelect;
+            Int64 Result{ get; }


What is this? #Resolved

This holds the dialog result(Canceled, Access_Denied etc.). This can be removed in favor of packaging the result with IAsyncOperation

In reply to: 499730295 [](ancestors = 499730295)

jonwis · 2020-10-05T16:39:29Z

specs/Picker-API_spec.md

+            StorageItemPicker();
+
+            /// Properties
+            String StartLocation;


This should probably be StartLocationFolderPath, since it's a path. What happens if the app does not have access to this path? Is there a prompt for the user to approve picking from here to start with? Or is the act of picking implicit approval? #Resolved

IMO, this API app should accept an arbitrary folder path when running in an AppContainer, but not allow any other operations on that folder or its contents except through the usual methods.

Can I specify a StartLocation via a StorageFolder e.g.

var sip = new StorageItemPicker(); sip.Start = Windows.Storage.KnownFolders.PicturesLibrary;

I can see merit in both

String StartFolderPath; StorageFolder StartFolderLocation;

and .ShowPickerAsync() throws an exception if both are specified

Woudn't you be able to just use the Path API on the StorageFolder? E.g.:

var sip = new StorageItemPicker(); sip.StartFolderPath = Windows.Storage.KnownFolders.PicturesLibrary.Path;

The documentation for Path states "The full path of the current folder in the file system, if the path is available", so perhaps that's a scenario which would require one can specify a StorageFolder as the StartLocation (no full path available)?

StorageFolders that represent libraries like the PicturesLibrary don't necessarily have paths, since they are shell constructs and not filesystem directories. You could get the 'best' directory from SHGetKnownFolderPath though (.NET has an equivalent).

Yes, as I have mentioned in the original thead here, using the .NET equivalent could look like:

var sip = new StorageItemPicker() { StartFolderPath = Environment.GetFolderPath(Environment.SpecialFolder.MyPictures) };

so at least in that case, we would be fine without shipping a specific StorageFolder StartFolderLocation API.

IMO, this API app should accept an arbitrary folder path when running in an AppContainer, but not allow any other operations on that folder or its contents except through the usual methods.

Yes, the point of the picker is to get files you don't have access to. If the user doesn't like the location, they can change it.

Relying on a single, fixed list of locations (current Windows. API) or relying on the app already having access vastly reduces the functionality. For example, if I already have access to C:\Foo\bar.txt I might want the user to pick another file from C:\Foo\ even though I don't have access. (I believe the current API remembers the last start location, but that doesn't help if the user picked another file in the meantime...)/

The new pickers should be easy to nest into user controls or dialogs, and should allow simple access from MVVM viewmodels. Don't repeat WPF's mistakes.

ZenBird-zz · 2020-10-05T19:05:26Z

This can be enabled via a property similar to Win32 IFileDialog interface.

In reply to: 698086497 [](ancestors = 698086497)

DrusTheAxe · 2020-10-06T04:30:23Z

specs/Picker-API_spec.md

+            Windows.Foundation.Collections.IPropertySet FiltersAndDescriptions{ get; };
+            ViewMode PickerViewMode;
+            StorageItemPickerKinds PickerKinds;
+            String SuggestedSaveFile;


Suggested? Do we use that terminology? Default seems more natural

File sounds like an object, but this is just a filename. String DefaultSaveFilename? #Resolved

Suggested mirrors the SuggestedStartLocation, although most WinRT APIs use the term Prefer or Request when the app is giving a hint that the platform can ignore. .NET just calls it FileName (note the different capitalization as well... which is quite dated since now the world recognizes "filename" as a single word in the English language).

PreferredFilename?

In reply to: 500440519 [](ancestors = 500440519)

ptorr-msft · 2020-10-06T16:40:51Z

specs/Picker-API_spec.md

+    picker.FiltersAndDescriptions.Insert("Images", "*.jpg, *.png");
+    picker.StartLocation = startLocation;
+    picker.PickerKinds = StorageItemPickerKinds.Folder | StorageItemPickerKinds.FileOpen;
+    // multi-select will be automatically set


Multi-select is the default? Is that what applications expect? It defaults to false in the .NET pickers. #Resolved

MultiSelect is being automatically set since the PickerKind is both files and folders. Multiselect is false by default.

In reply to: 500443235 [](ancestors = 500443235)

That doesn't logically follow though... it's legitimate to want to pick a single file or a single folder. Also, having one property change value based on another property's value is against guidelines. For example, the following two bits of code should be equivalent:

picker.PickerKinds = Folder | FileOpen; picker.Multiselect = false;

and

picker.Multiselect = false; picker.PickerKinds = Folder | FileOpen;

But they are not equivalent; the first one works as expected, but the second one does not. #Resolved

Updated to false by default. No automatic setting of the property.

In reply to: 500446491 [](ancestors = 500446491,500443235)

ZenBird-zz · 2020-10-13T16:46:56Z

specs/Picker-API_spec.md

+    }
+```
+
+## Pick folders


s [](start = 14, length = 1)

Pick folder no "s" at the end. Picking a single folder. #Resolved

Adding StorageItemPickerResult to return the result of the operation. Added more code to the samples. Addressed feedback comments

ghost · 2021-03-28T13:22:08Z

@zenbird what happened to this PR?

mdtauk · 2021-05-15T18:25:24Z

Yea, what is the status of the updated XAML based File Pickers?

ghost added the needs-triage label Jun 30, 2020

wjk suggested changes Jun 30, 2020

View reviewed changes

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

ZenBird-zz force-pushed the master branch from f3ab812 to 6531c1e Compare June 30, 2020 20:15

wjk suggested changes Jun 30, 2020

View reviewed changes

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

ZenBird-zz force-pushed the master branch 2 times, most recently from 943b5e3 to cee7d60 Compare June 30, 2020 23:28

usvoyager reviewed Jul 1, 2020

View reviewed changes

specs/Picker-API_spec.md Show resolved Hide resolved

MikeHillberg reviewed Jul 2, 2020

View reviewed changes

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

Adding initial spec for Reunion Picker API.

438f817

ZenBird-zz force-pushed the master branch from cee7d60 to 438f817 Compare July 6, 2020 19:42

ZenBird-zz marked this pull request as draft July 6, 2020 19:44

Merge branch 'master' into master

e044a5b

ZenBird-zz marked this pull request as ready for review July 6, 2020 21:23

ZenBird-zz mentioned this pull request Jul 7, 2020

Discussion: File/Folder picker microsoft/microsoft-ui-xaml#2854

Closed

jonwis added area-File access and removed needs-triage labels Jul 16, 2020

jonwis requested changes Jul 16, 2020

View reviewed changes

smaillet-ms suggested changes Jul 21, 2020

View reviewed changes

ptorr-msft reviewed Jul 22, 2020

View reviewed changes

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

ptorr-msft reviewed Jul 22, 2020

View reviewed changes

specs/Picker-API_spec.md Outdated Show resolved Hide resolved

Merge branch 'master' into master

4b400c5

ZenBird-zz force-pushed the master branch from 7589a73 to 4b400c5 Compare July 24, 2020 04:53

usvoyager reviewed Jul 28, 2020

View reviewed changes

ZenBird-zz force-pushed the master branch 2 times, most recently from 6a47b62 to 4eafb66 Compare September 14, 2020 23:03

Felix-Dev mentioned this pull request Sep 23, 2020

Improved StorageFile APIs #8

Open

ZenBird-zz force-pushed the master branch from 4eafb66 to 6c66875 Compare September 30, 2020 21:39

ZenBird-zz assigned ShawnSteele and jonwis Sep 30, 2020

ZenBird-zz requested a review from jonwis September 30, 2020 22:34

jonwis requested changes Oct 5, 2020

View reviewed changes

DrusTheAxe reviewed Oct 6, 2020

View reviewed changes

ptorr-msft reviewed Oct 6, 2020

View reviewed changes

ZenBird-zz force-pushed the master branch 2 times, most recently from a6aed2f to 0b86e7d Compare October 13, 2020 16:41

ZenBird-zz commented Oct 13, 2020

View reviewed changes

ZenBird-zz force-pushed the master branch from 0b86e7d to b0e4553 Compare October 13, 2020 17:28

Added flags attribute to PickerKinds enum

09979a6

Adding StorageItemPickerResult to return the result of the operation. Added more code to the samples. Addressed feedback comments

ZenBird-zz force-pushed the master branch from b0e4553 to 09979a6 Compare October 13, 2020 17:43

EHO-makai closed this Nov 11, 2020

EHO-makai deleted the branch microsoft:master November 11, 2020 21:14

mdtauk mentioned this pull request May 29, 2021

Modern FontDialog and ColorDialog microsoft/microsoft-ui-xaml#5082

Open

bpulliam added feature proposal and removed feature labels May 26, 2024

		@@ -0,0 +1,115 @@
		# Background

		The current FilePicker API for UWP has several limitations. Some of the top limitations


		3. Unable to specify an arbitrary start location for the picker.

		The existing File/Folder pickers do not allow the developer to specify an arbitrary start location (even if the app has access). Currently, the start location is limited to a set of predefined enum values.

Adding initial spec for Reunion Picker API. #99

Adding initial spec for Reunion Picker API. #99

Conversation

ZenBird-zz commented Jun 30, 2020

mdtauk commented Jun 30, 2020 • edited by ZenBird-zz Loading

ZenBird-zz commented Jun 30, 2020 • edited Loading

mdtauk commented Jun 30, 2020 • edited by ZenBird-zz Loading

wjk left a comment

Choose a reason for hiding this comment

wjk commented Jun 30, 2020 • edited by ZenBird-zz Loading

jonwis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ptorr-msft Sep 15, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonwis Jul 16, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

smaillet-ms Jul 21, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdtauk commented Jul 17, 2020 • edited by ZenBird-zz Loading

smaillet-ms Jul 21, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

usvoyager Jul 28, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

soumyamahunt commented Jul 29, 2020

mdtauk commented Jul 29, 2020

ZenBird-zz commented Sep 14, 2020

ZodmanPerth commented Sep 24, 2020 • edited by ZenBird-zz Loading

Poopooracoocoo commented Sep 29, 2020 • edited by ZenBird-zz Loading

ZenBird-zz commented Sep 29, 2020

mdtauk commented Sep 29, 2020

ZenBird-zz commented Sep 30, 2020

jonwis left a comment

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

DrusTheAxe Oct 6, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonwis Oct 5, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DrusTheAxe Oct 6, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Felix-Dev Oct 6, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZenBird-zz commented Oct 5, 2020

DrusTheAxe Oct 6, 2020 • edited by ZenBird-zz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ptorr-msft Oct 6, 2020 • edited by ZenBird-zz Loading

mdtauk commented Jun 30, 2020 •

edited by ZenBird-zz

Loading

ZenBird-zz commented Jun 30, 2020 •

edited

Loading

mdtauk commented Jun 30, 2020 •

edited by ZenBird-zz

Loading

wjk commented Jun 30, 2020 •

edited by ZenBird-zz

Loading

ptorr-msft Sep 15, 2020 •

edited by ZenBird-zz

Loading

jonwis Jul 16, 2020 •

edited by ZenBird-zz

Loading

smaillet-ms Jul 21, 2020 •

edited by ZenBird-zz

Loading

mdtauk commented Jul 17, 2020 •

edited by ZenBird-zz

Loading

smaillet-ms Jul 21, 2020 •

edited by ZenBird-zz

Loading

usvoyager Jul 28, 2020 •

edited by ZenBird-zz

Loading

ZodmanPerth commented Sep 24, 2020 •

edited by ZenBird-zz

Loading

Poopooracoocoo commented Sep 29, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

DrusTheAxe Oct 6, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

jonwis Oct 5, 2020 •

edited by ZenBird-zz

Loading

DrusTheAxe Oct 6, 2020 •

edited by ZenBird-zz

Loading

Felix-Dev Oct 6, 2020 •

edited

Loading

DrusTheAxe Oct 6, 2020 •

edited by ZenBird-zz

Loading

ptorr-msft Oct 6, 2020 •

edited by ZenBird-zz

Loading

ptorr-msft Oct 6, 2020 •

edited by ZenBird-zz

Loading

ZenBird-zz Oct 13, 2020 •

edited

Loading