Entries:
Comments:
Discussions:

Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

bondsbw bondsbw
  • Joe Duffy started blogging about Midori

    @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.

  • Joe Duffy started blogging about Midori

    , TexasToast wrote

    Research with no practical outcome should be done at a university.

    No research team starts by assuming there is no practical use for the information gathered during the process, that would be dumb.

    A company that doesn't do research doesn't grow.

  • Microsoft Kill Off Windows Phone

    @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.

  • Microsoft Kill Off Windows Phone

    , DeathBy​VisualStudio wrote

    That's oversimplified. When you have a complex business app you'll have a sh1t ton of controls and user concerns to deal with. 

    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.

    , Bass wrote

    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
    <Setter Target="MySplitView.DisplayMode" Value="Inline" />

    Should be something like this:

    1
    <mysplitview display="inline">

    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).

  • Microsoft Kill Off Windows Phone

    @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>

  • Microsoft Kill Off Windows Phone

    , cbae wrote

    The only problem is that the "pointing device" that you use on a phone is gigantic relative to the display size, so addressing the text size isn't all that you need to worry about.

    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.

  • Microsoft Kill Off Windows Phone

    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.

  • Microsoft Kill Off Windows Phone

    @magicalclick:  UWP accomplishes it with effective pixels which takes into account not only the pixel density of the display, but also the typical viewing distance, to normalize the perceived size.

  • It would still be a travesty had they been awarded $1

    , fanbaby wrote

    its patents are very meaningful (slide to unlock anyone?)

    Ha.  Haha.  Hahahahaha!

    THAT is meaningful?

  • Microsoft Kill Off Windows Phone

    , Ray7 wrote

    But this is pretty much how it works on Apple gear. You can have a fat binary that holds different layout templates and controllers for the iOS or tvOS and pick the set at runtime.

    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.