@aL_: I hope they went over all Win32 and .NET and other APIs and cautiously thought about what to include and what not to. I would hate it if some types of applications weren't possible just because they didn't fit in the narrow vision of what MS intended Metro apps to be used for. Of course WinRT is turing complete, but that's not everything - everyone knows how Silverlight was a huge failure for desktop programming and I would hate it if WinRT was limited in the same way, for no good reason at all even.
@W3bbo: It looks like (the docs say) you can use the WinRT APIs in desktop apps. However, it also looks like the app/packaging model (i.e. the AppX packaging / AppContainer sandboxing system) is for Metro style apps only. This is a shame, as I think packaging and deployment is a big problem for the Windows desktop too.
> for phones its pretty safe to say people perfer native apps compared to [non-native experiences].
I'd say this has been usually the case regardless of the platform. I'd say it goes as far as, if there's a cross platform c++ toolkit and a OS native c++ toolkit, rarely the resulting app from the cross-platform solution feels native to the OS even if it's in "native code". I'm tempted to say this can also lead to the perf of the app dropping but there's so many unknowns in play that all I can say is that when switching from native to cross platform toolkit, profiling should be done to see if there are some new surprise bottlenecks.
Random comments on the keynote touch/swiping demos... Huge latency between swiping the screen and stuff happening + lot of glitches. The "robotic finger" demo did not seem to have such latency. I hope they work a lot more on this area as it's the most important thing next to having a good display in the table. At very least, the latency should match the competition.
@blowdart:Lol, I think you know what I meant.
Just to state the obvious - WinRT supports Turing complete languages (so it's not like SQL..). But having said that I've explained the obvious which is that despite the fact that you can compute everything that is computable and reach all kinds of inputs and outputs, you can still be very much limited if the surrounding framework lacks some until now taken for granted fundamental features.
I am not a programmer, just a curious user. I noticed all of the Metro/WinRT apps in the Consumer preview and store look about the same - the same scrollbars, the same text, fonts - and with the same limitations (i.e. cannot select smaller/larger text, different backgrounds, etc.)
Is that a limitation of the language? or is that a requirement by Microsoft to keep the look/feel the same or is it just easy for the programmers in the pre-release versions of the apps.
For example, I find that the scroll bar contrast is usually so low I can't find it without squinting and while the text size is probably great for a tablet, on my desktop the fonts are much larger than they need to be, limiting the amount of the info on the screen.
I would provide this type of feedback on the apps, but I don't know if it is just a waste of time or not.
It's not a limitation of the language - WinRT allows you to draw arbitrary pixels in arbitrary places on your canvas, so you could technically make an app with all of the controls looking like Windows XP if you really wanted to. The reason why all of the controls look the same is because the common controls of WinRT look like that.
If you ask WinRT for a scrollbar, it'll look like the scrollbars you currently see in Metro. If you're willing to write your own (or link against code from somebody else that decided to) then you can make your controls look however you want to - subject to the restrictions imposed on the UI by Windows8 AppStore.
Providing feedback on the apps - particularly the UI of common controls is best done now if you'd like to see a change. Once Windows goes RTM there won't be any turning back, and the scrollbars will look the same until at least Windows9.