@TexasToast: And evidently you didn't hear, Microsoft Research was reformed recently in order to better focus on company goals. The division was producing good research, but with little visibility into the direction the company was heading. This led to good research that often didn't produce marketable products.
@Bass: The equivalent in XAML would be:
<Style TargetType="TextBox"> <Style.Triggers> <Trigger Property="IsMouseOver" Value="True"> <Setter Property="BitmapEffect"> <Setter.Value> <DropShadowBitmapEffect /> </Setter.Value> </Setter> </Trigger> </Style.Triggers> </Style>
which is among several reasons I don't like XML as a UI language.
Still, back to the original argument, it's not like this is complex. It is verbose... big difference. Adaptive UI is easier than this, and certainly no harder than most anything you do within the XAML language.
You must be looking for magic. In any real programming exercise, you always are expected to specify all your needs. The only thing that could be better, as Bass suggested, is to reduce the verbosity of XML.
That's highly debatable. If what bondsbw posted is "XAML" it looks way too verbose (also why XML in 2016?) and just like missing any kind of thought in the design of the markup. This:1
Should be something like this:1
I agree that the verbosity of XAML is bad and have previously advocated for something better.
But that syntax you suggested doesn't make sense because this isn't defining a control. It is defining a Setter, which modifies a property of a control, in the same way that CSS styles modify HTML definitions.
XAML control definitions are more succinct than style setters and look very similar to what you suggested.
But even then there is stuff talking about pixels and layout properties in the markup which is kinda gross to me.
That's not inside the markup, but within a separate Style. Like HTML+CSS, XAML has distinct ways of defining structure and layout. But in XAML both parts are XML-based (unlike CSS which is just a completely different language).
@DeathByVisualStudio: I don't know about the ribbon control (never liked it enough to even try) but adaptive triggers in UWP seem to be pretty simple. Tell it what causes the state to trigger (windows size above a certain point), and what to change.
<VisualState x:Name="Wide"> <VisualState.StateTriggers> <AdaptiveTrigger MinWindowWidth="900" /> </VisualState.StateTriggers> <VisualState.Setters> <!-- Keep SplitView pane always showing inline --> <!-- Hide the Hamburger, it's useless here --> <Setter Target="MySplitView.DisplayMode" Value="Inline" /> <Setter Target="MySplitView.IsPaneOpen" Value="True" /> <Setter Target="HamburgerButton.Visibility" Value="Collapsed" /> </VisualState.Setters> </VisualState>
And as I stated before, UWP is adaptive to input as well. Larger menu items for touch vs. smaller ones for mouse. Different strategy when an Xbox controller is in use. And so on.
So it's more like the adaptive layout by the sound of it
What you linked is "Auto Layout", and it appears to be roughly equivalent to the margins and padding that have been in XAML since the beginning. No, that is not what I'm talking about.
I'm talking about changing any part of the layout or content you want. If the windows is less than 800epx wide, content that was layered horizontal becomes vertical. Buttons get moved from the right to the bottom. A sidebar of selectable content is moved into drop-down. Description text is trimmed or eliminated.
But that's not what is happening here. Your code literally adapts to the size of the container. For example, if your app is run maximized on a large display, elements are arranged in one format. As you decrease the size, at some point the elements may rearrange to a different size. Or perhaps they resize fluidly as the container becomes smaller with no jumps. Maybe some functionality gets moved into a menu, or gets removed altogether as it doesn't make sense at that size. It's all up to the developer.
And it's not just about whether it's a phone vs. tablet vs. desktop. A desktop user could snap a window to the side, and the resizing logic would kick in to display a usable window (often the same as the phone layout). This is tons better than resizing a desktop window and cutting off most of the content, or not allowing smaller windows at all.