@JoshRoss: "Windowth", obviouthly.
Right you have to enable dev mode, which is also trivially possible to disable to revert back to the previous state. When you are in dev mode and you start up a Chromebook, for 30 seconds on boot (completely wrecking the "fast boot" niceity too, btw), the thing says "hey, you are in dev mode! if this is wrong, press the space bar." Yes, really, the space bar. There is no "are you sure?" either, it completely wipes your Chromebook the moment you press that space bar, accidentally or otherwise. If you install a different OS, all your files, and everything are gone as Chromebook reverts to its original state.
There are hardware hacks to avoid this, but even they aren't perfect for many Chromebooks. This is actually my biggest compliant with Chromebook: it's hard to alter, even if you want to.
lol, I was thinking of buying a chromebook to put some distro on because people on forums said they made good cheap Linux laptops but now I see those people were clearly insane.
Microsoft doesn't just make money off of Windows, they also make money off of Azure and other services (which are easier to use with MS tools/languages/etc.)
The Xamarin partnership stuff is meant to keep existing MS developers using MS tools (and therefore make it easier for them to target Windows as well), it's not really aimed at attracting new developers. For that I think they should consider a "reverse Xamarin" strategy: improve Windows' support for common languages and APIs from other platforms - for example with WinRT bindings for Java and OpenGL ES support - and make it easier to target Windows using tools popular to developers on other platforms (Eclipse? Android Studio?)
@itsnotabug: Don't think so. They were always planning to evolve/expand the immersive windowing model (you saw the first step of this in 8.0 -> 8.1), but not necessarily in the direction of merging it with the desktop "overlapping windows" model.
I think there's a lot of confusion of terminology here, which I guess is partly Microsoft's fault for overloading "metro" to mean a bunch of different things. Are we talking about the Windows Phone design language, or the more vaguely defined Microsoft-wide design philosophy, or the Windows 8 immersive windowing model, or the WinRT application model, or the set of new shell features in Windows 8 (live tiles, contracts/charm flows, etc.), or what?
From the rumors it sounds like the main thing they are de-emphasizing for "classic" PC form factors in future Windows is the immersive windowing model, in favor of fitting the new features (including Start / tiles) into the stacked-window desktop model instead. I personally wouldn't characterize that as "abandoning metro" but just reducing the focus on (or decoupling) one aspect of it.
I think Chris Anderson's answers at 9:09 - 11:34 in this video -> http://channel9.msdn.com/Events/Build/2014/9-007 are probably salient:
T: So Charice wants to know: Does XAML in Windows 8.1 code work in Windows 7 WPF desktop application or do we need customization?
A: That's a fabulous question! WinRT XAML is not accessible to desktop applications in Windows 8.1, so you have to write the UI again.
H: Especially not downlevel to Windows 7. We got some parts of this question earlier. WinRT is built on other improvements in Windows as well, that don't exist in Windows 7. It's hard to decouple some of the optimizations of some things like our composition, and aspects that just aren't there in Windows 7.
T: Absolutely. And this kind of goes back to when I jokingly said something like - one XAML. Right - One Microsoft, OneDrive, One XAML. Do you foresee sometime in the future where there actually could be one XAML that runs in different runtimes, or different contexts, like WinRT, desktop - it's something that would be really interesting.
A: Of course. I think that in Windows 8, we coupled a bunch of decisions together, around app containers, and security models, and store distribution, and programming models, and windowing models, and all of these other things. We put a bunch of these decisions together and we called one side the name of M which cannot be spoken, and the other side we called desktop apps. I think you see already in the keynote, and the work we've been doing, and where we've taken the 8.1 experience and where we're going in future releases, that we're starting to take those decisions and decouple them and make them be independent. So Harry showed a demo that showed you being able to break out of your app container and call full-blown native .net code to access LOB functionality. We saw Terry show a demo where there were some hints at future windowing ideas, that we're looking at decoupling that. And so I don't know if I necessarily say that the XAML we see today is going to suddenly light up in desktop, I'm just not sure how long that distinction between those two experiences is going to remain, and which decisions are going to be where.
Microsoft is a hive of a company with few individual opinions
Personally I very much agree that
- Clicking on a tile with a specific notification doesn't take you to that thing the notification represents. Instead it launches the app and you have to dig around the app to find the thing you were notified about (Facebook is a prime example). I find that very frustrating as that's what I'm used to on my Android phone.
is a huge problem with the current implementation of Start and live tiles. So I think a reliable way to deep link into the specific information a tile update represents would be very welcome.
OTOH I'm not sure the start screen would be a good place for more involved interactions with an app. The objections RealBBoy and magicalclick raised, that it would complicate interaction with Start and present developers a dilemma of where to implement features or require them to implement the features twice, are pretty salient I think.
So personally I'd prefer if interactions with tiles were kept focused on (1) dynamic deep links (e.g., click on a specific email out of several in a large tile and open that email directly) and (2) quick actions involving no more than 1-2 user interactions, the sort of thing you might see in a taskbar thumbnail (e.g. play/pause for music) or an Android notification (e.g. quick delete for an email). Whereas something more involved, like replying to an email, would be reserved for the app itself.