I've had my topcase replaced and the problems just came back months later. Does anyone know if they have a solution to this problem or is their plan to just have me ship my machine to them every six months and avoid the class action?
I'm confused about something. I keep hearing people say that they're replacing their "topcase" to fix this. What is the topcase? I thought the "topcase" was the screen.
No, the screen is the screen. The lower part of the laptop (where everything but the screen lives) has a case made of two pieces of aluminum. The topcase, which is the top half of the aluminum body, and has the keyboard mounted very deep into it as well as the logic board and other parts. There is a smaller piece of aluminum that screws to the topcase to hold everything inside.
Close. The bottom case is just a panel, not holding anything in, so removing it just gives access to the inside. Everything is attached to the top case, but some parts, like the display hinges and motherboard, are removable at the shop, while others, like the keyboard, plus the trackpad and battery for retina MBPs and newer, are part of the top case assembly part.
(The 12-inch MacBook is different: some parts are attached to the bottom case, like, iirc, the motherboard.)
the keyboard, palmrest/keyboard surround, and batteries are all one unit. they replace the whole thing if you need a new battery too. It's been like this since 2012~
I’m not making a argument. I hate the design more than anyone.
The problem has been acknowledged by Apple as being particles of dust, food behind the key mechanism. So the obvious solution is to cover the keys. I’ve had a cover for a while and now have had zero issues.
I love that you kept the tried and true Box2D API as that'll make porting what I'm working on much easier. I've been using the emscripten version [1] but the automatic port from C++ makes the JS API quite painful at times, especially with the manual memory management that's required to prevent leaks. Thanks for doing this!
[Cursors] can help a lot with this problem. As far as sibling/child components know, they own the state, but they're really using immutability helpers to update a larger encompassing state object.
I'm a fan of [superagent] for AJAX. The React lib is big, but its declarative nature has lead to fewer and easier-to-diagnose bugs for us, which is ultimately a win for the end user. I've been using it exclusively on new projects for months now and I'm a Backbone.js core contributor ;)
I've been toying with mercury, which is similar to React/flux, and had the same dilemma as the parent. It seems a bit strange to use a really light weight library like mercury and then throw jQuery into the mix.
I also checked out superagent and it seems to have a good amount of dependencies. I was thinking of simply wrapping XMLHttpRequest with the promise lib of my choice.
I went for a minimalist implementation that leverages the work done in React's Immutability Helpers (http://facebook.github.io/react/docs/update.html). The API allows you to use the same `this.state.xxx` you're used to which I find nice.
Unfortunately it looks like screenshots can't be edited (or even rearranged) until a new app binary has been submitted. I'll make this change when I get some new levels cooked up.
