Discussions

@nehresmann: Only if your OS is awful at caching or your compiler is doing a very poor job of indicating files that shouldn't be cached. All "having a RAM disk" does is add an unnecessary copy step between bits of memory and reduces the amount available for caching in the first place.

42 minutes ago, fanbaby wrote

So today Microsoft added yet ANOTHER transpiler. Great. News at 9. You see, in this new world, the fact that it's Microsoft, or Google, or Apple or anyone, means nothing.

LOL, only in fanboy dreams. FOSS projects without substantial backing are high risk options and always will be. Nobody wants to bet heavily on something that disappears overnight because the kid responsible for it got a real job/bored/went to college etc.

2 hours ago, JohnQPublic wrote

This reminds me of Charles calling people for trolls just because they ie give negative feedback.

*sigh* if you're going to sign up for a new account pretending to be someone new to the community, it helps not to mention a comment from the end of an obscure thread pretty much only a handful of people would have read. </freeadvice>

The tools are not as complicated and specific as SuperFetch (afaik the api's needed to write a superfetch open source version is missing).

If the APIs were missing, how would SuperFetch work? It's entirely possible to write a replacement for it, although the phrase "reinventing the wheel" would seem to apply.

They use block based caching of all the requested data from the hard drive. So the access time would be sped up no matter what data the programs regularly used not just the launch speed.

As does SuperFetch, it's all about what it decides to pre-fetch that makes it apply to launch times rather than anything else.

I was testing ramdisk a few days ago and it got me thinking. The speed up was huge. Using a caching solution might be good both for performance and the longevity of the hard drive.

You're trading performance in one area (disk caching) for another (absolutely everything else that requires RAM). It might appear faster in isolated benchmarks or over short periods of time, but under real world usage ramdisk type approaches sacrifice far more performance than they gain.

The stock exchange has always been a notoriously bad indicator when it comes to technology trends. It's why we had the whole dotcom bubble, it's why Facebook was valued so obscenely high. There's far too much focus from those looking to make a quick buck on what is cool or new, rather than what is necessarily profitable.

Microsoft still make more profit than Google and across a much more diverse portfolio of products too. Buying their stock probably won't make you rich, but it's unlikely to go bust anytime soon either.

30 minutes ago, DeathBy​VisualStudio wrote

*snip*

web apps are "all the rage" with HTML5 and all.

Huh? have I slipped back in time to the mid 2000s again? Web apps were all the rage, those days are gone, have been ever since the introduction of apps on the iPhone/iPad.

13 minutes ago, DeathBy​VisualStudio wrote

The only thing confused here is you Andy.

• Stylus: acts like a mouse today, high precision -- show "x"
• Kinect: low precision -- don't show "x" (Pretty disingenuous of you to throw this in your list of "concerns")
• Mouse with touch: high precision & low precision -- show "x" if the bar is brought up with the mouse, don't show the "x" if the menu is brought up by touch.

You see, you're missing the subtleties. Let's say I'm holding a tablet in my left hand and using the stylus in my right. I swipe from the corner to bring up the switch list and want to swap to an app in the list near to where my left hand is resting. It's much, much easier to use my thumb to click than to contort your arms to do it with the stylus. Except now you've put these close buttons there and we're back to accidental closures. And that's assuming you're using a tablet-style direct-to-display stylus, as opposed to a separate desktop one where there is a visual disconnect - you're now forcing the user to employ a degree of accuracy otherwise unnecessary to switch tasks (the Taskbar doesn't do that, for example)

Similarly with the mouse with touch, the whole point is to allow quick gestures which can bring up system or app UI, but your hand is still on the mouse and you still might want to use that to actually point/select. Except now you've made the close function you wanted more accessible disappear, so the user either has to give up the touch gestures or go back to the right-click menu that is apparently too difficult. More exotic devices like Kinect only increase the number of UI combinations, none of which are necessarily going to be used in isolation any more than you'd use the mouse in isolation from the keyboard.

The W8 desktop taskbar already implements this differentiating between mouse, pen, and touch currently. When touch is being used it displays the "x" for all thumbnails. The only change required would be to avoid the latter when touch is in use -- you know to avoid accidental closures by Microsoft apologists.

And it just doesn't do it well. Trying to fudge touch support onto a UI designed wholly around the idea of being mouse driven is inevitably going to fail. That's kind of the whole reason why Windows 7 touch devices aren't ubiquitous already. It's why Steven Sinofsky said in the Building 8 blog all those months ago: "Going back to even the first public demonstrations of Windows 7, we worked hard on touch, but our approach to implementing touch as just an adjunct to existing Windows desktop software didn't work very well. Adding touch on top of UI paradigms designed for mouse and keyboard held the experience back."

And let's not forget that the W8 desktop taskbar can be oriented vertically on the left or right side of the screen...

I have absolutely no idea what point you're trying to make with that.

51 minutes ago, DCMonkey wrote

*snip*

There's also infinite screen width courtesy of Fitts' Law if you keep the mouse against the edge of the screen.

As for the rest, making close buttons only appear for the mouse would solve the fat finger problems from touch use.

But your mouse starts against the edge of the screen, so any unintended travel is naturally going to be away from the edge, so you can't really rely on Fitts to help.

I'm also not convinced that you having close buttons appear/disappear depending on what input device your using would work particularly well in practice either. Aside from being potentially confusing, it starts to introduce oddities with differing input devices (Should a stylus act more like a mouse or touch? What about Kinect? What about a mouse that supports Touch gestures?)

22 hours ago, DCMonkey wrote

*snip*

The Windows 8 App list requires you to put the mouse in the top left corner and then move it vertically along the left edge of the screen to activate. It would be nowhere near the close button of the thumbnails.

With a large display there is quite a bit of scope for mouse travel sideways if you're aiming near the bottom of the list. And it's much worse with touch because aiming is a lot less precise, particularly if you're stretching your finger to reach one of the more extreme ends of the list. Ironically the IE tabs suffer less here because you've pretty much got to take your hand away from it's natural position in order to click them.

PS: I noticed that Windows 8 App Store App Internet Explorer 10 has permanently displayed close buttons on its thumbnail shaped tabs. 

Yeah, those I the ones I've already got annoyed by hitting occasionally when use the trackpad on my laptop, because in that case you right-click somewhere and then make a (potentially) large mouse movement to hit the tab. It's probably not quite as bad if you've got a mouse plugged in, but trackpads have never been nearly as easy to be precise with as a mouse (despite Windows treating them identically).

12 hours ago, DeathBy​VisualStudio wrote

*snip*

You know they can't design a UI that protects idiots from every mistake they make.

I suppose you have that problem with the W7 taskbar thumbnails too. Do you run with scissors? Be careful!

No, but that's probably because the mouse pointer is naturally very close to the thumbnail by the time it appears (because it had to hover over the button to trigger it). As a result you're typically making a shorter, slower movement and are thus more likely to accurately hit the correct target. By contrast the IE tabs or the W8 app list potentially require a much longer range movement and thus accurately targeting quickly becomes more difficult. You may have heard of this before, it's called Fitts Law.

*snip*

You're also throwing out the notion (again) that desktop PCs will exist in this new world and if they do they won't have a mouse & keyboard. Devices like tablets and phones don't have the luxury of large screen sizes or mouse & keyboards so they need a simpler interface.

Am I? Or did I explicitly state:

5 days ago, AndyC wrote

*snip*

What you're missing is that if you were designing an OS from scratch today with absolutely no legacy cruft whatsoever, even if you went with a "desktop" style paradigm with overlapping windows etc, you still wouldn't design it in a way that requires users to "open" or "close" applications.

What you're ignoring is that just because you take an app-centric view or move the application lifecycle to one that is more system managed - it doesn't mean you have to give up a desktop environment. Nobody is (or at least nobody should) say that all future applications will exist in a Metro-like environment.

If you look at the last 15-20 years of OS development you'll see this is exactly the way everyone has been trying to go. It's precisely why the Apple Dock was created originally in a way that barely distinguished between running and non-running apps and why Apple at the time were often trying to explain the "with OS X you won't need to close apps" line (admittedly they someone pre-empted their OS being truly ready to take that approach. It's what things like Restart Manager and the OS X equivalent were meant to enable. Even your much loved Window 7 Taskbar is about blurring the distinction between launching and switching apps, albeit within the confines of what traditional Win32 apps could do.

The only way in which Metro represents a shift in thinking is that Microsoft have learnt the hard way that they simply can't introduce bits and pieces into the OS and expect apps to embrace them in the same way that Apple can. The amount of software out there today that supports Restart Manager, for example, is statistically insignificant - because the sheer weight of developers wanting legacy OS support steers them all away from using new features (no matter how many times the idea that apps can "light up" by using new functions on a new OS, it's just a bit too rare in reality). In contrast all the big OS X apps are first party, so new OS functionality gets embraced fast, which in turn pushes third party developers to keep up. The end result is taking a much bigger, more holistic approach to bringing Windows up to date and dragging developers along with it and focusing that effort on the sector of the developer market (that which is predominantly consumer focused and thus carries less back-compat baggage).

*snip*

Sounds like you're inferring that any app that isn't connectionless is written wrong. Another "you're holding it wrong" response. Very clever.

It's not "wrong", it's just dated. There are many good reasons that moving in favour of a RESTful approach is preferred these days, the fact that such designs work better in suspend/resume scenarios is by no means the biggest.

*snip*

Current PC's having problems resuming from sleep? Say it isn't so! Oh yeah it is...

Oooh look, the goalposts move again. What do driver and hardware issues that cause resume to fail have to do with the speed by which a working PC can resume?

The Atom processor in the ThinkPad make me a little nervous since we all know who well netbooks perform but I'll give it the benefit of the doubt because it's next-gen and dual core. So what are you willing to give here Andy?

Clover Trail is the Intel SoC design. It may use x86 instructions, but otherwise it's a lot closer to the ARM chips you'll find in iPads and Android tablets. SoC, aside from supporting newer power modes like "connected standby" are far easier to handle from a driver PoV, because there is obviously a lot less variation in the support hardware than in a traditional PC.

*snip*

I was there smart guy. That's how I got my tablet. Heard every word he said

Hearing != Listening.

*snip*

Andy has an interesting sense of reality; one where the mouse and keyboard don't exist.

Au contraire, I fully expect mouse and keyboard to be used for a very long time.

9 hours ago, Bas wrote

*snip*

Oh the terrible irony.

XAML is also used for more than just graphics too, it's a generic markup for object models.