Metadata commands

Introduce the annotate and the inspect commands.
Fixes https://github.com/kubewarden/kwctl/issues/8
Annotate
$ kwctl annotate
           -m ../psp-apparmor/metadata.yml \
           -o annotated.wasm \
           ../psp-apparmor/target/wasm32-unknown-unknown/release/psp_apparmor.wasm

This command reads the user-provided metadata file, reads a vanilla Wasm file and produces a Wasm file that has the metadata embedded as a custom Wasm section.
Inspect
$ kwctl inspect file:///home/flavio/hacking/kubernetes/kubewarden/kwctl/annotated.wasm
Metadata:
---
protocolVersion: v1
rules:
  - apiGroups:
      - ""
    apiVersions:
      - v1
    resources:
      - pods
    operations:
      - CREATE
      - UPDATE
labels:
  io.kubewarden.policy.url: "https://github.com/chimera-kube/psp-apparmor"
  io.kubewarden.policy.license: Apache-2.0
  io.kubewarden.policy.source: "https://github.com/chimera-kube/psp-apparmor"
  io.kubewarden.policy.author: Flavio Castelli

This command dumps the metadata stored inside of a policy to the stdout.
The command works also with policies that are inside of the main store, plus it handles policies that do not have metadata:
$ kwctl inspect 'registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.3'`
Error: No Kubewarden metadata found inside of 'registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.3'.
Policies can be annotated with the `kwctl annotate` command.

I put the right deps into the Cargo.toml. I have also undone the version bump. We can do that when we have more features to push out


[DUBBO-78] Add options configuration mechanism for JdkCompiler.

What is the purpose of the change
I personally need this mechanism in one of my repos, (I have to copy/change this whole class now because not having such mechanism, I need a JdkCompiler to deal with java 1.8 codes)
and I think it helpful to other people too.
Brief changelog
JdkCompiler
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[x] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[x] If this contribution is large, please follow the Software Donation Guide.

Hi, @XenoAmess , you can customize a AbstractCompiler in your project using SPI.

Hi, @XenoAmess , you can customize a AbstractCompiler in your project using SPI.

Yep, now I copied the JdkCompiler and changed it to a Jdk8Compiler.
It can do.
see https://github.com/XenoAmess/metasploit-java-external-module/blob/develop/src/loader/src/main/java/com/xenoamess/metasploit/java_external_module/loader/Jdk8Compiler.java
I just think things can be easier... because that be just duplicated codes lol.

Codecov Report

Merging #7232 (21ac1f5) into master (33a547c) will decrease coverage by 0.23%.
The diff coverage is 77.77%.

@@             Coverage Diff              @@
##             master    #7232      +/-   ##
============================================
- Coverage     60.00%   59.76%   -0.24%
+ Complexity      289      287       -2
============================================
  Files          1004     1004
  Lines         40015    39977      -38
  Branches       5935     5905      -30
============================================
- Hits          24010    23894     -116
- Misses        13304    13371      +67
- Partials       2701     2712      +11

Impacted Files
Coverage Δ
Complexity Δ

...che/dubbo/common/compiler/support/JdkCompiler.java
61.68% <77.77%> (-1.53%)
0.00 <0.00> (ø)

...va/org/apache/dubbo/remoting/TimeoutException.java
0.00% <0.00%> (-33.34%)
0.00% <0.00%> (ø%)

...bo/config/event/listener/LoggingEventListener.java
37.50% <0.00%> (-25.00%)
0.00% <0.00%> (ø%)

...dubbo/remoting/exchange/support/DefaultFuture.java
68.14% <0.00%> (-19.04%)
0.00% <0.00%> (ø%)

...bbo/common/bytecode/CustomizedLoaderClassPath.java
28.00% <0.00%> (-16.00%)
0.00% <0.00%> (ø%)

...ng/transport/dispatcher/WrappedChannelHandler.java
47.82% <0.00%> (-15.22%)
0.00% <0.00%> (ø%)

...ng/transport/dispatcher/all/AllChannelHandler.java
68.96% <0.00%> (-13.80%)
0.00% <0.00%> (ø%)

...dubbo/common/status/support/LoadStatusChecker.java
50.00% <0.00%> (-11.54%)
0.00% <0.00%> (ø%)

...in/java/org/apache/dubbo/common/utils/JVMUtil.java
81.13% <0.00%> (-11.33%)
0.00% <0.00%> (ø%)

...ava/org/apache/dubbo/config/DubboShutdownHook.java
63.82% <0.00%> (-10.64%)
0.00% <0.00%> (ø%)

... and 41 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 33a547c...6e3f8fb. Read the comment docs.

@AlbumenJ
still wondering...
why JdkCompiler.java  be CRLF but JdkCompilerTest.java be LF?
please consider do a unify...

Hi @XenoAmess Thank you for the contribution. We have reviewed and merged some of your pull requests recently. However, all the changes are code reformats which do not match the overall evolve plan of the community and will bring us a lot of conflicts and verifications.
I think it will be better for us to focus on such refactoring when we arrive at a certain stage. We have labeled all PR as reopen later so that we can review these PRs later.
Please feel free to let us know if you have any questions.

all the changes are code reformats

Not all of the prs are code reformats. for example, this one is not.
I wonder, have you at least read them all?
I will reopen the prs which be not reformat pr, and I hope you can at least find some time for them.

I think it will be better for us to focus on such refactoring when we arrive at a certain stage.

According to my former experience there will never be such a perfect stage.
But if you wanna delay some of them, I have no problem, as this is not my lib to maintain.

which do not match the overall evolve plan of the community

Well, you have different ideas about this with people in alibaba/p3c. As you are both alibaba team, I'm actually confused.
I thought you alibaba people will follow one same idea about code maintaining, and I heard every java repo in ali must pass p3c. Maybe I be wrong.

@chickenlj this pr is a functional pr, should not be closed.

@XenoAmess
In my opinion, this pr should be reopened.
Why we temporarily close those reformatting PRs is because we are currently resolve most of previous PRs which created for servals months and if we merge those reformatting PRs  may cause a lot of confilcts with the previous PRs .
Code maintaining is important, and we will make code clean enough once after we resolve those previous PRs.
We are sure that will reopen those reformatting PRs in the future, Also please feel free to notify us if we forget it.

Also, we cannot find if the file is in CRLF mode only from Github Pull Request website and it is sure that the files in the future PR in CRLF mode is unavoidable.

This can be done using checkstyle plugin.
We can fail the build when there be CRLF file.
See example at commons-lang.
https://github.com/apache/commons-lang/blob/master/pom.xml#L754
https://github.com/apache/commons-lang/blob/master/src/site/resources/checkstyle/checkstyle.xml#L28

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@6c779a9). Click here to learn what that means.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master    #7232   +/-   ##
=========================================
  Coverage          ?   58.68%
  Complexity        ?      528
=========================================
  Files             ?     1076
  Lines             ?    43371
  Branches          ?     6306
=========================================
  Hits              ?    25451
  Misses            ?    15071
  Partials          ?     2849

Impacted Files
Coverage Δ
Complexity Δ

...che/dubbo/common/compiler/support/JdkCompiler.java
63.55% <100.00%> (ø)
0.00 <0.00> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6c779a9...07230f5. Read the comment docs.


"TypeError: decoding Unicode is not supported" when debugging

Description
After updating to Spyder2.3.4, I notice some strange behavior:

running a script (F5) that loads other modules works fine
running the same script (F5) with an additional line "pdb.set_trace()" will produce the above error
the line position of the pdb call doesn't matter
running the same script in a standalone ipython console works well (including the pdb call)

I haven't seen this behavior in previous versions of Spyder

What is the expected output? What do you see instead?

Please provide any additional information below
using xubuntu14.04
If I can provide any further info, pls let me know.
Thanks a lot for providing the cool Spyder IDE!

Version and main components

Spyder Version:  2.3.4
Python Version:  2.7.6
Qt Version    :  4.8.6, PyQt4 (API v2) 4.10.4 on Linux

Optional dependencies
pyflakes >=0.5.0:  None (NOK)
pep8 >=0.6      :  None (NOK)
IPython >=1.0   :  2.2.0 (OK)
zmq >=2.1.11    :  14.0.1 (OK)
pygments >=1.6  :  1.6 (OK)
pandas >=0.13.1 :  0.15.2 (OK)
sphinx >=0.6.6  :  1.3b2 (OK)
psutil >=0.3    :  1.2.1 (OK)
rope >=0.9.2    :  None (NOK)
jedi >=0.8.1    :  0.8.1-final0 (OK)
matplotlib >=1.0:  1.3.1 (OK)
sympy >=0.7.3   :  0.7.5 (OK)
pylint >=0.25   :  None (NOK)

I can't reproduce it with master branch on Arch Linux. I didn't try with 2.3.4
Is there a full stack trace in addition to the line in the title ?

I've never seen this issue with previous versions of Spyder (2.2, 2.3.3...)
Is that the stack trace you want:
File "", line 1, in
runfile('/mnt/data/Research/001_Tegut/Python/AgentSystem_003_paper/opti_ants_V2_006_bastel.py', wdir='/mnt/data/Research/001_Tegut/Python/AgentSystem_003_paper')
File "/usr/local/lib/python2.7/dist-packages/spyderlib/widgets/externalshell/sitecustomize.py", line 682, in runfile
execfile(filename, namespace)
File "/usr/local/lib/python2.7/dist-packages/spyderlib/widgets/externalshell/sitecustomize.py", line 78, in execfile
builtins.execfile(filename, *where)
File "/mnt/data/Research/001_Tegut/Python/AgentSystem_003_paper/opti_ants_V2_006_bastel.py", line 42, in
res = wh.optimizeDeliveryTimeFrame()
File "/mnt/data/Research/001_Tegut/Python/AgentSystem_003_paper/opti_ants_V2_006_bastel.py", line 42, in
res = wh.optimizeDeliveryTimeFrame()
File "/usr/lib/python2.7/bdb.py", line 49, in trace_dispatch
return self.dispatch_line(frame)
File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
self.user_line(frame)
File "/usr/lib/python2.7/pdb.py", line 158, in user_line
self.interaction(frame, None)
File "/usr/local/lib/python2.7/dist-packages/spyderlib/widgets/externalshell/sitecustomize.py", line 488, in interaction
self.notify_spyder(frame) #-----Spyder-specific-------------------------
File "/usr/local/lib/python2.7/dist-packages/spyderlib/widgets/externalshell/sitecustomize.py", line 432, in notify_spyder
fname = unicode(fname, "utf-8")
TypeError: decoding Unicode is not supported

Addon: just installed pyflakes, pep8 and pylint using pip.
Odd behavior still the same.
Above used scripts were working well with Spyder 2.3.3

Solution: cleared all Spyder breakpoints (many existed in the module that was called). Now script runs fine with the pdb.set_trace() line and new breakpoints set up in the submodules.
Sorry for bothering, thanks a lot!
:-)

Grrr, another error that I didn't noticed. It'll be fixed in 3.0 now ;-)

Incredible response time :+1:
Anyway, clearing the bulk of breakpoints that were set in the modules with the previous version of Spyder (2.3.3) solved the issue.
Thanks a lot


[feat] Dark theme red value

Description
Need
Add new red value for dark theme
Specs

New value is #ff3333
#ee0000 does not pass contrast on #151515, our primary surface color for dark theme

Example image

Suggested solution
Add #ff3333 as a dark theme only brand red color
Example API
No response
Additional context
No response

@bennypowers Yes, both are fine, thanks.


Feat/cube impl

Now we support adding methods to structs!

Looks pretty good overall, I really like the vec of enums to more easily handle sequences of items in codegen. Makes things much more modular and reusable.


Allow multiple executions of perf test

Coverage remained the same at 91.295% when pulling 9a43421f4e26ec6930bcfaeb0f5b5e06ba601c66 on SAP:perf_improve into bf694da69505ca2b23111a55b048aee96a9a869e on cloudfoundry-incubator:master.

Coverage remained the same at 91.295% when pulling 9a43421f4e26ec6930bcfaeb0f5b5e06ba601c66 on SAP:perf_improve into bf694da69505ca2b23111a55b048aee96a9a869e on cloudfoundry-incubator:master.

Coverage remained the same at 91.295% when pulling 9a43421f4e26ec6930bcfaeb0f5b5e06ba601c66 on SAP:perf_improve into bf694da69505ca2b23111a55b048aee96a9a869e on cloudfoundry-incubator:master.


Generating satellite imagery animations notebook

Proposed changes
Add the Exporting satellite imagery animations notebook to the Real_word_examples folder.
Checklist (replace [ ] with [x] to check off)

[x] Remove any unused Python packages from Load packages
[x] Remove any unused/empty code cells
[x] Remove any guidance cells (e.g. General advice)
[x] Ensure that all code cells follow the PEP8 standard for code. The jupyterlab_code_formatter tool can be used to format code cells to a consistent style: select each code cell, then click Edit and then one of the Apply X Formatter options (YAPF or Black are recommended)
[x] Include relevant tags in the first notebook cell and re-use tags if possible
[x] Ensure appropriate colour schemes  have been used to maximise accessibility for vision impairment. Test your images or learn more with Coblis or TPGI
[x] Clear all outputs, run notebook from start to finish, and save the notebook in the state where all cells have been sequentially evaluated

Closes issues (optional)

Closes Issue #390

Getting this error when loading it


Move widgets and rendering inside src

Code outside of package:sky should import this code using
package:sky/rendering.dart
package:sky/widgets.dart
Moving this code into the "src" directory is a convention that signifies that
and it cleans up the generated dartdoc because the libraries in the src
directory aren't included in the generated documentation. Instead, the classes
are documented in the widgets.dart and rendering.dart libraries.

lgtm

don't forget to update the READMEs :-)


Add tag inputs to refine search

Coverage remained the same at 33.478% when pulling 89d08f57c3aedd77f4f093bda9ea4cd30321a0e5 on Kiloutre:patch-43 into c6168be8b1d049a80c13d91a786648d558b8e66b on NyaaPantsu:dev.

Coverage remained the same at 33.478% when pulling 89d08f57c3aedd77f4f093bda9ea4cd30321a0e5 on Kiloutre:patch-43 into c6168be8b1d049a80c13d91a786648d558b8e66b on NyaaPantsu:dev.

@Kiloutre for quality can you add a select instead?

@akuma06
can't because i don't know the options the select should have

Coverage remained the same at 33.139% when pulling c54b35d767f7032ec40ce600697c7e794bf875a3 on Kiloutre:patch-43 into 46d974b6c60f2d2ef3b18f8064f53b738d7c1693 on NyaaPantsu:dev.

Changes Unknown when pulling 5cbfedf54a40981f7c19a88e551796cd6cacccbd on Kiloutre:patch-43 into ** on NyaaPantsu:dev**.


Is docker search API implemented in 2.1.0-rc.0?

Could you please let me know if searching registry is implemented in 2.1.0-rc.0 release? Any references/documentation will be helpful.

You will find information here: https://github.com/docker/distribution/blob/master/ROADMAP.md#indexing-search-and-discovery
If you want raw listing of content, use the catalog API.
If you want to implement search, you can do it on top of the notification and/or catalog API.
docker search itself is not part of v2 yet.


bug(mat-tab-group): pagination does not work in flex container

Reproduction
https://stackblitz.com/edit/angular-n5waqv
Steps to reproduce:

Put mat-tab-group inside a display: flex container.

Expected Behavior
The pagination (left/right scroll) buttons should appear on smaller widths.
Actual Behavior
No pagination (left/right scroll) buttons.
Environment

Angular:
CDK/Material: 12.1.1
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Windows

See Also
#16371

@crisbeto Thank you!


Highest level of Education re-work

The form needs an option for "other" or at least a field where the user can type in their answer. There may be levels of education that don't exactly fit into our provided choices.

American Community Survey (Census Bureau) question is
What is the highest degree or level of school Caroline G Robinson has COMPLETED? If currently enrolled, select the previous grade or highest degree received. (Help - with COVID-19 guidance)
NO SCHOOLING COMPLETED

No schooling completed

NURSERY OR PRESCHOOL THROUGH GRADE 12

Nursery School
Kindergarten
Grade 1 through 11 - Specify grade 1-11
text box  here to fill in grade
12th grade - NO DIPLOMA

HIGH SCHOOL GRADUATE

Regular high school diploma
GED or alternative credential

COLLEGE OR SOME COLLEGE

Some college credit, but less than 1 year of college credit
1 or more years of college credit, no degree
Associate's degree (for example: AA, AS)
Bachelor's degree (for example: BA, BS)

AFTER BACHELOR'S DEGREE

Master's degree (for example: MA, MS, MEng, MEd, MSW, MBA)
Professional degree beyond a bachelor's degree (for example: MD, DDS, DVM, LLB, JD)
Doctorate degree (for example: PhD, EdD)

I just thought I would stick this in here as an example to consider

Thanks for the exhaustive list.
What do we want on our form?
The question uses radio buttons. Which bullet points should we include?


changes to support db 13.3+

Also adds db version as option to db benchmark script and a gpu only option (i.e. no spark rapids plugin).
Plus some other misc. updates (e.g. to logistic reg. notebooks, spark-rapids versions).
Includes a temporary patch till https://github.com/NVIDIA/spark-rapids/issues/10770 is fixed.

build

build


Enable Windows tests on the Open CI

Signed-off-by: Arthur She<EMAIL_ADDRESS>

#47 Needs to be merged before this PR, to fix MSVC Windows jobs.

Successful (and deliberately failing) test runs on the OpenCI:
Mbed-TLS/mbedtls-restricted#759:  head, merge
Mbed-TLS/mbedtls-restricted#850:  head, merge
Mbed-TLS/mbedtls-restricted#906:  head, merge


fix vagrant ssh command concatenation / multi-line string

currently, this code looks like a mix of concatenation w/ string literals in a multi-line string which doesn't work. had to fix to get vagrant provider to run.

Wow does it actually work?  We've been having problems with vagrant for months, but we've been so busy with other issues that we haven't gotten around to fixing it yet...
I think the only thing that needs to be changed is the commit message.  I'm somewhat particular about their format (see the contributing documentation, or other commits in the history).  Go ahead and fix that up and I'll merge.

@ejj After making the PR'd changes to the Vagrant image, I was able to quilt daemon && quilt run sparkPI.js (changed provider in code... as well as diskSize so I still have some free space on my system :P) without getting any errors about the provider going unavailable, failing to boot, etc.
That said, I haven't actually figured out where to see the output of the Spark job yet so I'm not 100% sure that the Vagrant provider works though I'm fairly sure that this change does since there's a clear before/after (will look into integration tests). I expect to see results in STDOUT of spark-submit command but didn't find out where that was being run last night (or which machine was master from Quilt logs). I'll continue looking tonight, but let me know if you have any tips!

Have a look at this:  it should tell you how to find the results (assuming it's working).
https://github.com/NetSys/quilt/tree/master/specs/spark

@ejj Ahh, will try that later tonight! Thanks.


Retention Policy - A Comparison.

I am using btrbk for btrfs snapshots and restic for backups, so I have been able to compare the two retention policies.  Here is btrbk's and restic's.  I find the former intuitive and easy to use.  I find the latter basically unworkable.  So, I'd like to suggest you consider the former.
Example:  I take backups every day and I want to save a backup 1 day old and a backup 1 week old.  If I use a forget -w2 policy, then the last backup of each of the last two weeks will be retained.  If either of those weeks have no backup, they are ignored.  When starting my daily backups, I only have one backup in the most recent of the two weeks.  So -w2 will only retain a backup in this most recent week and I will never generate a backup one week old.  I'll never get beyond a single backup one day old.  I am forced then to generate backups each day for 8 days before adding the w2 policy to my script.  Consider how complicated this would get if I want to keep one backup one month old, one a week old and one a day old.
Btrbk, on the other hand, is very simple, eg:

daily
Defines how many days back daily backups should be preserved. The first backup of a day (starting at preserve_hour_of_day) is considered a daily backup.

Similarly for hourly, weekly, etc.  So, snapshot_preserve 1d 1w gives me what I want.
I'm using restic 0.12.0 on Ubuntu 20.04.

We're using GitHub for bugs and feature requests, discussions should be in the forum. I'll close this issue for now in favor of the following thread there: https://forum.restic.net/t/forget-policy/4014


Remove unused scripts from the diagnostics demo scene

#4708 removed a script from the project and removed the need for the diagnostics demo to contain a SpeechInputHandler.
However, I forgot to remove the references to these scripts from the demo scene. This change fixes the issue.

/azp run mrtk_pr


Bug 61805 - Allow simple HTTP request

Description
Add simple HTTP request template
Creates an HTTP Request with Header Manager and View Results Tree
Motivation and Context
Simplify creating a simple HTTP request
How Has This Been Tested?
Create simple HTTP request with and without defaults on windows GUI
Screenshots (if appropriate):
NA
Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

[X ] My code follows the code style of this project.
[X ] I have updated the documentation accordingly.

Thanks for the PR. I fixed the last spacing issues and squashed the commits.


Change $nats::service_provider to $nats::service_type #20

Commit a change that should fix and issue where tests run on
modules/profiles using choria-nats would fail a is_expected.to compile
test due to an unknown variable error.

sweet, thanks a lot @dhollinger 👍


Update OuiBreadcrumb

[x] Blurry text
[x] Use Primary for tints/shades (tint/shade system tbd)
[ ] Appears larger size in 'Next' than in Current (Current is the correct size)

@KrooshalUX @BSFishy Can either of you verify if the final item is still needed or complete?


The Future: React Easy Stack

Just a little heads-up on my future plans 🙂
This lib is part of my private React stack, which I plan to open-source eventually. Easy State and Easy Params are already open sourced and Easy Router will be the next.
With the release of the router this repo will turn into a monorepo. The npm packages will still be available separately (react-easy-state, react-easy-params and react-easy-router) and also as a complete React framework (react-easy-stack). They will continue to be developed separately, but the source code will get a new home - the react-easy-stack repo - with a unified documentation.

Would it be a big issue for you if I dropped easy-state and easy-params in favor of easy-stack and let tree shaking do its job? I don't see much value in releasing 4 different libs instead of a single one with the current state of modern bundlers. The migration would be replacing 'react-easy-state' with 'react-easy-stack' globally in your projects. Feedback would be awesome 🙂
Otherwise the code is ready and I am really satisfied with the result. You will be able to use the exact same API in the browser, React Native and Node. I am currently testing, documenting and creating examples, which will take around 2 weeks more (hopefully).

Since the project is fairly new and not (yet) incredibly used (don't take it wrong) I would agree with you and make a single library which is also easier to maintain and include new features.

@solkimicreb I'd prefer a monorepo with separate packages.
Bundlers are not always good with tree shaking, I wouldn't rely on them. Plus, some devs are already trying to use es6 modules without bundlers, just by importing a module directly in browser (when they don't need old browsers support).

One note would be to make it very clear that they can be used in isolation. Having multiple packages helps with that but I can see why you'd want to consolidate. Do what you think is best would be my recommendation 🍻

It would be much better if the packages are separated.
Because on my side, I'm using NextJS with React-Easy-State, and it's been awesome so far. Please let these packages remain as separate ones 🙏🏼🙏🏼🙏🏼

Hey @solkimicreb , thanks for the swift reply!
Actually the reason on why I suggested keeping the package name as it is is because it easier for me to introduce more people to your package. Example: redux vs facebook-stack/state-management. When there is a unique name to the package, its easier to introduce other people/developers to it.
However, this project belongs to you and you should do what you think is best! (:

I agree with @joshuaquek and also kindly request that you consider keeping them as separate packages. Personally, I find that Yarn's workspaces feature combined with Lerna makes this a very manageable exercise.
Keeping them as separate packages allows you to use an independent versioning system which avoids unnecessary updates for those consuming only one of your packages.
And another personal opinion - I feel like it's easier for me to sell an individual package (to clients/colleagues) if it comes as such. Completely subjective this, but I just feel the idea of having to install a stack and only use part of it would put some people off.

P.S. I love you and THIS is the state library that I have been waiting for.

Thanks @ctrlplusb 😄
I small update for everyone. The react-easy-state package will continue to be available as a separate package (with the exact same name and continued versioning).
I already use (codename) react-easy-stack for several small and a large-scale project internally and I am more or less satisfied with the result. I am waiting for React 16.6 with the release since Suspense might affect the package (it also has async data resolution in the router part) and I don't want to refactor the API right after release.
🍻

A new update. I continue to use easy-stack for internal project, but wait even more with the release. (Sorry everyone). Now it is 100% clear that concurrent React will affect it in breaking ways, I just don't know exactly how until the scheduler and react-cache packages are out.

Hey @solkimicreb , so far no breakages on my side. It has been working great (its even easier to use than React Hooks, in my opinion 😂)

Agree with separate packages! 💯
Side note for @joshuaquek... Can you share some examples on how you're using this with NextJS? I also sent you an email :)

Hi @altruisticsoftware , here is a simple example of a single page in NextJs:

import { view, store } from 'react-easy-state'
import './style.css'

const state = store({
  myMessage: 'Hello World'
})

Element.defaultProps = {
  myValue: 1
}

function changeMessage(){
  state.myMessage = 'Goodbye for now!'
}

function Element ({ myValue }) {
  return (

{state.myMessage}

      <button onClick={changeMessage()}>Click me to change the message.</button>

  )
}

export default view(Element)

...or another example if you want one which uses React.Component:
import { view, store } from 'react-easy-state'
import { Component } from 'react'
import './style.css'

let state = store({
  myMessage: 'Hello World, my name is'
})

class Element extends Component {
  componentDidMount () {
    // Logic to run just before component renders
  }

  render () {
    const { firstNameFromProps = 'John', lastNameFromProps = 'Doe' } = this.props // Set default props
    return (

        {`${state.myMessage} ${firstNameFromProps} ${lastNameFromProps}`}

    )
  }

}

export default view(Element)


Multiproject delete other generate sites

Hy we have a project with more then one submodul.
in the parent we configur the plugin in the pluginMangagment
we want to generate a page for every submodule, but if the first submdul hav generate a page, the second module delete the first generate page and generate there own page.
:-(
the problem is the "publishingStrategy", both will always delete all pages under the "ancestorId".

Hi @flod1, thank you for using the Confluence Publisher. In https://github.com/confluence-publisher/confluence-publisher/issues/76, we have added some support for configuring the publishing strategy, but your case is currently not yet supported.
The current approach would be to manually create one ancestor page under your current root page in Confluence for each submodule and use the corresponding module-specific ancestor id in the module-specific configuration of the Confluence Publisher, together with the REPLACE_ANCESTOR strategy. In addition, you would have to make sure that no module is publishing any page to the root page of your documentation (the page you are currently using as the ancestor id).
We might add additional publishing strategies, but in your scenario, it is not really clear how and when to clean up existing pages in Confluence. When publishing a single module, some sibling pages might indeed be root pages of other modules (the ones to keep), but others might simply be pages that are obsolete (e.g. due to a previous renaming of a module-specific root page, and should be removed). Anyway, any valuable input is highly appreciated.

Thank you very much for your answer.
That's exactly how we implemented it for the first time. with more than 30 submodules, it's a breeze to start with, but it works.
i hope there will be more features soon.


Mobile - market in reporting: Weird behaviour with show more arrows

Closing but creating a new one for other issues linked to this


An Iconic Disaster

WinUI has delivered innovative and impressive new GUI elements, designs, and techniques, and the WinUI team has implemented many clever improvements.  But of course, nobody is capable of 100% pure perfection, so some deficiences must exist in WinUI.  So now I'd like to talk about a glaring exception in the impressive track record of WinUI; an area desperately in need of improvement:  Icon rendering in WinUI hardly works -- it's a disaster currently.
Icons are a very important topic, considering that most apps uses multiple icons in multiple places in multiple kinds of GUI elements (icons in buttons, toolbars, menus, tabs, standalone, etc).  Thus it's really surprising to observe that, currently, icon rendering hardly works in WinUI/UWP unfortunately.  Considering the extreme ubiquity of icons in apps, I consider this to be a high priority topic.
Use a PNG image as an icon?
For starters, look at a really simple case where you have an instance of Windows.UI.Xaml.Media.Imaging.BitmapImage that was produced from a PNG, and you want to use this PNG BitmapImage as an icon.  This should be super simple, right?  But no, unfortunately neither Windows.UI.Xaml.Controls.BitmapIconSource nor Windows.UI.Xaml.Controls.BitmapIcon support the ability to render a specified instance of BitmapImage -- surprising but true.
To use your BitmapImage instance as an icon, you are forced to use Windows.UI.Xaml.Controls.Image to render it because BitmapIconSource cannot.  This means that, in combination with the other problems I will describe, Windows.UI.Xaml.Controls.IconSourceElement is a nice idea but so badly broken that it's practically unusable currently.
See also:  Proposal: Create IconSource from Bitmap stream #601
Use an SVG image as an icon?
For example, you have an SVG image file that you want to use as an icon in multiple places in your app.  You're out of luck because the SVG renderer contains bugs.  See the most recent messages in this issue:
SVG Image sources behave unpredictably. #825
The names of BitmapIconSource and BitmapIcon suggest that they will not render SVG images because SVG images are vector not bitmap.  I haven't actually tested what happens if you try to set BitmapIconSource.UriSource to the URI of an SVG instead of a bitmap.  Unfortunately an IconSource subclass named ImageIconSource does not exist currently.
I am surprised to observe that WinUI does not yet have good support for scalable vector icons, neither colored vector icons (such as SVG) nor monochrome vector icons/symbols (such as paths).
SymbolIconSource and SymbolIcon are often unusable
For example, imagine you want to create a button that looks similar to this:

Thus you write XAML like this:
<Button Margin="20">
	<StackPanel Orientation="Vertical">
		<IconSourceElement Width="64" Height="64" Margin="8">
			<IconSourceElement.IconSource>
				<SymbolIconSource Symbol="Refresh"/>
			</IconSourceElement.IconSource>
		</IconSourceElement>
		<TextBlock Text="Reload Data" FontSize="20" FontWeight="SemiBold"/>
	</StackPanel>
</Button>

But it fails because the above XAML renders as follows:

As you can see, regardless of how large or small you make your IconSourceElement, the symbol still renders at a constant size of 20!  Yes, a constant size!  I could hardly believe it.   Shockingly, SymbolIconSource and SymbolIcon don't scale, and don't provide any way to manually configure the size of the icon, and don't have a FontSize property either.  (A FontSize property wouldn't be the right solution but anyway it doesn't exist.)
Following is an awkward inconvenient inefficient workaround that uses a Viewbox element to hack the icon into scaling.  An alternative workaround is to view SymbolIconSource as unusable, and stop using it entirely, and instead use a TextBlock element and set its TextBlock.FontSize property.
<Button Margin="20">
	<StackPanel Orientation="Vertical">
		<Viewbox Width="64" Height="64" Margin="8">
			<IconSourceElement>
				<IconSourceElement.IconSource>
					<SymbolIconSource Symbol="Refresh"/>
				</IconSourceElement.IconSource>
			</IconSourceElement>
		</Viewbox>
		<TextBlock Text="Reload Data" FontSize="20" FontWeight="SemiBold"/>
	</StackPanel>
</Button>

How IconSourceElement with SymbolIconSource should behave:  The same as BitmapIconSource and Windows.UI.Xaml.Controls.Image -- both of those scale the icon/image whereas SymbolIconSource does not -- a strange inconsistency.  The icon should be scaled in the same manner as an Windows.UI.Xaml.Controls.Image element does with its default setting of Stretch="Uniform", or the same as a Windows.UI.Xaml.Shapes.Path element with Stretch set to Uniform.
FontIconSource and FontIcon are also broken
FontIconSource and FontIcon are slightly less broken than SymbolIconSource because they have a FontSize property.  Actually a FontSize property is a bad solution but at least there exists some way of changing the icon size, and a bad way of changing the icon size is better (less bad) than the nothing that SymbolIconSource provides.
The idea of applying a FontSize to an icon is strange and doesn't make sense.  What makes sense is applying a Width and Height to an icon or image or path, not a FontSize.  A FontSize property is applicable to text but an icon is not text, rather an icon is akin to an image or path.
Instead of trying to apply font size to an icon, SymbolIconSource and FontIconSource should scale the icon in the same manner as BitmapIconSource does.
SymbolIconSource handles white space better than FontIconSource.  For example, have a look at how this SymbolIconSource snippet renders:

<Border Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
	<IconSourceElement Margin="0">
		<IconSourceElement.IconSource>
			<SymbolIconSource Symbol="Refresh"/>
		</IconSourceElement.IconSource>
	</IconSourceElement>
</Border>

The above rendering makes sense.  The Border encloses the icon without padding.  Now compare it with the failure of FontIconSource and FontIcon:

<Border Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
	<IconSourceElement Margin="0">
		<IconSourceElement.IconSource>
			<FontIconSource Glyph="↻" FontFamily="Global User Interface" />
		</IconSourceElement.IconSource>
	</IconSourceElement>
</Border>

As you can see above, FontIconSource and FontIcon render with padding/whitespace around the icon.  In practice, this makes it difficult to use the icon in a button because the spacing/layout looks strange because of the uncontrollable extra space introduced by FontIconSource.  The amount of white space on the left, top, right, and bottom sides varies depending on the font -- the white space comes from the font.
If you have several IconSourceElement instances, such as 10 different buttons (in a row) with icons, and some of those IconSourceElement instances use SymbolIconSource and some use FontIconSource and some use PathIconSource, then the 10 buttons look strange and inconsistent with each other because some have extra whitespace/padding (those that use FontIconSource) while the others don't.
FontIconSource and FontIcon are not any better than using a TextBlock element.  They render the same as TextBlock.  This rendering behavior makes no sense because they are supposed to render as icons not text.
If you use TextBlock instead of FontIcon, you might try to use the OpticalMarginAlignment property to eliminate the problematic whitespace/padding, but it doesn't work, as you can see following.  The first image (left) is with OpticalMarginAlignment="None" and the second image (right) is with OpticalMarginAlignment="TrimSideBearings".  As you can see, TrimSideBearings didn't trim anything at all, rather it moved the space on the left side to the right side (the total width remains unchanged), and it didn't trim the top and bottom sides, and no other trimming option exists in OpticalMarginAlignment.

<StackPanel Orientation="Horizontal">
	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<TextBlock Text="⎈" FontFamily="Global User Interface" FontSize="100" OpticalMarginAlignment="None" Margin="0" Padding="0"/>
	</Border>
	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<TextBlock Text="⎈" FontFamily="Global User Interface" FontSize="100" OpticalMarginAlignment="TrimSideBearings" Margin="0" Padding="0"/>
	</Border>
</StackPanel>

In WPF, one way of rendering a glyph/character as an icon (without whitespace/padding) is to do this:

Use either System.Windows.Media.FormattedText.BuildGeometry or System.Windows.Media.GlyphRun.BuildGeometry to convert the glyph/character to a Geometry instance.
Create an instance of System.Windows.Shapes.Path and set the Path.Data property to the Geometry returned by BuildGeometry.
Set the Path.Stretch property to Uniform.

Sadly, this technique cannot be used in WinUI because an equivalent of FormattedText.BuildGeometry does not exist in WinUI (or not that I'm aware of).
PathIconSource and PathIcon are unusable
For example, you have an instance of Windows.UI.Xaml.Media.PathGeometry that you want to use as a monochrome vector icon in multiple buttons, pages, or places in your app.  This should be super simple, right?  Just use Windows.UI.Xaml.Controls.PathIconSource or Windows.UI.Xaml.Controls.PathIcon and give it whatever PathGeometry instance you want?  But no, unfortunately this fails to render.  Surprising but true.
Following you can see the success of Windows.UI.Xaml.Shapes.Path versus the failure of Windows.UI.Xaml.Controls.PathIconSource (or PathIcon), when rendering the same PathGeometry (a house symbol).  The first image (left) is the Path element -- it works.  The second image (right) is PathIconSource -- a failed (truncated) rendering of an icon.

<StackPanel Orientation="Horizontal">
	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<Path Width="90" Height="90" Stretch="Uniform" Fill="Black">
			<Path.Data>
				M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
			</Path.Data>
		</Path>
	</Border>

	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<IconSourceElement Width="90" Height="90">
			<IconSourceElement.IconSource>
				<PathIconSource>
					<PathIconSource.Data>
						M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
					</PathIconSource.Data>
				</PathIconSource>
			</IconSourceElement.IconSource>
		</IconSourceElement>
	</Border>
</StackPanel>

The Path element succeeds because I set its Stretch property to Uniform, but this solution does not work for PathIconSource nor PathIcon -- they have no Stretch property.  Thus PathIconSource and PathIcon are unusable and you're forced to use the Path element instead, which means that IconSourceElement is a nice idea but so badly broken that it's practically unusable currently.
The fact that PathIconSource and PathIcon don't scale the icon is especially strange when you consider that BitmapIconSource does scale the icon.
A second reason why PathIconSource and PathIcon are broken is that if you try to use the same icon in multiple buttons, pages, or places in your app, it fails (throws an exception).  Unfortunately the Path element also suffers from the same failure, but it only fails in WinUI, not in WPF.  In WPF, you can "freeze" a Geometry instance and then use it in an unlimited number of places in your app.  For more info, see this issue:
PathIconSource claims to support sharing but throws exception (AKA shared Geometry issue) #827
If your PathGeometry instance represents a stroked figure instead of a filled figure, such as a "+" symbol consisting of a horizontal stroked lines over a vertical stroked line, then PathIconSource does not support your PathGeometry.  See issue:
PathIcon/PathIconSource should allow stroke to be set as well as fill #1279
Library of icons in app (re ResourceDictionary)
Edited:
I remembered another important part of this issue.  When using PathIconSource, obviously every app needs to store a collection of all the icons that the app uses (icons as paths/geometries in the case of PathIconSource).  This should be super simple to do because WinUI already supports the excellent ResourceDictionary feature.  Therefore, our problem is simply solved by storing the app's icons in a "MyResourceDictionary.xaml" file, right?  But no, unfortunately this only works in WPF, whereas it is still broken in WinUI, even after the number of years that have elapsed since the release of UWP/WinUI.
In WPF, you can easily store a collection of icons in your app like this:
<ResourceDictionary xmlns="..." xmlns:x="...">

	<PathGeometry x:Key="HouseSymbol">
		M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
	</PathGeometry>

	<PathGeometry x:Key="RefreshSymbol">
		...
	</PathGeometry>

	<PathGeometry x:Key="SettingsSymbol">
		...
	</PathGeometry>

</ResourceDictionary>

Actually, to be precise, in WPF, it's recommended to optimize the above by simply replacing PathGeometry with the optimized read-only equivalent of PathGeometry that is named StreamGeometry.  Easily done:
<StreamGeometry x:Key="HouseSymbol">
	M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
</StreamGeometry>

So that works great in WPF, but StreamGeometry is unsupported in WinUI.  As for the other class, PathGeometry, it does exist in WinUI but it still produces a compile-time error message when you try to use it (PathGeometry) in a ResourceDictionary XAML file:
Error XLS0503
A value of type 'String' cannot be added to a collection or dictionary of type 'PathFigureCollection'.

This bug could be easily fixed AFAIK, because most of the necessary work is already done, therefore I find it surprising that this bug still hasn't been prioritized after this number of years.  I thought it was standard recommended practice to increase the priority of a bugfix when the bug is easy to fix.
AFAIK the PathGeometry bug is easy to fix because the WinUI XAML compiler already compiles the following successfully, therefore most of the work is already done for PathGeometry.
<ResourceDictionary xmlns="..." xmlns:x="...">

	<Path x:Key="HousePathElement">
		<Path.Data>
			M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
		</Path.Data>
	</Path>

</ResourceDictionary>

Although Path in ResourceDictionary compiles successfully, you should use PathGeometry not Path.  Path is derived from Windows.UI.Xaml.FrameworkElement and Windows.UI.Xaml.UIElement, and each FrameworkElement instance is permitted to have only one parent FrameworkElement instance, and this won't change.  Thus you cannot (and should not) try to share the same Path instance among multiple different buttons in your app where the same icon needs to be used in multiple places.
Unlike the Path element, PathGeometry and/or StreamGeometry are suitable for being shared/used in multiple places, but as I mentioned in issue #827, it only works in WPF.  Currently WinUI malfunctions (throws an exception) when you try to share/use the same PathGeometry or PathIconSource instance in multiple places, even despite the fact that the documentation says that sharing is supported:

"PathIconSource is similar to PathIcon. However, because it is not a FrameworkElement, it can be shared."

Notice how the documentation says "because it is not a FrameworkElement".  This is the same reason why the ResourceDictionary should contain PathGeometry not Path.  Path derives from FrameworkElement whereas PathGeometry does not.
The conclusion is that WPF (but not yet WinUI) supports the storage of the app's icons in a "MyResourceDictionary.xaml" file.  This is very strange when you consider the fact that the only thing stopping WinUI from supporting it is a small easily-fixed bug in the XAML compiler.  (Or maybe the bugfix is more difficult to implement than it appears, because maybe some reason exists that I don't know about, but anyway, this bug needs to be fixed.)
Apps definitely need this ability to store their own icons/symbols, instead of being limited to predefined icons from Microsoft.   SymbolIconSource is an excellent feature (thanks!) but obviously it's unreasonable to limit apps to using only the predefined icons/symbols in the Windows.UI.Xaml.Controls.Symbol enumeration.
Classes were not updated for IconSource
When the IconSourceElement and IconSource classes was created in WinUI in order to replace the defective IconElement subclasses, unfortunately various other classes were not updated accordingly.  They should have been updated at the same time as when IconSource was released.  For example, in order to update MenuFlyoutItem, this needed to be done:

Create a property in MenuFlyoutItem named IconSource of type IconSource.
Mark the old property MenuFlyoutItem.Icon as obsolete by applying System.ObsoleteAttribute.  (This old property uses Windows.UI.Xaml.Controls.IconElement.)

public class MenuFlyoutItem : ...
{
	public Windows.UI.Xaml.Controls.IconSource IconSource { get; set; }

	[System.ObsoleteAttribute("Use IconSource property instead of Icon property.")]
	public Windows.UI.Xaml.Controls.IconElement Icon { get; set; }
}

The following have not yet been updated:

Windows.UI.Xaml.Controls.AppBarButton.Icon
Windows.UI.Xaml.Controls.AppBarToggleButton.Icon
Windows.UI.Xaml.Controls.MenuFlyoutItem.Icon
Windows.UI.Xaml.Controls.MenuFlyoutSubItem.Icon
Windows.UI.Xaml.Controls.NavigationViewItem.Icon
Windows.UI.Xaml.Controls.Primitives.NavigationViewItemPresenter.Icon
Windows.UI.Xaml.Controls.SettingsFlyout.IconSource (uses ImageSource not IconSource)

Already up-to-date:

Windows.UI.Xaml.Controls.SwipeItem.IconSource
Windows.UI.Xaml.Input.XamlUICommand.IconSource

Although the subclasses of IconSource currently render in a broken manner, this will be fixed and IconSource is still a good idea, thus the various other classes need to be updated to support IconSource instead of the old IconElement subclasses.
Conclusion: They're all broken!
Windows.UI.Xaml.Controls.IconSourceElement is a nice idea and its concept makes good sense, but unfortunately all subclasses of IconSource are currently broken:

BitmapIconSource
SymbolIconSource
FontIconSource
PathIconSource

Fixing this iconic disaster should be a high priority because icons are very common in apps.  Despite the fact that nearly all apps use icons, icon rendering hardly works in WinUI!

A FontSize property is applicable to text but an icon is not text

In this case it is, that's why it's called FontIcon.

In this case it is, that's why it's called FontIcon.

It's called FontIcon not TextIcon therefore it shouldn't behave like text, but currently it does behave like text and this text-like behavior causes failures.  We could interpret (or re-interpret) it as being named "FontIcon/FontIconSource" because the icon comes from a glyph in a font, and don't interpret the name "FontIcon" as meaning that it should behave like text.   Thus it shouldn't have a property that controls the size of the text, but it does.  It's meant to (or needs to) behave as an icon not text.
In order to control the icon size, wouldn't you prefer to set the Width and Height properties of IconSourceElement or an ancestor element of your choice, rather than trying to control the icon size via FontIcon/FontIconSource.FontSize?
Before you answer, keep in mind that the concept of IconSourceElement is better than its predecessors BitmapIcon, SymbolIcon, FontIcon, PathIcon.  The issue is that BitmapIcon etc are fundamentally defective designs because, for example, if you write some XAML for a ControlTemplate, UserControl, or Page etc and your XAML displays an icon by using BitmapIcon, then the icon is locked to being a bitmap -- that's a problem.  The icon cannot be later changed to a path-based or font-based icon because your XAML uses BitmapIcon and BitmapIcon only supports bitmap icons.
This problem cannot be solved by simply editing the XAML to change BitmapIcon to PathIcon whenever you want to switch from a bitmap to a path -- this doesn't work because the person who writes the XAML of a ControlTemplate is often a different person than the various people who use it.  The solution is to use IconSourceElement instead of BitmapIcon etc, and then the ControlTemplate works for everyone regardless of what kind of icon they want/need to use, and the ControlTemplate XAML doesn't require modification whenever someone simply needs to display a different kind of icon.
Thus IconSourceElement is an excellent concept, but in practice it only succeeds if IconSourceElement.IconSource can be set to any subclass of IconSource (any kind of icon) without breaking the size of the rendered icon.  This means that each subclass of IconSource needs to behave consistently in regards to icon size, but currently they behave wildly differently than each other.
Currently, when you use IconSourceElement in the XAML of your ControlTemplate or Page or wherever, you can easily configure your IconSourceElement instance in a way that makes it render perfectly when IconSourceElement.IconSource is set to BitmapIconSource, but then your IconSourceElement instance breaks (renders incorrectly) as soon as IconSourceElement.IconSource is set to FontIconSource, SymbolIconSource, or PathIconSource.  This causes IconSourceElement to be practically unusable, or at least it defeats the purpose of IconSourceElement.
In order to make IconSourceElement.IconSource interchangeable with any subclass of IconSource (any kind of icon), each subclass of IconSource needs to render the icon consistently with the same size as BitmapIconSource and Controls.Image do, meaning all subclasses of IconSource need to scale the icon to fit the available space.  IconSourceElement breaks when different different subclasses of IconSource use completely different ways of controlling icon size such as FontIconSource.FontSize.
Thus the existence of FontIconSource.FontSize represents a design defect and it should be removed.  However, if people still desire the option to use FontIconSource.FontSize, then instead of removing this property entirely, it could be made optional, meaning it could operate like this:

When FontIconSource.FontSize is set to System.Double.NaN or defaults to NaN (similar to how the default value of FrameworkElement.Width is NaN), then it would render like BitmapIconSource, Controls.BitmapIcon, and Controls.Image already do:  Scale the icon.  This also makes the Width/Height/MinWidth/MaxHeight properties usable/settable in either IconSourceElement or an ancestor element of your choice.
When FontIconSource.FontSize is not NaN, then it would operate the same as it does today:  The FontSize property controls the size of the icon instead of the normal behavior of scaling the icon.  This mode might be useful in some circumstances, but the disadvantage of this mode is that it breaks the interchangeability of IconSourceElement.IconSource.

An analogy with the Image Control
Windows.UI.Xaml.Controls.Image defines these Source and Stretch properties:
public class Image : ...
{
	public Windows.UI.Xaml.Media.ImageSource Source { get; set; }
	public Windows.UI.Xaml.Media.Stretch Stretch { get; set; }
	...
}

The current design of the Image Control works well.  Now imagine what would happen if you remove the Stretch property from Image and instead place it in ImageSource.
public class Image
{
	public Windows.UI.Xaml.Media.ImageSource Source { get; set; }
	...
}

public class ImageSource
{
	public Windows.UI.Xaml.Media.Stretch Stretch { get; set; }
	...
}

That would be madness, but let's imagine making it even worse by adding settable sizing properties to ImageSource akin to the Width/Height properties that Image contains/inherits from FrameworkElement:
public class FrameworkElement
{
	public double Width { get; set; }
	public double Height { get; set; }
	...
}

public class Image : FrameworkElement
{
	public Windows.UI.Xaml.Media.ImageSource Source { get; set; }
	...
}

public class ImageSource
{
	public Windows.UI.Xaml.Media.Stretch Stretch { get; set; }
	public double Width { get; set; }
	public double Height { get; set; }
	...
}

That would really be madness -- it'd cause chaos!  I believe I don't need to explain why this would cause chaos, because everyone already understands and agrees that the Stretch, Width, Height properties need to be located in Image not in ImageSource.  That's obvious.
However, despite the fact that everyone knows that placing Stretch, Width, Height in ImageSource would be madness, the current version of WinUI does engage in this madness anyway, but only in the case of IconSource not ImageSource.
I'm not saying that IconSource.Stretch exists (it doesn't exist), rather I mean that in principle IconSource subclasses behave with the same kind of madness as if IconSource.Stretch did exist:

BitmapIconSource renders like Windows.UI.Xaml.Media.Stretch.Uniform.
PathIconSource renders like Windows.UI.Xaml.Media.Stretch.None.
SymbolIconSource renders like Windows.UI.Xaml.Media.Stretch.None plus a constant size of 20.
FontIconSource renders like Windows.UI.Xaml.Media.Stretch.None plus a size determined by FontIconSource.FontSize.  This FontSize property is the same madness as if  ImageSource.Width/Height would exist instead of (or in addition to) Image.Width/Height.

In principle, the current behavior of IconSource subclasses is the same madness and chaos as if the Image.Stretch property would be moved to ImageSource.Stretch.  Also in principle, FontIconSource.FontSize is the same chaos as if settable ImageSource.Width/Height properties would exist.
The WinUI team has repeatedly delivered impressive stuff, except for the dysfunctional icon rendering.  No big deal; just fix it and become even greater! :smile:

@jevansaks - is this a proposal? It feels more like a discussion that should lead to one or more proposals.
@verelpode you make some really good points - to summarize and ensure I understand what you're saying, it's that:

IconSource's API structure/behavior is inconsistent with that of similar components, like Image and ImageSource
Subclassing IconSource to Bitmap/Symbol/Font/PathIconSource all result in different sizing behavior that isn't consistent and renders IconSource rather unusable because of this
If IconSource's sizing behavior operated in a similar way to how Image and ImageSource work, it would mean that FontIconSource is practically obsolete, because the need to size the icon would be mostly handled by the system or through height/width properties instead of a "FontSize" property.

Is the above summary correct?

Hi @kikisaints, thanks for the quick reply.

IconSource's API structure/behavior is inconsistent with that of similar components, like Image and ImageSource.

Correct.

Subclassing IconSource to Bitmap/Symbol/Font/PathIconSource all result in different sizing behavior that isn't consistent and renders IconSource rather unusable because of this.

Correct.

If IconSource's sizing behavior operated in a similar way to how Image and ImageSource work, it would mean that FontIconSource is practically obsolete, because the need to size the icon would be mostly handled by the system or through height/width properties instead of a "FontSize" property.

There's a typo in that point.  The typo can be correct as follows:
"If IconSource's sizing behavior operated in a similar way to how Image and ImageSource work, it would mean that FontIconSource the property FontIconSource.FontSize is practically obsolete, because ...."
The FontIconSource class is a good idea; don't throw it in the garbage bin; just fix its problems and it will become great.  The two problems with FontIconSource are:

The sizing behavior / "FontSize" property as mentioned above.
The glyph needs to be rendered without the whitespace/padding that currently surrounds the glyph.  In other words, the whitespace/padding behavior of FontIconSource needs to be made consistent with SymbolIconSource.  (To implement this fix, note that in WPF, BuildGeometry is one way of eliminating the whitespace/padding.)

I also suggest that the following points are important for inclusion in a summary:

A common requirement is to share or use the same icon in multiple different places in the app, but this fails (throws an exception) despite the documentation saying that PathIconSource supports sharing.
The WinUI XAML compiler fails to compile PathGeometry in ResourceDictionary XAML files.  See details in my next message.

The first or second version of something is hardly ever great, but who cares?  What I love about software development is that we can produce a third or fourth version that is great, and erase the mistakes of the first and second versions.  The concept of IconSourceElement is solid and if a new version is released, then WinUI's support for icons can definitely become great.  Success is not far away!  :smile:

Library of icons in app (re ResourceDictionary)
I remembered another important part of this issue.  When using PathIconSource, obviously every app needs to store a collection of all the icons that the app uses (icons as paths/geometries in the case of PathIconSource).  This should be super simple to do because WinUI already supports the excellent ResourceDictionary feature.  Therefore, our problem is simply solved by storing the app's icons in a "MyResourceDictionary.xaml" file, right?  But no, unfortunately this only works in WPF, whereas it is still broken in WinUI, even after the number of years that have elapsed since the release of UWP/WinUI.
In WPF, you can easily store a collection of icons in your app like this:
<ResourceDictionary xmlns="..." xmlns:x="...">

	<PathGeometry x:Key="HouseSymbol">
		M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
	</PathGeometry>

	<PathGeometry x:Key="RefreshSymbol">
		...
	</PathGeometry>

	<PathGeometry x:Key="SettingsSymbol">
		...
	</PathGeometry>

</ResourceDictionary>

Actually, to be precise, in WPF, it's recommended to optimize the above by simply replacing PathGeometry with the optimized read-only equivalent of PathGeometry that is named StreamGeometry.  Easily done:
<StreamGeometry x:Key="HouseSymbol">
	M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
</StreamGeometry>

So that works great in WPF, but StreamGeometry is unsupported in WinUI.  As for the other class, PathGeometry, it does exist in WinUI but it still produces a compile-time error message when you try to use it (PathGeometry) in a ResourceDictionary XAML file:
Error XLS0503
A value of type 'String' cannot be added to a collection or dictionary of type 'PathFigureCollection'.

This bug could be easily fixed AFAIK, because most of the necessary work is already done, therefore I find it surprising that this bug still hasn't been prioritized after this number of years.  I thought it was standard recommended practice to increase the priority of a bugfix when the bug is easy to fix.
AFAIK the PathGeometry bug is easy to fix because the WinUI XAML compiler already compiles the following successfully, therefore most of the work is already done for PathGeometry.
<ResourceDictionary xmlns="..." xmlns:x="...">

	<Path x:Key="HousePathElement">
		<Path.Data>
			M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
		</Path.Data>
	</Path>

</ResourceDictionary>

Although Path in ResourceDictionary compiles successfully, you should use PathGeometry not Path.  Path is derived from Windows.UI.Xaml.FrameworkElement and Windows.UI.Xaml.UIElement, and each FrameworkElement instance is permitted to have only one parent FrameworkElement instance, and this won't change.  Thus you cannot (and should not) try to share the same Path instance among multiple different buttons in your app where the same icon needs to be used in multiple places.
Unlike the Path element, PathGeometry and/or StreamGeometry are suitable for being shared/used in multiple places, but as I mentioned in issue #827, it only works in WPF.  Currently WinUI malfunctions (throws an exception) when you try to share/use the same PathGeometry or PathIconSource instance in multiple places, even despite the fact that the documentation says that sharing is supported:

"PathIconSource is similar to PathIcon. However, because it is not a FrameworkElement, it can be shared."

Notice how the documentation says "because it is not a FrameworkElement".  This is the same reason why the ResourceDictionary should contain PathGeometry not Path.  Path derives from FrameworkElement whereas PathGeometry does not.
The conclusion is that WPF (but not yet WinUI) supports the storage of the app's icons in a "MyResourceDictionary.xaml" file.  This is very strange when you consider the fact that the only thing stopping WinUI from supporting it is a small easily-fixed bug in the XAML compiler.  (Or maybe the bugfix is more difficult to implement than it appears, because maybe some reason exists that I don't know about, but anyway, this bug needs to be fixed.)
Apps definitely need this ability to store their own icons/symbols, instead of being limited to predefined icons from Microsoft.   SymbolIconSource is an excellent feature (thanks!) but obviously it's unreasonable to limit apps to using only the predefined icons/symbols in the Windows.UI.Xaml.Controls.Symbol enumeration.
Note my message here is a different issue than https://github.com/microsoft/microsoft-ui-xaml/issues/827 because https://github.com/microsoft/microsoft-ui-xaml/issues/827 describes the sharing failure whereas the main point of my message here is the failure of the XAML Compiler to compile PathGeometry in ResourceDictionary.

Classes were not updated for IconSource
When the IconSourceElement and IconSource classes was created in WinUI in order to replace the defective IconElement subclasses, unfortunately various other classes were not updated accordingly.  They should have been updated at the same time as when IconSource was released.  For example, in order to update MenuFlyoutItem, this needed to be done:

Create a property in MenuFlyoutItem named IconSource of type IconSource.
Mark the old property MenuFlyoutItem.Icon as obsolete by applying System.ObsoleteAttribute.  (This old property uses Windows.UI.Xaml.Controls.IconElement.)

public class MenuFlyoutItem : ...
{
	public Windows.UI.Xaml.Controls.IconSource IconSource { get; set; }

	[System.ObsoleteAttribute("Use IconSource property instead of Icon property.")]
	public Windows.UI.Xaml.Controls.IconElement Icon { get; set; }
}

The following have not yet been updated:

Windows.UI.Xaml.Controls.AppBarButton.Icon
Windows.UI.Xaml.Controls.AppBarToggleButton.Icon
Windows.UI.Xaml.Controls.MenuFlyoutItem.Icon
Windows.UI.Xaml.Controls.MenuFlyoutSubItem.Icon
Windows.UI.Xaml.Controls.NavigationViewItem.Icon
Windows.UI.Xaml.Controls.Primitives.NavigationViewItemPresenter.Icon
Windows.UI.Xaml.Controls.SettingsFlyout.IconSource (uses ImageSource not IconSource)

Already up-to-date:

Windows.UI.Xaml.Controls.SwipeItem.IconSource
Windows.UI.Xaml.Input.XamlUICommand.IconSource

Icons in "Visual Assets" in manifest
On the topic of icons, unfortunately I also had a disappointing experience when configuring the icons in the "Visual Assets" tab in the "Package.appxmanifest" of a WinUI UWP app in Visual Studio 2019.
Lack of knowledge of runtime image scaling
The current design of "Visual Assets" represents a surprising lack of knowledge of the commonly-known fact that at runtime an image can be quickly and easily rendered at a smaller or larger size -- scaled to fit any rectangle.  This rendering-with-scaling is quick regardless of whether the app is running in a smartphone or desktop computer.  When the image is rendered at exactly 50% or 25% size, the scaling is even faster and delivers excellent image quality.  Here is a screenshot of the current GUI for "Large Tile":

As you can see above, it recommends that the app developer provide 3 sizes of the same image, plus 2 optional sizes (up to 5 sizes of the same image).  Thus it represents lack of knowledge of the fact that only one image file is required for "Large Tile" because the image can be scaled at runtime.
As I mentioned, the quality and speed is especially good when the rendered size is 50% or 25% of original.  As you can see in the screenshot above, the 3 recommended sizes are 1240, 620, and 310 and those are multiples of 310.  50% of 1240 is 620, and 25% of 1240 is 310.  Thus if only one image is provided, and if that one image is 1240x1240 px, then the 620 and 310 versions can be rendered at runtime with excellent image quality and speed, even better than if they weren't multiples.  The current GUI for configuring "Large Tile" (with 5 sizes of the same image) is nonsense.
"Scaling Mode" option makes no sense
This lack of knowledge of image scaling is further evident in the "Scaling Mode" option that provides 2 choices named:

"Bicubic (Sharper Edges)"
"Nearest Neighbor (Smoother Edges)"

Both of those descriptions are wrong.  For "Nearest Neighbor", it says "Smoother Edges", but Adobe Photoshop says the opposite:  "Nearest Neighbor (preserve hard edges)".  Visual Studio says the opposite of both Photoshop and Wikipedia.  Wikipedia says "Nearest-neighbor ... introduce jaggedness in previously smooth images."
Not only are the descriptions wrong, but Visual Studio's "Scaling Mode" option shouldn't exist at all, because "Nearest Neighbor" never produces a better result than bicubic scaling (for the purpose of Visual Studio).  Furthermore, the scaling should be performed at runtime, not in Visual Studio, meaning only one image file should be provided for "Large Tile".  Thus the "Scaling Mode" option should be removed from "Visual Assets".
Word wrapping is broken
Another problem is word wrapping.  In the section titled "Display Settings", you can enter a name in the textbox "Short name" and you can tick "Show name", but when the tile is displayed in the Start menu, the name fails to wrap onto 2 lines, despite the fact that other Microsoft products somehow do achieve 2 lines.  For example, MS Blend displays as:

In your own app, if you set "Display Settings" to "Blend for Visual Studio 2019", then it appears with only one line, truncated:

Nonsense file names
For "Small Tile", the default file name is "SmallTile.png" and that makes sense.  Likewise for "Large Tile", the default file name is "LargeTile.png" and again that makes sense.  Now what do you think the file name is for "Medium Tile"?  A sensible guess would be "MediumTile.png", but no, the name is "Square150x150Logo.png", even when the PNG file is not 150x150 pixels.  That's nonsense.
The problem repeats itself for "App Icon".  What do you think the file name is for "App Icon"?   A sensible guess would be "AppIcon.png", but no, the name is "Square44x44Logo.png", even when the PNG file is not 44x44 pixels.  Likewise for "Wide Tile", you'd expect "WideTile.png", but no, the name is "Assets\Wide310x150Logo.png".  The file name says "Logo" instead of "Tile", and it says 310x150 even when the PNG file is not 310x150 pixels.
A file named "Wide310x150Logo.scale-200.png" is not 310x150 pixels.  It's actually 620 x 300 pixels.  The file name includes the text "scale-200" but that's ridiculous, as I explained previously in regards to runtime image scaling and 50% and 25%.
When you click any asset within the "Large Tile" section, such as when you click 620x620 px, a window appears and describes the asset incorrectly.  It says the wrong name and wrong size.  Instead of saying "Large Tile 620x620", it says "Square 310x310 logo".  It says:  "This asset is used for the Square 310x310 logo field and is shown in the following location(s)."  The underlying XML schema says "Square310x310Logo" but unfortunately that design is nonsense.
Other problems in "Visual Assets"

The "Visual Assets" GUI fails to provide any way to delete an unwanted asset or scale.
When you click the 1240 x 1240 large tile, it displays the image in a window but the window has no scrollbars and the window is so large that the "Close" button is offscreen, despite the fact that my computer has a relatively large monitor attached.
Too many assets are recommended.  For example, in the "Wide Tile" section, 3 assets are recommended, but nothing should be recommended by default in Wide Tile.  "Wide Tile" can be supported but it's hardly a good recommendation.  Except for games, none of the Microsoft apps use the "Wide Tile" visual asset.  The Microsoft Weather app does not use it either.  Weather supports wide tiles via live tile, NOT via a Visual Asset.
By default, the "Asset Generator" auto-generates images for "App Icon" and tiles, but it strangely also generates an image for the splashscreen, despite the fact that it makes no sense to display an icon as a splashscreen.
"Apply recommended padding" would be more useful if it allowed the app developer to choose an amount of padding, instead of using the "recommended" amount that doesn't work well for all icons/tiles.
When you click "Large Tile" on the lefthand side, you expect it to show the settings for "Large Tile", but it also shows some settings that affect "Medium Tile" and "Wide Tile" (the settings in the "Display Settings" section).

On a few occasions in the past, I produced amateurish work, but I'm proud to say that I revisited my work and transformed it from amateurish to professional, and the customers loved receiving the improvements.  Everyone produces amateurish work sometimes.  The current version of "Visual Assets" is one of these examples of things that need to be transformed from amateurish to professional.
Here is a screenshot of the files that Visual Studio 2019 produces when you auto-generate every image in "Visual Assets".  A fair and accurate description of this behavior is:  Amateurish.   The file list is not long because it's advanced and powerful.  In reality, the list is long because it's amateurish work and falls far below the usual high standards of UWP.  Many things in UWP are advanced and powerful and wonderful, but "Visual Assets" is not yet one of them.

Microsoft has experienced some difficulties in convincing app developers to develop for Windows Phone instead of (or in addition to) Android and Apple iOS.   One factor to keep in mind is the effect of first impressions.  First impressions count.   When an app developer used other products in the past, and one day uses Visual Studio for the first time, what will his/her first impression be?
The first impression when seeing "Visual Assets" is that Microsoft seems amateurish, and then the app developer begins to wonder:  "If Microsoft couldn't even manage to do the app icon/tile, then what's the rest of UWP like?  Is the whole thing amateurish?"
In reality, UWP is really great stuff -- UWP is advanced and professional -- but app developers can be misled by the bad first impression of "Visual Assets".  What happens next?  App developers swallow the amateurish "Visual Assets" and then start writing an app and they try to create some icons inside of their app, and then they discover that WinUI's icon rendering badly broken, and the first impression deteriorates further.  This is a sad result because in reality many things in WinUI and UWP are wonderful, but the first impressions (icons) can mislead developers into thinking that UWP is low quality.

I struggled with that form too. I was trying to figure out the unplated/plated/light mode/dark mode rules and this form was no help. It is a very unintuitive “tool”.

@moshegutman -- Oh yes, "unplated" is another problem; thanks for reminding me.  I can explain "unplated".  Surprisingly, the newly-invented term/jargon "unplated icon" means "a normal icon" in the normal sense of the word "icon".
This raises the question:  If "unplated icon" just simply means a normal icon, then why not speak normally and just simply say "icon" instead of confusing everyone by inventing a new term that means the same as the preexisting word "icon"?
I can think of two possible answers to this perplexing question.  I'm pretty sure that the answer is one of these:

An honest mistake; or
The same as the reason why lawyers and judges invented a bunch of legal jargon:  Because it sounds impressive and intelligent to use jargon, and it separates "insiders" from "outsiders".  In reality, the use of obscure legal jargon (or tax jargon) represents juvenile behavior, but it sounds intelligent and it impresses people, and that's why lawyers, judges, and accountants use it, despite the juvenile and unprofessional nature of such behavior.  I wish they would just grow up, but unfortunately it's not going to happen.

In the case of the "unplated" jargon, I think the answer is probably number 1, an honest mistake.  In various other cases in life, the answer is number 2.

Yeah, I think it goes back to the windows phone says where the tile background in the start menu is the “plate” that the icon is on. But either way, through Visual Studio it isn’t possible to make all the variations of icons needed for a proper app.

I suspect that the Visual Assets recommendations will be changing with WinUI 3.0 - because of the new icon styles used by Windows 10 X

Here are a few more things that are unfortunately bungled in "Visual Assets".
Firstly, imagine that I wrote an app and in my app there is a place to choose a color for some purpose.  However, instead of using something like ColorPicker, I use TextBox and require the user to type in a hexadecimal RGB color.  It would be accurate to describe that part of my app as amateurish.  As a matter of fact, I really did that once, in a real app, but later I improved it and eliminated my amateurish work.  I'd expect the same to be done for "Visual Assets" -- fix it.  In the following screenshot, I've circled the part of "Visual Assets" that has the amateurish way of choosing colors:

More is bungled.  The following screenshot shows the default setting of "Tile background" -- "transparent".  When "Tile background" is "transparent", the tile background is opaque!  Yes, in this case, "Visual Assets" uses the word "transparent" to mean "opaque".  How can you configure it to be truly transparent?  You cannot.  It's always opaque.  I have no complaint about it being always opaque, but if it's always opaque, then it shouldn't say transparent.  "Visual Assets" uses the word "transparent" to mean "non-transparent default tile background color".

@mdtauk wrote:

I suspect that the Visual Assets recommendations will be changing with WinUI 3.0 - because of the new icon styles used by Windows 10 X

I haven't looked at 10X, but do you mean the "Windows Light Theme"?  If yes, then this is already in Visual Studio 2019 -- see the icons called "Light Unplated Target" in the "App Icon" section of "Visual Assets".
In the "Asset Generator" section, the option "Apply color conversion for Windows Light Theme" seems to be badly broken, or at least it didn't work with the icons I tested it with.  I didn't have time to perform a comprehensive test with many icons, but I did test the main feature that should work:  I tested with an icon that has a light gray border meaning it is intended for use on a dark background.  This means that for the "Windows Light Theme", the light version of the icon needs the light gray border to be changed to a dark gray border, but "Apply color conversion for Windows Light Theme" completely failed to do this.  It did make a modification to the icon, but it was a weird pixelated modification that didn't appear to be even remotely successful.
Not often, but occasionally Microsoft does attempt impossibly difficult tasks -- tasks that are far too difficult to achieve, even for a company as large as Microsoft.  My impression of "Apply color conversion for Windows Light Theme" is that it seems to be one of these few cases where Microsoft attempts an impossibly difficult task.  Therefore I think that Microsoft shouldn't attempt to repair this option, rather Microsoft should remove it entirely, because Microsoft does not possess sufficient resources to achieve impossibly difficult tasks.
Alternatively, if it won't be removed, then give it a completely different name such that it will no longer be an impossibly difficult task.
I gave this issue the title "An Iconic Disaster" because the current situation for icons really is an iconic disaster.  The icon support is terrible currently.  But overall UWP and WinUI are excellent.  Keep up the good work! :smile:

Unfortunately I still haven't finished the substantial work of documenting the list of defects in "Visual Assets" :frowning_face:
In the following screenshot, you can see that I've set "Tile background" to a blue color, and understandably this blue color is displayed in the previews in the sections "Small Tile", "Medium Tile", "Large Tile".  That part of it behaves correctly.

"Tile background" behaves incorrectly in the "App Icon" section:

You can see in the above screenshot that the first row is labelled "Scaled Assets" but the other 3 rows are missing their labels -- that's a strange inconsistency.  The last 2 rows are the so-called "unplated icons" meaning actually "normal icons" that don't have a plate/tile.  Confusingly, Visual Assets uses multiple different words for the same things, thus plate = tile, and unplated = non-tile.  As you can see above, the non-tile icons (the last 2 rows) are incorrectly rendered with the blue tile background.  Obviously that's a mistake because non-tile icons shouldn't be rendered as tiles, thus the color specified in the "Tile background" textbox shouldn't be rendered under the non-tile ("unplated") icons, but it is.
If you click on any of the unplated icons, it displays a window like the following, and you can see it says the icon is used in Windows Explorer etc, but NOT used as a tile.   The "Tile background" color is incorrectly rendered in the preview despite the fact that it isn't a tile.

A few other defects are also visible in the above window, such as the wrong name ("Square 44x44 Logo"), and also the fact that it doesn't say "unplated" in this window despite the fact that I clicked on an icon that did say "unplated".
To summarize, the defects in the "App Icon" section include these:

The "Tile background" color is incorrectly rendered underneath non-tile ("unplated") icons (the last 2 rows).
The purpose of each row is only displayed for the first row (the first row is labelled "Scaled Assets" but the other rows are unlabelled).  For the remaining 3 rows, the purpose is displayed only in a tooltip when the mouse pauses above one of the previews.  That's inconsistent and bad GUI design.
Lack of knowledge that images can be scaled at runtime.  The 176x176 size is ridiculous.  The following image sizes should be removed because they should be scaled at runtime from the 256x256 image:  176x176, 88x88, 66x66, 55x55, 48x48, 44x44.
The 16x16 size is ridiculous and should be removed.  We're not living in the 1990's anymore.  Nowadays computer and smartphone screen resolutions are much higher than in 1995, thus the tiny 16x16 size is ridiculous considering that 1995 was 25 years ago.  As for the 32x32 size, it could be retained (an exception could be made for this small size) because it is so small that runtime scaling may produce an unsatisfactory result (when 256x256 is scaled to 32x32).  Re 16x16, the need to render the icon at 16x16 size is unlikely but if it happens, then at runtime the 32x32 icon can be scaled to 16x16.
When using "Asset Generator" with default/recommended settings (when "Recommended Scales" is ticked), it auto-generates three 16x16 image files.  This behavior makes no sense.  It's completely illogical.  If 16x16 is an auto-generated image, then there is no need to supply it.  It's only logical to supply a 16x16 image if it is manually created by a graphic designer person who specially tweaks/adjusts it in order to make its appearance acceptable at such a tiny size.  Thus it can be justifiable to supply multiple image sizes if they're manually created/tweaked images, whereas it's nonsense if they're auto-generated by "Asset Generator" because if they're auto-generated then they can be scaled at runtime.
It doesn't provide any way to delete one of the images within the "App Icon" section.  For example, it doesn't allow you to click or right-click 44x44 and then click a "Delete" button or command.
The preview for 256x256 is rendered smaller than the preview for 176x176. That's the reverse of what you'd expect, considering that 256x256 is actually larger than 176x176.  Various other previews also exhibit strange sizes.
The "App Icon" section uses absurd file names such as "Square44x44Logo.targetsize-256.png".  The default file name for the "App Icon" section is expected to be "AppIcon.png" like how the "Small Tile" section uses "SmallTile.png".  However, "App Icon" uses a nonsensical file name: "Square44x44Logo-XXXXXX.png".  The name is especially nonsensical because it generates multiple variations of "Square44x44Logo-XXXXXX.png" (such as "Square44x44Logo.targetsize-256.png") that all say "44x44" despite the fact that most of these PNG files are NOT 44x44 pixels.
It uses multiple different names for the same things.  "Unplated icon" = a normal icon.  "Plate" = tile.  "Square44x44Logo.png" = "App Icon".  And others.

Icons and tiles for an app should be a simple issue.  It shouldn't require a PhD to understand it.  It shouldn't require hours of deciphering.  It shouldn't require the following ridiculous translation table.

Term
Meaning

Asset
Image.

Unplated icon
A normal icon in the normal sense of the word "icon".  There was no need to invent a confusing new term for normal icons.

Plate
The same as tile.  A duplicate term for the same thing.

Alternate Form (altform)
Normal form. Unplated form.

Square 44x44 Logo
App Icon.  Although it says 44x44, these images are mostly not 44x44.

Square 71x71 Logo
Small Tile.  Although it says 71x71, these images are mostly not 71x71.

Square 150x150 Logo
Medium Tile.  Although it says 150x150, these images are mostly not 150x150.

Wide 310x150 Logo
Not logo.  Actually means tile, specifically "Wide Tile".  Although it says 310x150, these images are mostly not 310x150.

Square 310x310 Logo
Large Tile.  Although it says 310x310, these images are mostly not 310x310.

Lock Screen Logo
Badge Logo.

Store Logo
Package Logo.

transparent
Non-transparent.  It means opaque default tile background color.

Bicubic (Sharper Edges)
Softer edges.

Nearest Neighbor (Smoother Edges)
Jagged edges.

Scale 100
Does not mean 100%.  It actually means an arbitrarily chosen size such as 150x150 pixels.  For "Medium Tile", the so-called "Scale 100" means 150x150 pixels but no reason exists to explain why an arbitrary size such as 150x150 pixels should be called "100%".  The scaling system of "Visual Assets" is illogical.

Scale 400
The largest image supplied.

Scale 200
An unnecessary useless duplicate of the exact same image as "Scale 400", but scaled to 50% of the image "Scale 400".  Serves no real purpose because normally images are scaled at runtime, not prior to compile-time.  There is no reason to pre-generate multiple sizes of the same image.

Scale 150
Another unnecessary duplicate that serves no real purpose.

Scale 125
Yet another unnecessary duplicate that serves no real purpose.  This image size served a purpose back in the year 1995 because back then it was slow to scale an image at runtime, but that was 25 years ago!   Nowadays we don't need to store many duplicates of the same image.

I've saved the best for last.  Here is the number 1 most absurd thing about the current version of "Visual Assets".  When you use "Asset Generator" with its "Recommended Scales" setting, and you want to use the full tile area thus you untick "Apply recommended padding" (or tick it if you want), and you give it a source tile image of a reasonable size such as 300x300 or whatever, then as I said it generates many unnecessary smaller duplicates of the same image for no reason, but that's not all it does.  Here comes the number 1 most absurd thing:  In the "Large Tile" section, it takes the 300 x 300 source image file and scales it UPWARDS to produce a big blurry 1240 x 1240 PNG file that consumes roughly 1 megabyte on average!!
That upwards scaling to 1240 x 1240 is so absurd that if Mac users knew about this, they'd burst out laughing.  Scaling it downwards is bad enough, but scaling it upwards is just... so... ridiculous.  It's not any exaggeration whatsoever to describe it as absurd.  Mac fanatics will say it's hilarious.  It's even worse than I said because the 1240 x 1240 PNG file isn't the only one.  It's one of multiple upscaled image files.  It also scales up the 300x300 source image to produce PNG files of sizes 310x310, 310x150, 620x620, 620x300, 600x600, and 1240x600.
It's still even worse than I said.  The default setting also includes scaling up the 300x300 image to produce a 2480 x 1200 splashscreen that also consumes roughly 1 megabyte on average.  And a 1240 x 600 splashscreen.  Wait, there's one more:  It also scales upwards to a 620 x 300 splashscreen.
I do realize that the "Scale 400" image files are supposed to correspond with the setting in Start menu / Settings / Display / "Scale and layout", but this reasoning is completely illogical.  It makes no sense whatsoever.  400% doesn't even exist in the ComboBox in "Scale and layout", and even if 400% did exist there, it would still be completely illogical to pre-generate upscaled PNG files.
The behavior of "Visual Assets" is just beyond belief.  It's very unusual for Microsoft to publish something of very low quality, but this time it happened unfortunately.  "Visual Assets" is extraordinarily low quality software.

Instead of fixing all the resolution problems in @verelpode 's posts on visual assets directly, you could just obviate them by making a large simplification.

SVG are by far the most important case, as almost all icons are vector graphics. A single svg file should be usable, with no need to generate or display scaled assets.
To support bitmaps (for backwards compatibility), a single high-res image can be used for each case, and if there is a need to use smaller ones, these can be generated as a release build step. Again there is no need to display scaled assets in the UI. There isn't any need to support manual specification of multiple versions of the same image.

@charlesroddie -- I believe you've described an excellent solution that fits the needs:  A modern design with a good balance between power and simplicity.  Surely nobody will be able to think of a better plan than what you said.
Additionally, the same plan could also be applied to both of "external" icons ("Visual Assets") and "internal" icons displayed within the app, or at least X% of the source code could be shared between the "internal" and "external" icon scenarios when it operates like you described.
For comparison purposes, Android supports SVG icons, although the SVG must be converted first (AFAIK).  Android has a GUI-based tool that converts the source SVG file to Android's own vector format called VectorDrawable.  I think the following items belong in the list of top 10 reasons why Android won the battle between Android versus WinRT/UWP:

vector graphics files,
vector icons,
managed code (Java),
etc.

This is a good opportunity for Microsoft to change some things in order to attract more developers to UWP.

Realized my comment on TabView relates to this discussion as well.

I definitely feel like it'd be useful to split this into multiple scoped issues. There's a lot of great problems pointed out here, but I feel like this is hard to act on as an all-up sink.
I just realized that I can't style an Icon/IconSource, when I get the FontIconSource from the developer's XAML it's fixed at 20 for FontSize, any amount of style I have in my template is ignored and won't inherit or override that FontSize value, even if I call ClearValue on the FontIcon, as that just sets it back to 20...

@verelpode: Just by chance I discovered that a negative margin enables scaling to some extend. See you're code snippet below with this "hack"...

I noticed that when I'm binding to a XamlUICommand, the icon doesn't show up. I don't know if I'm doing something wrong (the last time I programmed with XAML was 15 years ago, in Silverlight at the time, and WinUI is totally new for me atm).
I'm using version 3.0.0-preview3.201113.0
The ViewModel:
private void BindCommands()
{
    this.PickMovieFolder = new XamlUICommand
    {
        IconSource = new SymbolIconSource
        {
            Symbol = Symbol.Folder,
            Foreground = new SolidColorBrush(Color.FromArgb(1, 122, 16, 28))
        },
        Description = "Select a movie folder to add...",
    };
    this.PickMovieFolder.ExecuteRequested += (command, args) =>
    {
        command.DispatcherQueue.TryEnqueue(async () =>
        {
            var folderPicker = new FolderPicker
            {
                SuggestedStartLocation = PickerLocationId.VideosLibrary
            };

            folderPicker.FileTypeFilter.Add("*");

            folderPicker.As<IInitializeWithWindow>().Initialize(Process.GetCurrentProcess().MainWindowHandle);

            var folder = await folderPicker.PickSingleFolderAsync();

            if (folder != null)
            {
                // Do sthg
            }
        });
    };
}

The View:
<Grid Margin="0,12,0,0">
   <Grid.ColumnDefinitions>
       <ColumnDefinition Width="768px" />
       <ColumnDefinition Width="Auto" />
       <ColumnDefinition Width="Auto" />
       <ColumnDefinition Width="Auto" />
   </Grid.ColumnDefinitions>
   <TextBox Grid.Row="0" Grid.Column="0" HorizontalAlignment="Stretch" VerticalAlignment="Center" PlaceholderText="Path to your movie folder (eg: C:\Users\Zeus\Movies)"></TextBox>
   <Button Grid.Row="0" Grid.Column="1" Width="36" Height="32" Margin="-36,0,48,0" BorderThickness="0" CornerRadius="0,1, 1, 0" Command="{Binding Path=PickMovieFolder }" />
   <CheckBox Grid.Row="0" Grid.Column="2" Margin="0,0,12,0" VerticalAlignment="Center">Include subfolders</CheckBox>
   <Button Grid.Row="0" Grid.Column="3" VerticalAlignment="Center">Add folder</Button>
</Grid>

I tried removing the negative margin, but to no effect. When I set the property Label on the XamlUICommand , this shows correctly, only still no icon.

I don't know if I'm at the right place here.

🦙 @brechtb86 probably best as a new issue, especially as it related to WinUI 3, I moved it over for you here: https://github.com/microsoft/microsoft-ui-xaml/issues/4074

🦙 Linking to an older Stack Overflow thread about this same type of issue for reference: https://stackoverflow.com/questions/50458126/how-to-set-appbarbutton-icon-using-svg-file-resource-in-uwp-c

🦙 Linking to most of the other related issues I could find fairly directly related to this topic:

https://github.com/microsoft/microsoft-ui-xaml/issues/507
https://github.com/microsoft/microsoft-ui-xaml/issues/825
https://github.com/microsoft/microsoft-ui-xaml/issues/827
https://github.com/microsoft/microsoft-ui-xaml/issues/1279
https://github.com/microsoft/microsoft-ui-xaml/issues/2495
https://github.com/microsoft/microsoft-ui-xaml/issues/3077 (TLDR: No)
https://github.com/microsoft/microsoft-ui-xaml/issues/3561
https://github.com/microsoft/microsoft-ui-xaml/issues/3666
https://github.com/microsoft/microsoft-ui-xaml/issues/3830
https://github.com/microsoft/microsoft-ui-xaml/issues/3846
https://github.com/microsoft/microsoft-ui-xaml/issues/4741 (maybe duplicate of 3077)
https://github.com/microsoft/microsoft-ui-xaml/issues/5724

It's also important to note that the general platform design guidance here calls out using vector based formats where possible:

There are many ways to create an icon. You can use a symbol font like Segoe MDL2 Assets. You could create your own vector-based image. You can even use a bitmap image, although we don't recommend it. Here's a summary of the different ways you can add an icon to your app.

SVG resources are ideal for icons, because they always look sharp at any size or resolution. Most drawing applications can export to SVG.

More than 3 years later this is still the status quo?

rather an icon is akin to an image or path.

Actually, that's a negative. MDL2 and Fluent Font are called font icons and they are literally that: .ttf fonts

I just started with WinUI3 recently and I can't believe it isn't easy to load an SVG image anywhere you can load a PNG.  I can do it in WinForms with DevExpress controls, for example.  These elements need to scale nicely depending on DPI, why is there little-to-no support for SVGs in things like NavigationViewItems after all this time?


fullTextSearch not working on json fields

Bug description
using the fullTextSearch search on a json field gives a type and runtime error.
How to reproduce

use the fullTextSearch on a text field
Change the field to be a json
run prisma generate
See error

Expected behavior
we can search on json fields
Prisma information

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider      = "prisma-client-js"
  previewFeatures = ["dataProxy", "fullTextSearch"]
  output        = "../../../../node_modules/@prisma/client/ultron"
}

generator dbml {
  provider = "prisma-dbml-generator"
}

Environment & setup

OS: macOS
Database: postgreSQL
Node.js version: v14.17.4

Prisma Version
3.5.0

@JulienDemarque
Can you please share your schema and the prisma client call which is triggering the error? Thanks!

@pantharshit00 here is the part of the schema that is concerned:
model BaseRun {
  id               String @id @default(dbgenerated("uuid_generate_v4()")) @db.Uuid
  processId        String @map("process_id") @db.Uuid
  companyProcessId String @map("company_process_id") @db.Uuid
  baseId           String @map("base_id") @db.Uuid
  baseEntity       Json   @map("base_entity")
  /// Not a database id, but something that comes from the base entity itself
  baseEntityId     String @map("base_entity_id")

  /// Automatically set based on SLA in company's config
  deadline DateTime? @db.Timestamptz(3)

  /// milliseconds
  benchmark Int?

  snoozeUntil DateTime? @map("snooze_until") @db.Timestamptz(3)

  variables Json?
  ...

the prisma client call:
   const searchVariableFragment = input.search
        ? {
            variables: {
              search: input.search,
            },
          }
        : {}
    const items = await prisma.baseRun.findMany({
          where: {
            baseId: input.baseId,
            ...searchVariableFragment,
          },
          skip: input.cursor,
          take: input.take,
          orderBy: {
            deadline: (input.sort?.deadline ||
              input.sort?.timeleft ||
              undefined) as Prisma.SortOrder | undefined,
          },
        })

the type error in the screenshot:

Ryan answered me on slack that there is already an issue opened for this: https://github.com/prisma/prisma/issues/8835