Yeah, that verbosity is pretty ridiculous. I could make a responsive, resizable window in VB6 by dragging and dropping something in 10 seconds in 1998 if I wanted to. I understand it's not the same, but wow, the tooling has taken a step back now.

I feel like C++ is getting ridiculously cumbersome to code on par with Java, and I also feel like this "XAML" crap by Microsoft would drive away all but the more patient programmers.

this was how i felt reading the helloworld for windows 10. very good point.

for example from the same page: to print "Hello's" you actually have to type "Hello"s", (I assumed you cant use \' anymore)

That's just bad formatting on the website.

It's verbose but also extremely flexible and toolable. You're discounting how easy it is to add arbitrary animations between these two states, or how you can visualize them in Visual Studio without having to rebuild your app.

You can also create your own triggers so that you can be "responsive" to any arbitrary event.

> bmp Windows::WinForms::XAML::Imaging::Bitmap = ^new Windows::WinForms::XAML::Imaging::Bitmap(filestream)

That must be an outdated example. That namespace doesn't even exist. You can add images like this:

<Image Source="hello.jpg"/>

I could be interesting to compare that to the Android/iOS/HTML5 equivalent.

Basically this XAML does 3 things:

- declare 2 states: narrowState for windows smaller than 640px widestate for windows wider >= 641px

- set the layout stacking strategy of a container to Vertical when in narrowState

- set a top margin of a button to 4px when in narrowState (not sure this is relevant for this sample)

I don't really see what's wrong in your second example. You get exactly what you ask for.

Sure, it could be improved by having

1) the "auto" keyword and

b) one project include which exactly defines which namespaces/aliases to use.

My original gripe was simple, if I declare bmp = class() should I really have to tell the compiler what the return type is? ideally no.

>its now in 4 spots (header, function definition, and two spots on the same line in case the compiler cant find those?)

also they added a ^ operator so thats cool.

but I guess my gripe is every time I want a different taxonomy function I have to page up to the top of my CPP and type 42 keystrokes. (also I think I might have been missing an extra taxonomy there and its really 5 namespaces deep.)

You can use C# or JavaScript if you don't like C++.

Well, once you understand visual states, that XAML example starts to make much more sense. I don't think the issue with W10 development are the tools because they are generally quite damn good.

Once you understand what the equivalent would be in a pure Win32 application, XAML starts to make much less sense... making a window resizeable involves setting one bit in the window styles and responsive just means a loop over the contents to move them to the right places when WM_SIZE message is received.

Declarative UIs in XML are more verbose and less flexible than just putting the appropriate expressions in a simple resize-recalc table, which is what the Win32 equivalent would be.

Without addressing the XAML mess, Window resizing in WINAPI is a complete mess too. You toggle whether a window is resizable by setting the window style (wtf!) with WS_THICKFRAME. When resizing windows, you need to handle three different messages (WM_ENTERSIZEMOVE, WM_EXITSIZEMOVE, WM_SIZE). To set minimum/maximum size, you respond to a WM_GETMINMAXINFO message.

All I wanted was SetWindowMinMaxSize(hwnd, min_size, max_size) and an event to tell me the window has resized. That's it.

This complexity allows apps to misbehave in various ways, either unintentionally, on purpose or maliciously. Windows programming is so darn complicated that it doesn't make any sense.

>responsive just means a loop over the contents to move them to the right places when WM_SIZE message is received.

So you're suggesting I should handroll my own layout manager? That sounds several orders of magnitude more complicated.

Well, essentially your re-layout loop would probably end up applying some specific pattern in code. Declarative UI is basically a way of doing that in a way that other developers have a better chance of understanding, and is less prone to bugs.

Not that you couldn't go the hard way and write the responsive UI with code only. A XAML file is essentially just a recipe for creating the hierarchy of objects in your UI, that the framework then goes on to draw. Everything that is done in XAML can just as well be done with code.

Having attended a course on XAML, and done a few small home projects using XAML, I can see how it can make sense if you use it intensively, but if you use it occasionally, it is an absolute nightmare, a bit like regex. Making things hard to learn is not a good design principle.

remarkable how many times the string "VisualState" appears. such a waste of bandwidth.