|
February 16, 2010
Betas, Twitter and WTF
I've seen some complains from people about us seeding betas on Twitter and how it is inconvenient for some of you. Why are we bothering with the whole Twitter thing? Mostly because… it saves us time. With the recent addition of @haxiesbeta Twitter account it's now easier to seed these betas — you sign up, we approve your request, and then you instantly see the links to all the current versions of stuff in testing. With e-mail lists it was fairly tedious to manage, prepare and send notifications. So yes, I guess we're just using the opportunity to save the time to do something more productive. We don't expect the beta period to be long. We also don't urge everyone to jump on the beta train. Pre-release versions of the software tend to be buggy and may cause instability of your system (we try really hard to not allow that, but it's software, and it's fairly complex). After all, in 2-3 weeks we will release everything publically (hopefully) and it will be a much more polished experience - thanks to our testers. Meanwhile, Xounds for 10.6 is preparing to enter the beta stage, and we've seeded FruitMenu and Labels X updates, with WindowShade X beta update to be out later tonight. Thanks for sticking with us!
June 02, 2009
Mighty Mouse with Some Theme Sauce
Cursors! At long last, here's a version of Mighty Mouse that works on Leopard. It's also got a few new UI wrinkles, and you can now easily move your cursors back and forth between Mighty Mouse and Adobe Photoshop™. Enjoy it, and report bugs! Wait, what did you say? ShapeShifter will never be updated for Leopard, and here's why: The way that Apple has internally implemented skinning of the UI for Leopard is very obviously a stopgap measure on the way to something new that they'll unveil in the future. To explain this, I need to go into theming history and future extrapolation a bit, so please bear with me.  themeing as old as this icon Until Leopard was released, theming on OS X was mostly done via a single monolithic file named Extras.rsrc. Internally, this file was a Resource Manager file. The Resource Manager is a leftover from Apple System 1 (yes, seriously) and has been officially deprecated by Apple since the original release of Mac OS X. And yet, this is how theming has been implemented. Obviously, this situation couldn't last forever. With Leopard, there's something new and spiffy — CoreUI. In the old Extras.rsrc system, the themer modified a bunch of chopped up bits of buttons and sliders and the operating system assembled them all together onscreen. CoreUI changes this idea dramatically - instead, the themer describes what should be rendered onscreen and the operating system assembles the graphics from the themer's recipe. Cabel has an old but good blog post describing this here. Sounds great. The problem is that it wasn't ready in time for Leopard. So Apple pulled a quickie. Leopard still uses the old, late '90s era vintage Extras.rsrc system. Leopard also uses the snazarrific late '00s era CoreUI. And Leopard uses the stopgap measure called ArtFile. And all three of these completely different systems get used in different places and under different conditions, sometimes even within the same application.  coreui, straight from apple's patent filing So, what's this ArtFile thing, then? Basically, it's two single files (with two unique file formats, of course) that contain the various images used to composite the operating system. They're both binary files, and neither one uses any sort of a documented file format. And unfortunately, the majority of theming on Leopard uses this particular subsystem out of the three that are available. So why not convert ShapeShifter to use this system? Basically, because it would take an entire rewrite of ShapeShifter, and I know that I'd be required to do another complete rewrite as soon as the transition to CoreUI is complete. If I'm going to do a complete rewrite, I'm only going to do it a single time. So basically, ShapeShifter is sitting out Leopard. Once we get a good look at Snow Leopard at this year's WWDC, we'll see how Apple's transition to CoreUI is doing and I'll be able to evaluate ShapeShifter for Snow Leopard more seriously. In the meantime, themers haven't had many options under Leopard. I personally apologize for this. I haven't been following the theme world closely during the Leopard era, and when something called ArtTools came out a year ago, I thought that themers had what they needed to create themes. Façade was originally slated for release last fall and I thought it would fill the gaps. I didn't realize until a couple of months ago when Magnifique was released that themers really hadn't had any good options, and that the situation still wasn't ideal. So here's something to help: a new build of ThemePark that has full support for the two different types of ArtFile used in Leopard. Themers can use this to build Leopard themes. And something really new is that you can also apply these themes from within ThemePark. This ThemePark build is basic as hell, and the themes you can create and use with it are a far cry from what you could do with ShapeShifter. There's no Unsanity APE module involved, which drastically limits what can be done.  It's also alpha software, meaning that there are known bugs and it isn't feature complete. In the event of an emergency, you can revert to Aqua via the command line by entering the following command:
Anyway, a picture is worth at least thirty-six words, so here's a fun lil' screencast showing how you can create and apply a theme that will turn your Mac OS X from blue to green in under five minutes. Enjoy!
April 17, 2009
Welcome back.
 It's been a while since this blog was updated… the same stands for our products. I believe it's about time to change that — drastically. Today, we're releasing the Leopard-compatible version of our haxie Xounds (a public beta) as well as a public beta of WindowShade X that fixes the most annoying bugs. In the coming days, you will see the Leopard-compatible Mighty Mouse and the final releases of Xounds 2.5 and WindowShade X. Then we will focus on ironing the remaining bugs out as well as doing further R&D work. You may notice that our site and products branding changes over time — we are doing the rebranding and the new website is half-way ready, but it's on the low priority as we'd like to focus on products first. Above is our new logo, and all of our haxie updates will have new icons to match the updated, simpler look. We are already doing some research on the Mac OS X 10.6 Snow Leopard to make our most popular haxies supported, as well as bring you something new. Either way, thanks for staying around with us through all these years — it's your support that helps us going and motivates us to do the work. Despite the recent silence, we're full of energy and do our best to not let you down. Yarr! Download Xounds 2.5b1
September 20, 2008
Spectacular Catastrophe: WindowShade 4.2b2
And thus, it is thrust upon this world.  There is one small change to this update. The donate panel in the preference pane has been removed. It has been replaced with a voluntary upgrade fee (vuf) panel. This is mostly because WSX is like totally 7 years old. Seven Freakin' Years Anywho, here's what's new in beta 2:
Some of these changes should please some people. Not much to say other than happy window shading!
September 15, 2008
Feel the Heat That's All Around You; Flashing Lights and Ecstasy Surround You: The Silly Effect and John Gruber
When we first put the "Silly Effect" effect in Menu Master, a lot of users complained about it, as you can see by looking at the comments for Menu Master on JesusUpdate. I mean a lot of users. I had never seen such angry comments about a feature before. (We got more angry comments via email too). 
We've seen more than a couple of reports that MeMa 1.4.3 doesn't like Adobe applications on Mac OS X 10.4.11. Something to do with the Help menu and the mouse cursor position. While we could reproduce it in the beta builds, we fixed MeMa to do the right thing, or so we thought. Please Help! If anyone is experiencing odd problems with Menu Master 1.4.3 and Adobe applications, please email us a System Profiler report (Apple Menu ☞ About This Mac ☞ More Info…) and a screenshot of your screen immediately after the problem (Command-Shift-3, a new file named Picture N.png (where N is a number) will appear on your desktop, send us that). The Silly Effect is Back; It Wants Blood The Silly Effect is a cheesy animation option developed over the course of a few weekends on May 26th, 2006 (over two years ago). It has been in hibernation since then. Silly Effects puts a Quartz Composer document animation in the background of a menu. By default, these documents are culled from Library/Application Support/Unsanity/Menu Master/ in both your user folder and the main Library folder (Local Domain and User Domain). There are also a number of quartz composer documents included in the Menu Master.ape application enhancer bundle. These included quartz composer documents are from Futurismo Zugakousaku's excellent Quartz Composer Lab study, used with permission. If you wish to create your own snazzy animation and are familiar with Quartz Composer, Quartz Composer documents can use two inputs that Menu Master makes available to them. "SelectedMenuItem", which is the name of the currently selected menu item (you may want to filter out "-", the separator), and "MenuItems", which is an array structure containing the names of all the menu items in a menu.
Apple's Quartz Composer Documentation Futurismo Zugakousaku's excellent Quartz Composer Lab study (contains a lot of excellent Quartz Composer documents, some are included with Menu Master). What's new in this version of Menu Master 1.4.8b1? Control is what's new.
There are a few known issues with this release, but they are mostly minor aside from the Safari 4.0 bug (which is a bug in JavaScriptCore). Download Menu Master 1.4.8b1 (after installing this, you'll get notices of new Menu Master betas until 1.4.8 is released)
Despite our much publicized interactions with the programmers at Barebones, we highly recommend BBEdit. It is a highly useful text editor that we at Unsanity could not do without. (In fact this post was made with the help of BBEdit). Neither SlickEdit 2008 nor Notepad++ can hold a candle to BBEdit (although I've yet to personally check out the new BBEdit 9).
August 25, 2008
Purified Chicken Embryo Cell, The VUF, and Menu Master Beta
The response to the voluntary upgrade fee for FruitMenu was freakin' amazing. It far, far exceeded our hopes and we give our gratitude to everyone that did the VUF.  Once again, I want to give thanks to all those that participated in the VUF and to all those that plan to participate. Let's have a chat about Menu Master For the last year and a half (18 months), every Menu Master beta has included a "Silly Effect". Most people never noticed this because it would only appear in one or two applications (TextEdit and Safari). The Silly Effect itself was created over the span of two weeks way back when, and polished so it could be shown off to users. It looks something like this (but animated):  Anywho, that's how it was in Menu Master one point four point three beta three. And then there was the anger. So much anger and so much ire. Some people claimed it was a bug. Some people tried repairing permissions, being unable to tie the new behaviour to the software they just installed that mentioned "silly". Some people went completely "psycho". (For what it's worth, he was told not to share the key because it had already been changed to something else in the codebase for beta four). If anyone has seen any other public forums with posts that complain about b3, please email the links to us or put the URL in the comments. Before releasing the third beta, we were a little worried that not that many people use Menu Master (MeMa from now on). Well, putting in that "new" feature and defaulting it to on with so many animations (some very hard to read) definitely taught us something. People that love MeMa... really love it. We'd also like to apologize to anyone that lost work or had a drop in productivity while the animations were showing. What's new in 1.4.3b4?  Here are the release notes:
Here is what has been added to the read me: Silly Effects Silly Effects is a cheesy animation option developed over the course of a few weekends over a year ago. There was no work needed to make it compatible with Mac OS X 10.5. Silly Effects puts a Quartz Composer document animation in the background of a menu. By default, these documents are culled from Library/Application Support/Unsanity/Menu Master/ in both your user folder and the main Library folder (Local Domain and User Domain). There are also a number of quartz composer documents included in the Menu Master.ape application enhancer bundle. However, these are not loaded by default. If you wish to load these bundled animations, check "Include Bundled Animations" in the Menu Master preference pane. If you wish to create your own snazzy animation and are familiar with Quartz Composer, Quartz Composer documents can use two inputs that Menu Master makes available to them. "SelectedMenuItem", which is the name of the currently selected menu item (you may want to filter out "-", the separator), and "MenuItems", which is an array structure containing the names of all the menu items in a menu. More information on Quartz Composer can be found at: Apple's Quartz Composer Documentation Futurismo Zugakousaku's excellent Quartz Composer Lab study (contains a lot of excellent Quartz Composer documents) Do we remove it or keep it in? Now that people have seen the silly effects, should we keep them in MeMa (but disabled by default) or should we just remove the entire thing, so no one can enable them? Of course, if we decide to keep it in for the final, we would really like some better looking animations than that MenuEvil.qtz thing I made. I do not have the skills of an artist. If anyone does have the skills, and is willing to let us use your work in MeMa, we would greatly appreciate it. Other Stuff Well, there's been two betas of MeMa released and still no new fansubbed episode of Detective Conan has been released. I weep. Also, please do respond in the comments here on the "keep or trash issue" and the Menu Master voluntary upgrade fee. Please state your reasons if you don't mind. Important Note: the final version of MeMa will be released super quickly fast depending on the results of this post. So I'd like to see some responses to this post by the time I wake up tomorrow. I've already been awake for 24+ hours. Although, there might be a reprieve if a new Detective Conan fansub is released.
August 06, 2008
Dear APE, I want you inside me. Love, Leopard #2: APE 2.5b2
Uhm... Well, I didn't have this post very well thought out. Usually I dwell on blog posts for weeks while in the shower, but all I had for this post was the title and the photo.  Of course, there are some exceptions. For example, Smart Crash Reports 1.5b3 was released a few weeks ago (it's also a part of FruitMenu 3.7b3 and higher). SCR does not include an updater (there's no need... yet) so I will state what's new on this post (ugh, that's not creative writing!)
Download Smart Crash Reports 1.5b3 The really big news of course is Application Enhancer 2.5b2. We really, really didn't want a repeat of what happened with older versions of APE (re: previous post). I mean, we really didn't want it. To that end, we've added an updater to APE itself. By default, it checks for updates weekly (or when the system version changes). If you install APE 2.5b2, I'd like you to change update checking (in the Application Enhancer preference pane) to daily. Some third-party APE module developers asked if they could disable the update check when the user installed their software. We have decided against allowing it to be changed on install by anyone other than the computer user. I mean, "the problem" only occurred because some third parties were shipping very old versions of APE with their products (re: previous post again). It'd kind of defeat the purpose of the updater if it could so easily be controlled by third-party software.
Download APE 2.5b2 Finally, there is a new beta of FruitMenu that includes APE 2.5b2 and SCR 1.5b3. However, you'd have to use the updater to get the new beta. We are desperately trying to get people to use the updaters. Once again, I'd like to repeat the warning stated on previous posts in this category. I'm sorry if it seems harsh, but it has to be said. Note: Please do not post comments and/or send emails asking about the present and/or future of things not mentioned in this post. Such comments will be moderated, deleted, or edited. When we have something to say about other products, it will be posted, and not a moment before then. Asking us about ETAs just ends up wasting both of our time. Apologies for taking such a harsh stance, but the only thing we would tell you is "it'll be done when it's done" and we're trying to prevent a repeat of the tens of thousands of comments/emails we've received asking for an ETA. Any kind of timeframe or ETA we could possibly give will be wrong and users get very disappointed when ETAs are missed. That's the nature of ETAs, they are always wrong. And due to the fact we won't release something before we feel it is ready, any ETA is even more likely to be missed.
On a happier note, I would like to state that SCR 1.5b3, FM 3.7b5, and APE 2.5b2 are nearly the final versions before actually being released in non-beta form. Except for the logging in FruitMenu, assume everything to be final and do not treat the software as beta quality in your mind. Speaking of the logging in FruitMenu, we are looking for any large values attached to "CreateMenuItem:" as listed in the console. We especially want to know if any operation takes longer than 200ms. This information will be used to increase FruitMenu's loading speed in the future. Price Increases Abound On a final note, the prices of the haxies are going up as the Leopard-compatible versions are released. FruitMenu, for example, is increasing from $10 to $12. The reason for this price increase is the sad state the US economy is in (seriously, Canadian funny money is worth more than the US dollar, OMGWTFBBQ?!). The price increases of other products have not been decided on yet.
February 24, 2008
Enthusiastic Trepidation
(Yes, Betas). While my previous post talked only about the past, this post talks about the present. Some of the previous post is intentionally wildly out of context if you don't read this post. And some of this post may be out of context if you don't first read the previous post. Note: Please do not post comments and/or send emails asking about the present and/or future of things not mentioned in this post. Such comments will be moderated, deleted, or edited. When we have something to say about other products, it will be posted, and not a moment before then. Asking us about ETAs just ends up wasting both of our time. Apologies for taking such a harsh stance, but the only thing we would tell you is "it'll be done when it's done" and we're trying to prevent a repeat of the tens of thousands of comments/emails we've received asking for an ETA. Any kind of timeframe or ETA we could possibly give will be wrong and users get very disappointed when ETAs are missed. That's the nature of ETAs, they are always wrong. And due to the fact we won't release something before we feel it is ready, any ETA is even more likely to be missed.
Standard Goldfish Disclaimer Applies These betas also have some significant user interface issues that will be resolved by the time their final release approaches. With that said, I wanted to talk about the current public betas for Mac OS X 10.5 we are releasing now. But, I'll do it in no specific order. APE 2.5 (and SDK)First, let's talk about the situation behind what happened with APE 2.0.1 and Mac OS X 10.5.0 (note that APE 2.0.2 was released on 2006-11-01, a year before Leopard's release, and APE 2.0.3 is the current version). Namely, specifically what caused the issue and what the issue actually was. I am hoping discussing this issue at length will restore any confidence in APE that may have been lost or at least prevent people from pointing to this issue as an argument against APE. BackgroundAPE is "burdened" by a number of restrictions placed on it. Some are the usual restrictions others are restrictions we've placed on APE from our knowledge and years of experience. Still other restrictions we've placed on APE just because it seems like a good idea to restrict APE to certain boxes beyond empirical evidence (hypothetico-deductive?). For example, "if doing something X is a bad idea, then certainly related action Y is just as bad." We also keep enforcing restrictions that were true on previous versions of Mac OS X, even if those restrictions have long since been lifted by the system itself. We try to respect the legacy. Also, whenever it is decided APE has to call a new API it's never called before, we evaluate who else uses the API on the system (especially if Adobe, Microsoft, and/or Apple applications uses the API) and the chances of a system update changing the previously documented behaviour of said API. We try to choose functions that, if they ever change due to a system update, they will fail in a spectacular and catastrophic manner. So spectacularly catastrophic that Apple cannot release the system update without breaking hoards of Mac OS X's most important applications (this is known as maintaining backwards compatibility). All of our code contains metric assloads (imperial assloads, too) of error checking and state checking code. If a function returns anything but void, an error check is made (and sometimes even if a function returns void. If something calls into a different API, a state check is made. APE contains about four point three times (if not more) state and error checks than most developers (including developers for embedded devices) would find necessary. With the result of every check being that APE stops doing what it is doing and disables itself if the check is not exactly what we expect it to be or if APE suspects the state of anything has changed. There is absolutely no room for "kind of" in APE. As an extremely abbreviated example, "this is a green tree". APE would first check to make sure the state is correct. The state being that APE is currently in an environment that can support something that lives, then something that grows (most developers would just assume their application is running above ground on the planet Sol 3, APE makes no such assumptions). APE would then error check to make sure green is a color and that a tree is organic. It would then check the state and make sure the environment has the nutrients to support organic life, then to make sure it supports the combined object "green tree" (that the wavelength of incoming light supports the chloroplasts for a tree and that the wavelength reflected is perceived as green). It would then do a bunch of other error and state checks. Of course, "this" could be a purple tree but APE has never seen a purple tree before. Therefore, APE will disable itself if it sees a purple tree. APE actually does a lot more checks and changes the order of the checks a bit, but this was just an abbreviated example. That may have been a somewhat tortured example, but it correctly describes the nature and amount of paranoia gone into the state and error checks in APE in a manner that may be understandable to most people. It's also all of I could think of at the time. Sadly, I will continue using this analogy. The Issue The problem in Mac OS X 10.5 with APE 2.0.1 is that one of the state checks APE used is rather high-level. In Mac OS X 10.5, Apple made a change so that this particular state check initializes a lot of unrelated subsystems and caches the states of those subsystems. To use the above analogy, it'd be similar to APE querying Mac OS X to determine if the tree was on Sol 3. However, instead of just loading the state of the current planet like Mac OS X 10.4 and earlier did, Mac OS X 10.5 also asks the USGS for the count of the items on the list of named lineae on Europa and then asks the IAU for the list of named minor planets around Ceres. This became an issue in that the component of APE 2.0.1 that asks for this state check happens to also be a client of one of the unrelated subsystems (configd in this case, used for synchronous notifications of specific state changes). Since configd cannot respond to a query indirectly made to itself at very specific times, this created a race condition that could result in the login process deadlocking. This problem was not caused by a failure or bug in APE's code. (configd accidently and indirectly asked a question of itself and refused to answer until the question was answered by itself.) Due to it being a deadlock, the login process would never continue on Mac OS X 10.5 with APE 2.0.1 installed, no matter how long the user waited. Note: This particular state check is explicitly documented by Apple as being thread-safe, but we do not call it from multiple threads anywho. I wish to remind everyone at this point that APE 2.0.2 was released on 2006-11-01 and that APE 2.0.3 is the current non-beta version. This problem should be reproducible in a stand alone application. I've spent a few hours on it here an there, but could never get the threads to align with the moon in just the right way to reproduce the race condition. After a few hours with no results, I stopped trying to reproduce it as I realized I had better things to do than try to make a new project, reproduce the deadlock, and send a bug to Apple. Especially since I knew Apple wouldn't be able to reproduce it due to the nature of race conditions and immediately close the bug as "cannot reproduce". Sadly, no amount of error checking or state validation on our part could have prevented this issue. It was not a situation we could have tested for as the fact it occurred at all was happenstance. So you found this problem and fixed it for APE 2.0.2, right?Yes and no. No and yes. Since the problem only occurred on Mac OS X 10.5 with APE 2.0.1 and not later versions, we looked at what changed in APE 2.0.2 and later that prevented ("fixed") the problem. Turns out that while we were trying to find a workaround to include in APE 2.0.2 for the horrible Rosetta bug, we had realized that if this particular state check (the one in the above section) was ever false, many of the other state checks before it and after it would also be false. Therefore, we could move this state check to a much, much, much earlier place in the code as it was a type of "master control" for other state/error checks. Moving the state check to such a location made the initialization of the completely unrelated subsystems that happens on Mac OS X 10.5 occur at a time at which no race condition could occur. Furthermore, by the time we moved the state check for APE 2.0.2 (which was around September or early October 2006), the Mac OS X 10.5 seed that developers had was virtually unusable. It would either kernel panic often or couldn't be installed on our development machines due to bugs in the seed. And if we happened to find a machine that it could run on for a while, applications crashed often. And this is all on a completely clean install, with no third-party software installed on it. So we never got chance to find out about this problem before APE 2.0.2 was released. Then again, I'm not sure the problem would have occurred on that seed of Mac OS X even if APE 2.0.1 would have gotten that far. The changes to all the various subsystems in Mac OS X 10.5 between October 2006 and October 2007 (when Mac OS X 10.5 was finally released) were very significant. Some components were completely removed from Mac OS X 10.5 in that time and some brand new components were added. Basically, we were not aware of the problem when we implemented the workaround. So it was a coincidence that the problem is addressed with APE 2.0.2. It is important to mention this now before I discuss some other things. Important Note: If, for whatever reason, you want to stick with APE 2.0.1 (and don't want to install APE 2.0.3 or APE 2.5b1) and you are running Mac OS X 10.5.0, then install the Mac OS X 10.5.1 update or the Mac OS X 10.5.2 update to address this issue. After installing Mac OS X 10.5.1, you will no longer have this issue if you have APE 2.0.1 installed.
Despite the fact that the issue was completely addressed by APE 2.0.2 (released on 2006-11-01), for APE 2.5, we decided to look for an alternative API to get the same state information; one that was not as high-level as the one we used previously (read above for low-level vs high-level discussion). Luckily, such an alternative API exists in Mac OS X 10.4 and Mac OS X 10.5. (You may notice that APE 2.5b1 and all the betas listed in this post now require Mac OS X 10.4 or later). This alternative API fits within all the requirements and restrictions I mentioned APE has above, especially the catastrophic requirement. This new API is also what the higher-level state check we used to use eventually calls to actually get the information we requested. This new API also has a super bonus failure check built directly into it, automatically adding more error and state checking. So it matches our design philosophy quite well. Yay! Why didn't you test APE 2.0.1 with Mac OS X 10.5 before Leopard was released?This is a question we've gotten from a few people, but I've never understood why it would be asked since APE 2.0.2 was released on 2006-11-01 and APE 2.0.3 is the current version. Note that the question is phrased here exactly as it was asked by these people. The question was not edited to be more APE friendly. First, assuming we could have tested it, why would we? APE 2.0.1 was replaced a year before Mac OS X 10.5 was released. If we would have tested it and found a problem, what would our recourse have been? To release an update to APE 2.0.1...? We already did that a year beforehand. All of our haxies have built in software updaters. If the user didn't choose to install any updates that include APE 2.0.2 or later in that year, they wouldn't have installed an update that was released with nothing but a bumped version number (as a form of lip-service). Well, they wouldn't have seen it since our software update has no method of ignoring updates and they would have had to have turned off the updater. And there are, of course, third party APE Modules and third party utilities that install APE. If these products were updated since APE 2.0.2 was released (since 2006-11-01), they should have made sure their products included the latest version of APE available at the time. Actually most, if not all, of these third party softwares do make sure to include the latest version of APE with their new releases. It's the primary reason why the APE installer is packaged into such an easy to use and easy to distribute file. This single file has all the logic to install, remove, validate, repair, and update APE built right into it. It also allows us to work around bizarre bugs in the system that are necessary to workaround for APE's sake. This is also why we do not permit third parties to modify the single file APE installer itself. If a third party wishes to make sure they have the latest APE installer in their product, they just install the latest APE SDK. Then they drag and drop the single file installer into their project/installer. The APE SDK also installs the latest version of the non-SDK APE installer to /Library/Frameworks/ApplicationEnhancer.framework/Tools/, so a lot of developers just make copying that file into their installer part of the build process (via Xcode's run script build phase). Doing this means they always make sure they have the latest installer included with their products. Secondly, even if we wanted to test APE 2.0.1 (as opposed to APE 2.0.3) on Mac OS X 10.5 before it was released to users, we couldn't have. Developers got the ability to download the final build (~6 gigs) of Mac OS X 10.5 at around 3pm on 2007-10-26 and the final developer documentation was not available until around 2007-10-31. Before that, developers weren't allowed to discuss Leopard, even if they had a purchased copy of Mac OS X 10.5 from a store (read that thread, if you have the time or the interest). And the two seeds released to developers before the final (9A559 on 2007-09-21 and 9A527 on 2007-08-24) had a very significant bug that prevented APE (any version) from working. Those versions of Mac OS X 10.5 refused to respect the security restrictions APE was asking for. Because this was a very significant bug, and involved security, we had no reason to believe it wouldn't be fixed in the final Mac OS X 10.5 release. (Yes, it was fixed by the final 9A581 build of Mac OS X). Due to the nature of this bug, APE versions earlier than the custom build for Mac OS X 10.5 we were using wouldn't have been able to get anywhere. Thus, there was no way to test APE 2.0.1 (or 2.0.2, for that matter) as the bug guaranteed they would not load. If, for some bizarre reason, this bug was not fixed in the final build of Mac OS X 10.5, then at that time we would have figured out a way to work around it and make Mac OS X respect the security restrictions we wanted. We would have done it then, and only then, because when Apple ships a bug in a major version of Mac OS X 10.y.0, it usually stays there until NMOS or NMOS+1 for backwards compatibility reasons. (Also, because it can be hard to convince the manager at Apple in charge of the component with the bug to let an Apple engineer work on fixing the bug and then ship the updated component in a Mac OS X 10.y.x>0 update). Luckily, because this bug (the one in 9A559 and 9A527, possibly earlier seeds) created an impossible state in Mac OS X (one that violated documentation, common sense, and a few standards), we were able to add even more error checking to APE. As discussed above, we like to add error checking code. There's no reason for us not to test for theoretical cases of failure; you should never test for theoretical success, only success you can verify in practice. Finally, who's to say we didn't test APE 2.0.1 (as opposed to just APE 2.0.3 or just APE 2.0.3 and APE 2.0.2) on every seed of Mac OS X 10.5.0 that we were capable of testing against? This state check subsystem initialization behaviour may have only been introduced in the later seeds of Mac OS X 10.5.0, preventing any kind of testing by us from finding it. Please do not assume we did not do as much as possible. I'm sorry if this section sounded overly harsh, but the question is it attempting to answer is a great example of a loaded question. The person asking the question is generally asking it in a rhetorical manner and does often not actually want or care for an answer. Alternatively, they ask it as fully knowing there's no way we can answer it without looking bad or as if we did something wrong, they've already decided what the conclusion is. Thus, it is a loaded question. If the situation was reversed and we asked the questioner a similar question, but one that fits their situation, they would also be at a loss to answer it as we are. The saddest thing about all of this is that we didn't even know there was an issue until consumers started getting Mac OS X 10.5 in their hands. By that time, it was all over the internets. And there was so much conflicting information that we were unable to understand the situation for a very long time, let alone reproduce it. However, we did update our website to show that APE 2.0.3 did not have the issue as soon as we were told about it (before we could confirm the issue in older versions) and we sent out a notice to everyone subscribed to our mailing list as soon as we could (which was again, before we could reproduce the issue or fully understood it). Due to the huge number of people subscribed to our mailing list, it took two to five days for some people to get the email and by then the story had spread all over the place. Why do y'all keep repeatedly saying APE 2.0.2 was released on 2006-11-01 (a year before Leopard was released) and that APE 2.0.3 is the current version?We mostly keep repeatedly saying that APE 2.0.2 was released on 2006-11-01 (a year before Leopard was released) and that APE 2.0.3 is the current version to drive home the fact that APE versions released in the past 16 months do not have this issue. Furthermore, anyone that's updated APE in the past 16 months would not have this issue. We also really want to convey to people that this issue was addressed long before we knew about it or could know about it (see above and below). A tangential reason for the repetition is that we really want to stress the importance of keeping software up to date. This applies to all software, not only APE. End users can use software tracking sites such as MacUpdate.com or VersionTracker.com. Developers should attempt to add software update checking into their own applications. They can either use a custom rolled solution (such as we do, since our requirements may be "unique") or use an extremely easy to integrate, open source updating framework, such as Sparkle. Yes, our custom updater does need a bit of work and polish, but that work will be done when we have more time to allocate to the task. I upgraded to APE 2.0.3 and I'm still having this issue || I completely deleted all traces of APE from my computer, yet APE is still causing this issueNo, you aren't still having an issue related to APE 2.0.1. There are a few changes to Mac OS X 10.5 that make it seem like something is failing, a blue screen appears for too long, or that login time is taking excessively long. I'll list some of the issues that could be confused with this one, but are unrelated to the problem APE 2.0.1 people experienced (note that APE 2.0.2 was released on 2006-11-01, a year before Leopard's release, and APE 2.0.3 is the current version). Mac OS X 10.5.x no longer shows a progress bar when booting. I think this is the biggest thing people attribute to a problem with APE. When people booted their computer box and it was running Mac OS X 10.4, the user would see a progress bar after the gray screen with the Apple logo. After the progress bar window disappeared, it would show the login window after a very short time of sitting at a blue screen. This progress bar was fake. It had nothing to do with how long Mac OS X 10.4 would actually take to boot. It was simply a program, /usr/libexec/WaitingForLoginWindow, that appeared for the amount of time the previous boot took to complete (this time value was stored in /var/db/loginwindow.boottime). It was absolutely nothing but a placebo there to make the user think progress was occurring. In Mac OS X 10.5, the boot process has changed a bit. WaitingForLoginWindow and /var/db/loginwindow.boottime are gone. Since launcd on Mac OS X 10.5 no longer supports explicitly listing dependencies and has no StartupItems, there is no reason for the fake progress bar during boot. All launch daemons are launched on demand and in an asynchronous manner. If a launch daemon has an implicit dependency (say it requires a service that another daemon provides) then the launch daemon will block ("pause") until that service is available. As soon as the service is available, the daemon will continue. This allows for multiple daemons to be launched simultaneously and to do as much work as they can before they need another service to be available. All of this leads to a significantly decreased boot time, further obliterating the need for a fake progress bar. The BootCache. Because loading multiple simultaneous daemons for startup can be slow, Mac OS X has an extensive boot caching mechanism. This caching mechanism is stored in a file, /var/db/BootCache.playlist. This cache significantly decreases the boot time of Mac OS X. This caching mechanism is surprisingly well documented in the BootCache.kext source code. If the BootCache.playlist file is outdated, old, or unavailable, the time a user sees the blue screen on Mac OS X can more than double. You can actually reproduce this yourself, if you so desire. At least, you can reproduce the longer blue screens display to prove to yourself that it's one reason you may see a longer blue screen irregardless of whether APE is installed. Simply reboot twice and measure the time the blue screen appears for. Then, open the terminal (/Applications/Utilities/Terminal) and run the following command: sudo rm /var/db/BootCache.playlist and reboot a final, third time. Time how long the blue screen appears for. It should appear for about 170% to 200% longer than it used to. The /var/db/BootCache.playlist is automatically regenerated on boot. If Mac OS X ever determines the BootCache.playlist is being a lying liar or isn't decreasing the boot time at all, it will ignore it and regenerate a new one. This is also why you see longer blue screens after installing an update to Mac OS X 10.5.x. If you wanted to reproduce a no progress bar, extremely long blue screen on Mac OS X 10.4, you can open the terminal (/Applications/Utilities/Terminal) and run the following commands (they are on two lines, they are two commands): sudo rm /var/db/BootCache.playlist Then reboot. When you are done playing around and want to restore the original behaviour, type: cd /usr/libexec/; sudo mv WaitingForLoginWindow.ignore WaitingForLoginWindow DiskArbitration. As I mentioned above, Mac OS X 10.5 has a lot of implicit service dependencies. Before the loginwindow can appear, and the blue screen can disappear, anything the loginwindow depends on must be up and providing its service. The loginwindow depends on DiskArbitration (diskarb) to be working before the blue screen will disappear. The problem is, diskarb freezes a lot. Especially if you have external FireWire or USB hard drives connected and their bridge boards are particularly shoddy. Diskarb will completely deadlock the machine until those disks are disconnected from the computer or the disk requests time out (whichever is shorter). This may explain why some people will reboot Mac OS X 10.5 once, see a blue screen forever, reboot, then no longer have a blue screen. Disks usually start responded when they are disconnected or the system has to requery them (which happens on a reboot). In fact, I have a SATA to USB bridgeboard that thrusts Mac OS X 10.5 into a blue screen 90% of the time, regardless of which computer I test it on. Perhaps I should send this bridgeboard to Apple so they can make diskarb handle this situation better. Bad Network Devices. One or more of the loginwindow dependencies also query the network to see if it is up. If DHCP is on, it may also query DNS in order to see if your computer has a hostname (to display in the loginwindow, syslogd, in terminal prompts, and some other places. However, the default connection establishment timeout on Mac OS X is somewhere between 10 and 15 minutes. This means that, on shoddy networks, borked routers, or in otherwise weird networking situations, Mac OS X 10.5 may show a blue screen for up to 15 minutes if the network cannot be traversed. After the timeout is hit, an error is returned to the API and the Mac OS X 10.5 booting resumes normally. This would explain some of the reports of Mac OS X 10.5 taking 10 to 15 minutes to boot. I've personally seen this in a lot of hotels and conferences when the network was down or overwhelmed with requests. This is especially annoying when trying to compile code using xcodebuild as it uses NSHost to try to resolve the current domain name of your computer box even if distcc is disabled (which is considered a bug). It's extremely annoying when you want to compile something but have to wait for the 10-15 minute timeout to expire before anything will start compiling. Application Enhancer 2.5b1 and APE SDK 2.5b1As I was trying to explain in my previous post, APE 2.5 will not load any APE module that has not been explicitly marked as compatible with Mac OS X 10.5. See my previous post for reasons on why. We discussed the issue with some other APE Module developers and they agreed that old modules should be disabled. Especially since it's been over 2 and a half years since Mac OS X 10.4 was released and some of these APE Modules haven't been updated since then. If an APE module cannot be loaded, for whatever reason, the APE Preference Pane will now show the listing why it cannot be loaded. The APE Prefpane now uses the same logic to determine why something won't load as APE itself. Previously, APE itself would have a bunch of undocumented checks and there would be no way for a user to determine why their APE Module wasn't working. The SDK documentation has also been clarified to mention the APEBundleMessage callback is not called on the main thread. If you need to call functions that are not thread-safe, call them on the main thread using something like MPRemoteCall. Not doing so can lead to unexpected behaviours. It's been an issue in the past, which is why it is now explicitly documented. Also, the SDK documentation now has a listing of all the Info.plist keys available to APE Module developers as they were never documented before and some are required for an APE Module to be loaded.
So here are the download URLs for the betas, finally. Download APE 2.5b1 Smart Crash Reports 1.5b2 I am repeating this as I find it to be very important. Important Note: On Mac OS X 10.5.x, InputManagers must not be installed in the user's home folder (~/Library/InputManagers/) as it will prevent the InputManager from loading even if the InputManager is installed globally in /Library/InputManagers/ and meets all the requirements to load. If you are a developer installing an InputManager, make sure your InputManager is not in the user's home folder on Mac OS X 10.5.x and move it to the trash (FSMoveObjectToTrashSync()) if possible.
Download Smart Crash Reports 1.5b2
FontCard 1.5.1b1 Please Note: FontCard 1.5.1b1 has not been "certified" for use with Adobe CS3 products (it should work, the worst that will happen is that it won't work). Furthermore, it does not work with Microsoft Office 2008 (the worst that could happen is explosive projectile vomiting). We have not yet acquired these products, therefore we have not tested them with FontCard. FontCard 1.5.x currently has a lot of code for Word v.X and Word 2004 to work around various "quirks" in Microsoft Office. I would not expect FontCard 1.5.1b1 to work with Microsoft Office 2008.
Menu Master 1.4.3b1 Also, Menu Master had to work around a lot of bugs in Mac OS X 10.4 with certain types of windows. Either the bugs were fixed for those certain types, or the bugs remain. Either way, Menu Master still does what is correct for all types of windows.
Silk 2.1.4b1
FruitMenu 3.7b1
WindowShade X 4.2b1
Final ThoughtsRemember, these are beta. All of these betas include SCR 1.5b2 and APE 2.5b1, so they do not have to be downloaded separately. APE 2.5b1 may also have some fixes for APE not enhancing some applications on Mac OS X 10.4.x in some cases. Note: We are currently evaluating raising the prices to some of our products. A number of factors contribute to this, including the weakness of the US dollar (I mean, seriously, funny money from Canadia is worth more than the USD). But if this happens, it'll only start to apply when these things go out of beta. The prices for these betas are the same as they have always been. The only change would occur when these things come out of beta and are at a final release. But seriously, Canadian funny money worth more? Sorry it took so dang long to post these, I've just been various amounts of "not well" for the last few weeks. Sigh, I wish I could ask various doctors on the internets for samples of the sweet blue pill known as Lunesta. Alternative title to this post was, "Dear APE, I want you inside me. Love, Leopard" |
Archives
February 2010
January 2010 October 2009 June 2009 April 2009 September 2008 August 2008 February 2008 November 2007 October 2007 July 2007 May 2007 April 2007 March 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002
Recent Entries
Betas, Twitter and WTF
Mighty Mouse with Some Theme Sauce Welcome back. Spectacular Catastrophe: WindowShade 4.2b2 Feel the Heat That's All Around You; Flashing Lights and Ecstasy Surround You: The Silly Effect and John Gruber Purified Chicken Embryo Cell, The VUF, and Menu Master Beta Dear APE, I want you inside me. Love, Leopard #2: APE 2.5b2 Enthusiastic Trepidation
Search
About...
Syndication
Disclaimer
Views and opinions expressed on this site are personal views and opinions of members of Unsanity LLC. They do not necessarily coincide with the official company views and opinions.
| |||||||||||||||||||||||||||||||||||||||||||||||||
Posted by slava at 
Posted by jason at 
Posted by rosyna at