3 ms·

I have to work with WPF on a daily basis. What a nightmare, and how I miss working with Qt. I wish the people responsible for WPF were forced to use it for the

I have to work with WPF on a daily basis. What a nightmare, and how I miss working with Qt. I wish the people responsible for WPF were forced to use it for the rest of their lives. The grid layout is broken. The stackpanel is broken. There are no sane defaults for anything. You can rotate any control - WHY? Default stackpanel has no control spacing. WPF code throws no exceptions. Bound comboboxes in datagrids have the performance of glaciers. Keyboard shortcuts trigger the decades-old 'edit field contents only transfer on killfocus' bug. Parent-windows and always-on-top is a mess. Live dom is different from your static hierarchy. I've waited for fixes to the WPF mess since.. 2007? I sense WinUI isn't it.

lostmsu 7y ago
I am not heavy on UI development, but most of my experiences with WPF were pretty good. In what ways grid and stackpanel are broken? They seem to perform exactly as designed (though I only have CSS to compare to, but it is magnitudes worse). The fact, that core controls have no default spacing seems like a sane engineering decision, considering you can set it app-wide with a few lines of XAML. Shortcuts sound like a problem for a specific scenario. The default binding update on lost focus might have been a bad decision, but even given my little experience I remember it quite well.
- The_rationalist 7y ago
  Why CSS is magnitudes worse?
  - IshKebab 7y ago
    I have no idea about WPF but CSS was really designed as a document styling system. It isn't very good as an app styling system: There's no scoping so it's really hard to know which bits of an app any CSS affects, and really hard to find all the CSS that affects a particular part of an app. It mixes styling (colours etc) with layout (flexbox). Etc.
    - The_rationalist 7y ago
      There's no scoping so it's really hard to know which bits of an app any CSS affects Shadow dom and css modules say hi really hard to find all the CSS that affects a particular part of an app Devtools show which selector from which file affect which element. It mixes styling (colours etc) with layout (flexbox). Yes, why not? :)
- fifticon 7y ago
  "..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 :-/.
- fifticon 7y ago
  To clarify on the "app-wide layout". You can specify things like "OK, let's have a 10px margin around the outer containers". But that doesn't really help you specifying the internal spacings _between_ items. You end up having to do lots of one-off adjustments, with the first or last button/panel. I don't want to spend my time messing with all that, it's trivial and boring, it should be something solved in a single place, once. After that, I just want to add "semantic" controls to my interfaces/screens, and have the application-wide layout rules make sure it's laid out nicely in the same way. When I look for solutions to that, I end up with useless "guides" like this: https://www.wpf-tutorial.com/styles/using-styles/ https://www.wpf-tutorial.com/styles/using-styles/
- fifticon 7y ago
  After my rant day, here examples from my work day: I need to lay out two data-tables in a dialog, with 50% to each. I also need label headers above each section. The tables must grow and share available space, the labels stay put. In WPF, this 'daily driver' task, requires this: - it can't be solved with DockPanel (which is OK.) - it can't be solved with hbox(StackPanel), because of StackPanel's broken design (ie not handling resizing children.) - so I'm forced to use Grid.. Which, for this trivial task, requires this: <Grid Margin="0,10,0,10"> <Grid.ColumnDefinitions> <ColumnDefinition Width="*"/> <ColumnDefinition Width="*"/> </Grid.ColumnDefinitions> <Grid.RowDefinitions> <RowDefinition Height="30"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> And then, on each of my 4 children, I have to put these: ..Grid.Column="1" Grid.Row="1" What a bloated inelegant mess. I don't want to specify absolute indices on my grid children, I want it handled by nesting or symbolic row identifiers (anything where I don't have to count/update row/column indices by hand.) I'm not happy, that the layout rules for grids have their own "", "number", "number", "number%" system independent of the hor/vert alignment system. I don't want to specify an absolute height on my label row.
pjmlp 7y ago
WPF, broken?!? I had the pleasure to work it during 5 years. Qt is also no walk into the park with multiple iterations of the UI scripting language, unclear roadmap of QML vs C++ based widgets, bugs left years unfixed for mobile platforms since they decided to pivot into IoT (aka Devices), the whole non standard C++ macros, and several other issues.
leeman2016 7y ago
Strange. I had mostly pleasant experience with WPF. In fact, back in the early days it was so exciting to work with.

lostmsu 7y ago

I am not heavy on UI development, but most of my experiences with WPF were pretty good. In what ways grid and stackpanel are broken? They seem to perform exactly as designed (though I only have CSS to compare to, but it is magnitudes worse). The fact, that core controls have no default spacing seems like a sane engineering decision, considering you can set it app-wide with a few lines of XAML. Shortcuts sound like a problem for a specific scenario. The default binding update on lost focus might have been a bad decision, but even given my little experience I remember it quite well.

The_rationalist 7y ago
Why CSS is magnitudes worse?
- IshKebab 7y ago
  I have no idea about WPF but CSS was really designed as a document styling system. It isn't very good as an app styling system: There's no scoping so it's really hard to know which bits of an app any CSS affects, and really hard to find all the CSS that affects a particular part of an app. It mixes styling (colours etc) with layout (flexbox). Etc.
  - The_rationalist 7y ago
    There's no scoping so it's really hard to know which bits of an app any CSS affects Shadow dom and css modules say hi really hard to find all the CSS that affects a particular part of an app Devtools show which selector from which file affect which element. It mixes styling (colours etc) with layout (flexbox). Yes, why not? :)
fifticon 7y ago
"..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 :-/.
fifticon 7y ago
To clarify on the "app-wide layout". You can specify things like "OK, let's have a 10px margin around the outer containers". But that doesn't really help you specifying the internal spacings _between_ items. You end up having to do lots of one-off adjustments, with the first or last button/panel. I don't want to spend my time messing with all that, it's trivial and boring, it should be something solved in a single place, once. After that, I just want to add "semantic" controls to my interfaces/screens, and have the application-wide layout rules make sure it's laid out nicely in the same way. When I look for solutions to that, I end up with useless "guides" like this: https://www.wpf-tutorial.com/styles/using-styles/ https://www.wpf-tutorial.com/styles/using-styles/
fifticon 7y ago
After my rant day, here examples from my work day: I need to lay out two data-tables in a dialog, with 50% to each. I also need label headers above each section. The tables must grow and share available space, the labels stay put. In WPF, this 'daily driver' task, requires this: - it can't be solved with DockPanel (which is OK.) - it can't be solved with hbox(StackPanel), because of StackPanel's broken design (ie not handling resizing children.) - so I'm forced to use Grid.. Which, for this trivial task, requires this: <Grid Margin="0,10,0,10"> <Grid.ColumnDefinitions> <ColumnDefinition Width="*"/> <ColumnDefinition Width="*"/> </Grid.ColumnDefinitions> <Grid.RowDefinitions> <RowDefinition Height="30"/> <RowDefinition Height="*"/> </Grid.RowDefinitions> And then, on each of my 4 children, I have to put these: ..Grid.Column="1" Grid.Row="1" What a bloated inelegant mess. I don't want to specify absolute indices on my grid children, I want it handled by nesting or symbolic row identifiers (anything where I don't have to count/update row/column indices by hand.) I'm not happy, that the layout rules for grids have their own "", "number", "number", "number%" system independent of the hor/vert alignment system. I don't want to specify an absolute height on my label row.

pjmlp 7y ago

WPF, broken?!? I had the pleasure to work it during 5 years. Qt is also no walk into the park with multiple iterations of the UI scripting language, unclear roadmap of QML vs C++ based widgets, bugs left years unfixed for mobile platforms since they decided to pivot into IoT (aka Devices), the whole non standard C++ macros, and several other issues.

leeman2016 7y ago

Strange. I had mostly pleasant experience with WPF. In fact, back in the early days it was so exciting to work with.