Anyway. I installed it and just at the start i notice something i really dislike: they slide a panel of text and the sliding is slow (in terms of sliding speed, not performance) and done in a subpixel manner, making all the text blurry and unreadable until the sliding finishes.
Also i noticed a bug in the "AutomationProperties" demo (second one) - if i use the wheel to change the size (no indication about being able to do that btw, unlike spinboxes in Win32) and i also have the "page" scrolled, both the page is scrolled and the value is changes.
In general scrolling seems to be broken - if i use the wheel to scroll, the page scrolls normally until a code block with a horizontal scrollbar enters into view at which point scrolling only scrolls the code view horizontally. Now i might be wrong but i do not think the mouse wheel should scroll a widget horizontally (this is what the horizontal wheel scrolling - that is wheel tilting - is for) and even if it does, it should only be done when the widget is not inside a scrollable container. Because as it is right now, i have to move my pointer to a "safe" area outside the code box to keep scrolling the page. Also regardless of horizontal or vertical scrolling, IMO if you reach the end of the scrolled area in a widget that is itself inside a scrolling area, then the outer widget should continue scrolling.
Finally on scrolling, the scrollbars do not seem to respect the shift+scroll behavior (normally clicking on the tray above/below the scrollbar thumb moves a page up/down, but if you shift+click it moves the thumb at the position you clicked like middle clicking in most X11 toolkits - however this doesn't happen in the demo).
Another thing (not a bug), i mentioned above that there isn't any indicator like a Win32 spinbox, but in the NumberBox demo there is a spinbox - and if you focus it, the spin buttons become enormous wasting almost half of the spinbox's editable area. Also - and this is a bug - if you click just left of the spin buttons before they become enormous, the big ones appear and then disappear immediately and the spinbox loses focus.
Funny enough, this is the "compact" configuration for the spinbox, although i guess it makes sense since the "inline" one (the alternative configuration) is even bigger. But at least it doesn't change size nor loses focus arbitrarily. Ideally it should be the "compact" one without changing size or focus unless you used touch input. Windows can differentiate between mouse and touch input, why doesn't Microsoft take advantage of this?
Another mouse wheel issue, now with the RadialGradientBrush sample (i'm testing those in succession)... the sliders do not respond to mouse wheel events meaning i can't change them with the wheel. However i'm not sure if it s the slider not understanding the wheel events or something else because the wheel behavior is weird in the panel there: if i click somewhere in the page outside of any panel (e.g. at the "Paints an area... blahblah" text at the top) and use the wheel over the MappingMode combo box, the values in the box change. But if instead of the MappingMode combo box i use the wheel over the SpreadMethod (that is, i click on the text at the top and then use the wheel over the SpreadMethod as the immediate next thing), then the page scrolls. However if i click on the SpreadMethod combo box and then use the wheel on it, the values in the combo box change (as expected) instead of scrolling. Note that i didn't have to click the MappingMode combo box for it to use the wheel. Also the slider does not change with the wheel regardless of me clicking it or not.
Another visual glitch, in the TabView demo: if you close the tabs and they remaining tabs do not fill the TabView line, the tabs line doesn't fill the entire width but gets shrunk to seemlingly random sizes. Note that if you close all but one tab but then you create a new one, the tabs line does fill the entire width. Also, if you close all tabs and open a new tab, none of the tabs are active and the content area remains empty. This might be intentional, but i doubt it since you can't "select no tabs".
Another bit of weirdness, with the TeachingTip demo: clicking the "Show Teaching Tip" button shows that teaching tip (i guess this is the new name for tooltip?) normally, but if you try to close it, it doesn't respond to mouse events (click, hover, anything) if it is at the area at the top of the window where the titlebar would be (and also that area doesn't seem to respect the system settings for its size - i have changed the setting in the registry to use a smaller area because i find the default titlebar size huge, but this demo ignores that setting). This means that i can only click the "X" button to close it from the middle and below. Even more weird, there is a small patch of pixels at the top left side of the button that accept mouse input... perhaps there is a hardcoded area at the top right of the window in case a window has all titlebar buttons visible (minimize, maximize, close and context help)?
A minor visual issue, the "three-state" AppBarToggleButton uses a background color shade to indicate its state. However the third state (neither checked nor unchecked) looks 99% the same on my PC where i use a gray "accent". Using an image editor i see the checked state uses an RGB value of 63, 63, 63 and the in-between state uses an RGB value of 57, 57, 57. On my PC they practically look the same.
At this point i lost interest, pretty much every single demo has some issues (except the AppBarButton, but if you can't even get a single rectangle to respond to clicks i'm not sure why you'd even bother working on UIs). I noticed a glitch in the menu bar demo (e.g. if i scroll the page and press space, the file menu opens... outside of the window) but i do not feel like investigating more or trying anything else.
Yeah, sure, i guess this demo did its job perfectly fine: it showed me why i'm good with sticking with Win32 :-P
Anyway. I installed it and just at the start i notice something i really dislike: they slide a panel of text and the sliding is slow (in terms of sliding speed, not performance) and done in a subpixel manner, making all the text blurry and unreadable until the sliding finishes.
Also i noticed a bug in the "AutomationProperties" demo (second one) - if i use the wheel to change the size (no indication about being able to do that btw, unlike spinboxes in Win32) and i also have the "page" scrolled, both the page is scrolled and the value is changes.
In general scrolling seems to be broken - if i use the wheel to scroll, the page scrolls normally until a code block with a horizontal scrollbar enters into view at which point scrolling only scrolls the code view horizontally. Now i might be wrong but i do not think the mouse wheel should scroll a widget horizontally (this is what the horizontal wheel scrolling - that is wheel tilting - is for) and even if it does, it should only be done when the widget is not inside a scrollable container. Because as it is right now, i have to move my pointer to a "safe" area outside the code box to keep scrolling the page. Also regardless of horizontal or vertical scrolling, IMO if you reach the end of the scrolled area in a widget that is itself inside a scrolling area, then the outer widget should continue scrolling.
Finally on scrolling, the scrollbars do not seem to respect the shift+scroll behavior (normally clicking on the tray above/below the scrollbar thumb moves a page up/down, but if you shift+click it moves the thumb at the position you clicked like middle clicking in most X11 toolkits - however this doesn't happen in the demo).
Another thing (not a bug), i mentioned above that there isn't any indicator like a Win32 spinbox, but in the NumberBox demo there is a spinbox - and if you focus it, the spin buttons become enormous wasting almost half of the spinbox's editable area. Also - and this is a bug - if you click just left of the spin buttons before they become enormous, the big ones appear and then disappear immediately and the spinbox loses focus.
Funny enough, this is the "compact" configuration for the spinbox, although i guess it makes sense since the "inline" one (the alternative configuration) is even bigger. But at least it doesn't change size nor loses focus arbitrarily. Ideally it should be the "compact" one without changing size or focus unless you used touch input. Windows can differentiate between mouse and touch input, why doesn't Microsoft take advantage of this?
Another mouse wheel issue, now with the RadialGradientBrush sample (i'm testing those in succession)... the sliders do not respond to mouse wheel events meaning i can't change them with the wheel. However i'm not sure if it s the slider not understanding the wheel events or something else because the wheel behavior is weird in the panel there: if i click somewhere in the page outside of any panel (e.g. at the "Paints an area... blahblah" text at the top) and use the wheel over the MappingMode combo box, the values in the box change. But if instead of the MappingMode combo box i use the wheel over the SpreadMethod (that is, i click on the text at the top and then use the wheel over the SpreadMethod as the immediate next thing), then the page scrolls. However if i click on the SpreadMethod combo box and then use the wheel on it, the values in the combo box change (as expected) instead of scrolling. Note that i didn't have to click the MappingMode combo box for it to use the wheel. Also the slider does not change with the wheel regardless of me clicking it or not.
Another visual glitch, in the TabView demo: if you close the tabs and they remaining tabs do not fill the TabView line, the tabs line doesn't fill the entire width but gets shrunk to seemlingly random sizes. Note that if you close all but one tab but then you create a new one, the tabs line does fill the entire width. Also, if you close all tabs and open a new tab, none of the tabs are active and the content area remains empty. This might be intentional, but i doubt it since you can't "select no tabs".
Another bit of weirdness, with the TeachingTip demo: clicking the "Show Teaching Tip" button shows that teaching tip (i guess this is the new name for tooltip?) normally, but if you try to close it, it doesn't respond to mouse events (click, hover, anything) if it is at the area at the top of the window where the titlebar would be (and also that area doesn't seem to respect the system settings for its size - i have changed the setting in the registry to use a smaller area because i find the default titlebar size huge, but this demo ignores that setting). This means that i can only click the "X" button to close it from the middle and below. Even more weird, there is a small patch of pixels at the top left side of the button that accept mouse input... perhaps there is a hardcoded area at the top right of the window in case a window has all titlebar buttons visible (minimize, maximize, close and context help)?
A minor visual issue, the "three-state" AppBarToggleButton uses a background color shade to indicate its state. However the third state (neither checked nor unchecked) looks 99% the same on my PC where i use a gray "accent". Using an image editor i see the checked state uses an RGB value of 63, 63, 63 and the in-between state uses an RGB value of 57, 57, 57. On my PC they practically look the same.
At this point i lost interest, pretty much every single demo has some issues (except the AppBarButton, but if you can't even get a single rectangle to respond to clicks i'm not sure why you'd even bother working on UIs). I noticed a glitch in the menu bar demo (e.g. if i scroll the page and press space, the file menu opens... outside of the window) but i do not feel like investigating more or trying anything else.
Yeah, sure, i guess this demo did its job perfectly fine: it showed me why i'm good with sticking with Win32 :-P