"..as designed". Yes, their design is broken :-).
Grid: All your items must specify absolute row/column indices. When you add row/column, you have to adjust all those row/column indices +1. And manage Row/ColumnDefinitions. The 16G computer should manage all that.
StackPanel: It assumes children have known static sizes.
You can't specify "2 children with 50% space each".
Thus a downgrade from hbox/vbox layouts we've had since 1989 :-(.
Because of this, most of my layouts are a weird mix of DockPanel, StackPanel and Grid (not because I want DockPanel, but because it's less broken than the other two.)
How would you set up default spacing/margins app-wide? I can't see how you would do that, without at the same time adhering to some custom "magic" rules, in your xaml instances, to cooperate with your app-wide settings?
IE normally you end up with weird mix of "margin at 10px", but then have 0 margin on some sides, for first/last item.
Shortcuts are not a "specific scenario".
The shortcut in question is closing a dialog, where your OK button has IsDefault="True".
In that case, the value in user's current edit field is not transferred, unless you as a programmer address it. Apple had this issue handled in 1994 :-/. Microsoft in 2007 believes programmers love dealing with stuff like that.(e.g. UpdateSourceTrigger=OnPropertyChanged will solve some cases.. Hooray, I really love having to type UpdateSourceTrigger=OnPropertyChanged.. Well no I don't).
I'm not asking for fixed default spacings, I'm asking for a well-designed mechanism to handle margins and spacing, app-wide, without having to specify alternating "0 pixels above, 10 pixels below" on random buttons to make things fit.
An funny example is StackPanel missing an items-Spacing property. The funny thing is, it actually has this setting.. But it was only added in 2017 (after 10+ years?), and available in some SDK preview that I have never managed to find in either my VS2017 or VS2019.
I forgot to mention ways in which DataGrid is broken.
On paper, it seems great. But in practice, the implementation of things like DataGridComboBoxColumn means it only works for toy examples.
If your tables have 20 rows and 3 columns, DataGrid with DataGridComboBoxColumn seems fantastic.
But we don't have 20 rows and 3 columns, do we?
No wait, we have 30-40 columns, and 900 rows..
And then you find out that DataGridComboBoxColumn performs like a dead dog/kicking a whale down the beach,
because some genius at microsoft thought it a good idea to look up the display value for each cell dynamically in the combobox itemsSource, FOR EACH CELL IT HAS TO RENDER.
And then you get a head-ache, because you remember programming the same things back in 1995 and 2003 and 2007 and 2009 with Qt/MFC/Delphi/Swing(yes, swing..), and having them perform well, and wonder why
this is suddenly not possible in 2020.
There are solutions to many of the problems in 3rd-party, e.g. Caliburn, but I don't want to have to use 3rd-party fixes for things that should be in the core package, in 2020 (and 2007, or whenever they did WPF.)
Another thing: WPF not throwing exceptions (or silently catching them, whatever you call it.)
I'm very much not a fan of this. As far as I can see, it just means programmers are ignoring and/or inaware of and not fixing, a million bugs in their GUI code.
If you don't believe me, try running Autodesk's monopoly building design tool Revit. Parts of it is written in WPF.
You can tell that, because if you run Revit from within Visual Studio,
the Immediate diagnostics Window is scrolling full with all the errors that Autodesk's programmers choose to ignore. Which is real helpful, when you are trying to find the messages YOUR program outputs in the same window :-/.