-
Make Old Apps Roar on Lion with FullSteam →
A friend and I were discussing the fullscreen feature in OS X Lion. Despite what many have said, we came to the conclusion that it is, in fact, useful; it’s just a different take on the Spaces mechanism, that uses less physical desktop space on the whole.
Games on OS X have often glitchy handling of their fullscreen status, usually due to the previously-poor handling the OS did of it. There’s pop-in of windows, losing your game, not having the game in Exposé or Mission Control, and so on. The one true solution to this is in Lion, which handles fullscreen apps handle perfectly. It’s great. But, sadly, most developers (if they’re even still maintaining the app) won’t do it for a long time. So, I wrote FullSteam. It’s a simple hack that kindly tells and app to shut up and go fullscreen, natively, beautifully, and just a little bit sexily (that’s a joke, for newcomers to my writing style).
Simply download the DMG and follow the 2-step instructions on it, which involve clicking, dragging, and double-clicking. Really difficult stuff.
Currently, the only apps supported by FullSteam are Source games (Half-Life 2, Portal 2, L4D, etc.) and Minecraft. No, it currently doesn’t do Steam, but who can give up such a punny name? Adding support for other apps is trivial.
If you know one you’d like to add, get the bundle identifier (right-click app, Show Package Contents, Info.plist, CFBundleIdentifier) or the executable name (Show Package Contents, MacOS, name of the hacky-looking black boxy thing). Tweet me @zwaldowski or communicate with me in some other fashion. For the more technical folk, this code is open source! Find it on GitHub.
-
Funky-Fresh Native Scrolling
Apple may or may not have introduced an update to iOS 5 that could maybe possibly have implemented a CSS property that could have the potential effect of introducing native scrolling onto HTML elements with overflow scrolling. That covers me on the NDA, right?
Okay, yes, there is a new CSS property, -webkit-overflow-scrolling. It exists. In the grand scheme of things, it’s minor, which is why I find it fit to mention. However, for web apps on mobile devices, it’s nothing short of revolutionary. While I don’t consider this here blog a webapp (he types while pointing sheepishly at your “Add To Home Screen” button), I do think it’s an important enough change to demonstrate. *cough* Because I can. *cough*
Of course, if you’re going to be OCD like me and say, well, fine, let’s make the whole damn site scrollable, there’s the ever-so-minor issue of anybody using a mobile device that doesn’t have native overflow scroll support, like any other iOS device on the planet. And, from what I hear, Android support for it is spotty. (I’ll refrain from making a snarky joke about that.) Before this property came out, the world was abuzz with a tiny JavaScript sample by Joe Hewitt (of Facebook fame; would you call it fame? I just recognize his name) called Scrollability. After 4 years, it finally gets an inertial scrolling algorithm right.
I decided to pair these up, both for use in general and here on Dizzy Technology. I’ve made an approximately 15-line change that cancels all the Scrollability stuff if you’re on a platform that supports WebKit overflow scrolling. The results are really cool, and you likely already see them if you’re reading this post. I encourage you to try the site on an iPad, because it’s pretty cool. It’s still pretty neat on a browser without overlay scrolling, too.
The code changes to Scrollability are available at my GitHub. I would also link to a code sample, but this site does (or, rather, did, depending on what regeneration of the site you see today) it really well (I’m OCD about web semantics, too!); just pull it up in Web Inspector.
-
Having It All With Xcode 4 Static Libraries
It’s been a long, annoying road to getting a usability balance with libraries in Xcode 4. Well, strike that. iOS static libraries have always been a little hellish experience-wise, whether it was your app crashing if that library had categories or the compiler not being able to find headers.
In Xcode 4, we got another obnoxious facet to this issue: auto completion, or, in Apple Magic™ terms, Code Sense. Long story short, Code Sense does not like external headers. It really doesn’t. Sometimes it just won’t index those external headers, making the experience for using, say, BlocksKit incredibly annoying. In working on PSFoundation, I ran into a much bigger issue where Xcode decides it just won’t highlight your code at all.
As most can guess, when things are a crapshoot like this, actually being able to compile and use your code was the primary issue over getting autocomplete to work. After weeks of investigation and toying around, I feel like I’ve worked things out.
The most common way to get headers working (without autocompletion) is to have the headers install to a named folder instead of /usr/local/include, so, properly:
/Users/zwaldowski/Library/Developer/Xcode/DerivedData/Filemator-/Build/Products/Debug-iphonesimulator/PSFoundation
A good way to get headers working (with autocompletion, but not always compiling properly) is to jump out of the proper Xcode scheme, e.g., Build/Products/PSFoundation over Build/Products/Debug-iphoneos/PSFoundation. Three20 does something like this, and I’ve followed them: in your static library target, set both “Private Headers Folder Path” and “Public Headers Folder Path” to “/../$(PRODUCT_NAME)/$(PRODUCT_NAME)”. Now, instruct your users to set their set their header search path to “$(BUILT_PRODUCTS_DIR)/../—project name—”. From then on, they use #import “—project name—/—main header—.h”, like #import “PSFoundation/PSFoundation.h”.
Their code will light up like a Christmas tree, things will autocomplete, and it will build.
Today, things are a little bit better with CocoaPods and fake frameworks. The former uses a method like this one, while the latter skirts Xcode’s wonky handling of static libraries entirely.
-
I had always wanted to have my own company; I suppose it’s “in the blood.” … It was always in the back of my mind that for any technology shift you’d need tools to help out. I’m really a tools guy, though we tend to call them “apps” nowadays. I was faced with the decision of continuing to work with the great people on my team on a clearly high impact project, living with the “what if” syndrome, or trying to forge my own path. ”Regret Minimization” is what should win out in life, so it did.
–From an interview with the developers of Hype.
“Jumping ship,” so to speak, for a startup isn’t always cast in a positive light by society or by people on the Internet. We in general are very corporation-biased, and a lot of us online take something like leaving Google (after being talented enough to get there in the first place) as some kind of arrogant statement or something against the company itself. It means a lot to hear positive things about the “independent” lifestyle.
-
Village Surf Shoppe
