(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.
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.
Background
APE 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.
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 issue
No, 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
cd /usr/libexec/; sudo mv WaitingForLoginWindow WaitingForLoginWindow.ignore
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.5b1
As 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.
- Added compatibility for Mac OS X 10.5.
- APE now requires Mac OS X 10.4 or later and will not install on older versions of Mac OS X.
- Application Enhancer will now refuse to load any APE module that is not marked as compatible with 10.5 on Mac OS X 10.5.
- Addressed some problems with some unpatchables due to the wonkiness of the x86 ABI (Includes APELite).
- The APE prefpane now shows why some APE modules cannot be loaded.
- Removed all references to the Rosetta workaround as Apple fixed that bug in Mac OS X 10.4.9 and the workaround no longer has any beneficial results.
- Worked around a prebinding bug in Mac OS X 10.4.10 and earlier that made APE treat some applications as if they were on the exclude list.
So here are the download URLs for the betas, finally.
Download APE 2.5b1
Download APE SDK 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.
- Updated to support Mac OS X 10.5
- Now supports registering for SCR in Info.plist entries of bundles (Frameworks, QuickTime plugins, Photoshop plugins, Safari plugins, et cetera). Developers no longer need to call UnsanitySCR_RegisterMatchSpecifier() bundles (in most cases).
- SDK: UnsanitySCR_Install now installs Smart Crash Reports with the correct permissions required to work on Mac OS X 10.5.
- SDK: UnsanitySCR_Install now pretends as if SCR is not installed if it is installed inside the user's home folder on Mac OS X 10.5.x as Mac OS X 10.5 will not load SCR from the user's home folder. Behaves as before on Mac OS X 10.4.x.
- SDK: Worked around a problem on Mac OS X that led to repeated calls UnsanitySCR_RegisterMatchSpecifier creating new entries in SCR's preferences when Mac OS X thought that two equal CFTypeRefs were not equal.
- SDK: On Mac OS X 10.5.x, UnsanitySCR_Install no longer allows you to install in a non-global manner due to the new restrictions in Mac OS X 10.5.x. Behaviour on Mac OS X 10.4.x is unchanged.
- Important Note: On Mac OS X 10.5.x, Smart Crash Reports must not be installed in the user's home folder (~/) as it will prevent SCR from loading even if SCR is installed globally. If you are a developer installing SCR, make sure SCR 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.
- Added support for Mac OS X 10.5 Leopard v10.5 and later.
- No longer loads Objective-C dynamically.
- Updated to SQLite 3.5.4.
- Now attempts to open third party font sets in read-only mode (possible thanks to SQLite 3.5.0). FontCard never intended to write to third party font sets, only read them.
- Now sorts third party font sets in the font panel (10.5 only).
- FontExplorer stores its database in a different location if your user home folder path does not begin with "/Users/". FontCard now loads FEX sets in these situations.
- Installs a busy handler for FontExplorer sets. This should fix a race condition leading to an error if the FontExplorer application is in the user's login items.
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.
- Added support for Mac OS X 10.5 Leopard v10.5 and later.
- Dropped support for Mac OS X 10.3 Panther. Menu Master now requires Mac OS X 10.4 Tiger v10.4.11 or later.
- No longer loads Objective-C dynamically.
- Removed calls to many deprecated APIs.
- No longer scans menu items if their titles are NULL or zero length due to an issue cause by the inefficiency of Cocoa menus.
- Potentially addressed an issue with Adobe applications losing custom menu shortcuts when switching documents or not listing all their menu items in the Menu Accelerator window. This required a lot more work than it should have.
Silk 2.1.4b1
- Silk now runs on Mac OS X 10.5.
- Dropped Mac OS X 10.3 support. Silk now requires Mac OS X 10.4.11 or later.
- No longer dynamically loads Objective-C.
- Moved a lot of code to the awesomely awesome CoreText APIs (10.5 only).
- Adjusted some code so it can be moved to CoreText in the future.
- Attempted to make Cocoa applications respect the baseline of a font when a custom theme font is used.
- Note: Classic is not supported in Mac OS X 10.5 and the fonts in the Classic fonts folder will not be loaded by Mac OS X. You may have to adjust your Silk settings to address any missing fonts.
FruitMenu 3.7b1
- Added support for Mac OS X 10.5 Leopard v10.5 and later.
- Dropped support for Mac OS X 10.3 Panther. FruitMenu now requires Mac OS X 10.4 Tiger v10.4.11 or later.
WindowShade X 4.2b1
- Added support for Mac OS X 10.5 Leopard v10.5 and later.
- Dropped support for Mac OS X 10.3 Panther. Windowshade X now requires Mac OS X 10.4 Tiger v10.4.11 or later.
Final Thoughts
Remember, 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"
Posted by rosyna at 10:24 PM
| Comments (143)
| TrackBack (4)
Related:
- Hiya Kids, it's Theming Time! - Oct 06, 2009
- Mighty Mouse with Some Theme Sauce - Jun 02, 2009
- WindowShade X 4.3 - Apr 24, 2009
- Sound of the Underground - Apr 20, 2009
- Welcome back. - Apr 17, 2009
Today, I clear my mind, and beta I install. Process at end of, this I see:
"We strongly you recommend restarting your computer now."
This rip off I believe of my signature style. Remove this, you must, or hear from my lawyers, you shall. The force does not run strongly in this installer beta of!
Posted by: Yoda on February 24, 2008 11:51 PMThis a very poor attempt at summarizing the above post:
Some of the delays were due to technical issues that had to be worked out, and some were due to various life issues that prevented proper development for stretches at a time.
Thanks to all of you for your patience, and for sticking with us through all of this (and through the above post! whew!).
Posted by: Joseph Bermann on February 25, 2008 12:50 AMThank you for the feedback and the betas, guys.
But I'm sad to see that the main reason why I use WindowShade is gone: the ability to get rid of the annoying window shadows. I hope this feature come back in future updates.
Posted by: João Carlos de Pinho on February 25, 2008 3:09 AMThank you very much. I really miss FruitMenu and WindowShade. Labels X would be welcome, and I'll look forward to the day when it is available.
I think Unsanity is the most talented (not to mention by far the most articulate) programming team working on OS X. Apple should just hire all of you, but then maybe we wouldn't have the haxies that make our lives better.
Спосибо большое и всего хорошего!
Posted by: David Derbes on February 25, 2008 4:11 AMThank you so much. Fruitmenu, Windowshade, Silk and Menu Master all load up fine and do their jobs without any glitches.When the full version comes out, remember to add a donate button for those of us who are already registered and want to contribute to Unsanity's continued efforts. Spasiba bolshoi, indeed.
I may have missed it (or don't remember), but should all previously installed haxies be removed before using the betas? Especially those that may not be able to be updated.
Posted by: David Spatz on February 25, 2008 6:54 AMDavid Derbes: Apple should just hire all of you, but then maybe we wouldn't have the haxies that make our lives better.
If Apple hired Unsanity's staff, maybe we'd get a better OS X that wouldn't need haxies.
Posted by: Anonymous Prime on February 25, 2008 8:02 AMI have long stated to Unsanity to cease their insane policy of upgrades, and to start charging a fair price for upgrades. I have been telling Unsanity this for at least a couple of years now. The reason is purely selfish on my part as I want to see Unsanity products well into the future; the only means of truly accomplishing this is not to work for free, but to be fairly compensated. Over the past several years there has also been an ugly trend among of the Mac community with the "something-for-nothing" Mac user who feels they are entitled to everything and whom has become viciously vocal about it too.
Stop the insanity Unsanity, and please start justly compensating yourselves! There is no better time than now. Please do not use the honor system with end users, simply implement it as a bloody upgrade and be done with it. The value I have received from my Unsanity products far exceeds what I initially paid for them.
Posted by: F451 on February 25, 2008 8:45 AMWOOOO-HOOOO! WindowShade at last. Danke schoen, darlings. Danke shoen.
Posted by: Jason Fox on February 25, 2008 9:24 AMOh God, or oh dear Unsanity.
My life is back to normal. Thanks.
I feel "normal" again.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Thanks for all of the updates and I'd also be fine with paying for the Leopard upgrade if it meant getting FruitMenu back...
Oh, get well!
Thanks for the explanation of how Tiger and Leo boot. As for the rest of it, you checked so many states but skipped the simplest one: OS version which could be handled rather easily:
switch:
case version unchanged then continue load
case minor version change then if newMinorOSFlag does not exist, write flag; continue load. if newMinorOSFlag (an else) exists (reset happened). Skip load, display explanation in GUI.
case major version changed, skip load, display message in GUI, offer option to override and load anyway. See if load fails and if can be determined, turn off override to prevent loading again.
end switch. (exit process would remove any needed flags, of course)
GUI code would, of course, be the sysPref. Pretty simple "tree attribute." The rest of this was just a typical coder pointing fingers in as many places as possible (but himself/themselves). After so many major releases, I would think people who write software that plays with Apple's system (hooks and patches) would presume things will break with a major release (no matter how many states you check) and react accordingly. And, making your code Sparkle should be in everyone's code (or another flavor).
Posted by: Pecos Bill on February 25, 2008 1:33 PMPecos Bill, APE checks this and always has. It'd be silly not to.
Of course, you may not remember what happened around March, 2005. So many people wanted to have Tiger that they modified their Mac OS X 10.3 install to think it had 10.4 installed, thereby making this OS X check untrustworthy (this topic also came up on a few developer mailing lists, back then)
Posted by: Rosyna on February 25, 2008 1:52 PMYou guys remember me I'm sure, I'm the "Labels X agitator" guy. While I'm happy to have Menu Master back (beta, I know) I am really hoping you can pull off something nice with Labels X in 10.5. Those round bubbles of color are so Fugly!
Posted by: Peter Payne on February 25, 2008 4:57 PMWould removing the "more ->" be possible through FruitMenu and having a single Finder CM?
Posted by: dave on February 25, 2008 5:22 PMThank you. It waits and ..
...development.. thank you very much for Leopard.
Please let me report when some trouble etc. are found.
FontCard and MenuMaster are such enormous productivity-enhancers for me, I would be willing to put up $15 or $20 for the final Leopard updates, especially if you'll rebirth your t-shirt on American Apparel or similar for a good price.
Posted by: Earthsaver on February 25, 2008 6:12 PMTHANK YOU THANK YOU THANK YOU X 1,000,000,000! I have missed Fruit Menu and Window Shade immensely since upgrading to Leopard. The Beta's work Beautifully!
Posted by: LogansRunRox on February 25, 2008 7:37 PMThanks for the updated betas. Fruit menu does have one tiny problem with Expose. When you switch windows the drop down menus are dimmed and only become responsive by clicking on the desktop.
Posted by: Mac007 on February 25, 2008 7:40 PMMenuMaster & Windowshade are working great for me, thanks! But FruitMenu is acting up. As soon as I click on the Apple menu, the system pauses and whatever app I'm in quits (even the Finder). It seems to be working for Geoff above, so maybe it's a compatibility issue with something else on my system.
Glad to see you back, Unsanity!
Posted by: Lefty on February 25, 2008 7:42 PMFruitmenu reliably crashes the Finder when clicking on the black Apple icon, but Windowshade and Silk betas seem to be working OK, although Silk for some reason, in some applications uses the bold italic variant of the font I chose. But as soon as Fruitmenu is stable, I will be a very happy camper. I guess patience is a virtue after all.
Posted by: Ishan Bhattacharya on February 25, 2008 8:22 PMNo problem with Fruitmenu at all, but MiP in Windowshade gets confused by Spaces - where is the Bottom Right Edge when you have Spaces operating? However, I repeat, it's so great to have the haxies back so that Leopard operates properly! ... Now, if only we could get rid of the 1" sidebar and if the dock would just open a folder if you clicked on it (although 10.5.2 has improved that experience).
Posted by: Geoff on February 25, 2008 11:27 PMThank you for the beta versions. I am using WindowShade and FruitMenu. Both working great on 10.5.2. 2.2GHz MacBook.
Posted by: dxtr on February 25, 2008 11:44 PMI can echo the FruitMenu crash when clicking the Apple Icon. (10.5.2, MBP). All goes away leaving Desktop empty. No problem with WindShade.
Posted by: Mike on February 25, 2008 11:50 PMAll working well here with WS, FM - but I echo the above comment: is there some way to move the FM items into the main contextual menu, and not have them in the More... section? That would be a splendid thing!
Posted by: Padmavyuha on February 26, 2008 12:01 AMsomething in silk ennable the translucent/transparent menubar on unsupported hardware.
Any chance for a free haxie for this? people with old G5 will thank you.
Posted by: Mr Eko on February 26, 2008 5:12 AMAt least it's just our money that looks funny. ;)
Seriously, when you conquer the hill, who cares what you look like?
Posted by: Proud Canuck on February 26, 2008 7:08 AM"FontCard and MenuMaster are such enormous productivity-enhancers for me, I would be willing to put up $15 or $20 for the final Leopard updates, especially if you'll rebirth your t-shirt on American Apparel or similar for a good price."
What they said. Exactly. Thanks!
Posted by: Kee Hinckley on February 26, 2008 8:03 AMFINALLY!
I installed FruitMenu, Label-X, WindoShade: yes they do have few bugs, but so far nothing life threatening. And definitely better than not having them at all.
Looking forward to Label X...
And agree with one of the commenter above: Apple should hire all of you guys.
I agree with the upgrade comment. I paid $5 for Fruit Menu when Apple stock was practically free. I'm willing to kick in some bucks for an upgrade. And yes, Apple should hire these folks...and a communications coordinator to keep their blog posts fresh!
Posted by: Rick and Julie-Anne Reed on February 26, 2008 4:11 PMRegarding the Finder and System prefs crash pointed out above: I deleted the Finder Prefs, System Pref's Prefs and FruitMenu Prefs and that issue went away!
Hope this helps to you posters with this problem.
Yay, that Unsanity is back-great developers-great products!
Posted by: Phil Hubbard on February 26, 2008 5:02 PMI did not upgrade to Leopard because I didn't want to live without FruitMenu, WindowShade X, Menu Master and Labels X (and ICeCoffEE too). So now I can finally upgrade. Thank you very much!
Posted by: Štěpán Kříž on February 26, 2008 5:11 PMFONTCARD YAHOOOOO!
I think the alternate title for the post is way better.
Is there any way to sign up for e-mail notices regarding the release of Leopard compatible software per product? I just REALLY want to know about fontcard. ...and eventually ShapeShifter.
Posted by: on February 26, 2008 7:14 PMJust waiting on that magical notice of a shapeshifter beta so that I can upgrade. You guys just checked everything else I've been waiting for off my list.
Posted by: adin on February 26, 2008 10:49 PMThanks for the updates. Like others here I'd be happy to pay extra when final versions of are released. Maybe it could be voluntary so you're not breaking your "no paid upgrade" promise.
Note for the future. While it may seem like letting people know what the problems with a new OS are will just lead to lots of questions, not letting us know just makes your customers pissed off. Honestly, your previous update could have been sent out months ago.
I will keep APE beta installed even while there is no beta of my products yet. Just to help with any issues (if they happen at all).
Thank you people!
Very clear story. Worth the wait. FM and WS working flawless on 10.4.11 & 10.5.2 PPC.
Thanks
Another thought - it seems that the cause of this leopard BSOD issue could have been avoided if APE (like all the other Unsanity haxies that run under it) were built with an update checker in it. It would be sensible to include one in there and have it turned on as the default, so people can (a) keep pace with recent developments and improved stability if they choose to, and (b) be alerted to the fact that it's installed in the first place, if it's been installed by a '4th party' developer without them knowing.
Posted by: padmavyuha on February 27, 2008 6:30 AMGreat reading. So nice to see something actually pop up after typing "windowshade leopard" into google every morning since I bought my MacPro in January.
I strongly support the alternate post title.
Also - go ahead and raise prices. Do what you gotta do. I bought Windowshade X a few years ago for all 8 macs in our art department, but after living without it for the last 6 weeks or so, I realize I am just fine paying whatever you ask.
thankyouthankyou.
Posted by: endub on February 27, 2008 8:43 AMI am with Mr Eko. We need a free haxie to do what silk does to the Menubar. My "unsupported" mac looks great with the transparent menubar. Actually, I would love to know if there is some sort of setting that Unsanity has found which could be enabled so that I would not seed Silk. I use other haxies, just not silk as I don't need what it does.
Posted by: Joe on February 27, 2008 5:05 PMThanks for updating these wonderful haxies. I've missed them.
I am sad to see some folks have criticized you harshly. You have made some superb contributions to making a great computer even greater.
After a quick visit to your web site a few weeks ago, it was clear you are working on updates.
Bravo to the Unsanity Team!
As a paying customer of WindowShadeX, I'm happy to report that the beta works on my Leopard machine. Thanks for all the hard work. It sounds like a nightmare!
-- ge
Posted by: George Entenman on February 28, 2008 6:53 AMI'm now getting consistent Finder crashes with FM installed when accessing the apple menu. Tried deleteding prefs, resinstalling etc. with no luck.
PH
Posted by: Phil Hubbard on February 28, 2008 7:09 AMI have had zero problems with WindowShade X, FruitMenu and the new APE. This is a brand new Mac Pro, 2.8 GHz, 4GB RAM, running OS X 10.5.2, and very few other OS addenda (maybe none but Unsanity's.)
Всё хорошо.
Thanks again, and if you decide to charge for the updates, no problem. Your software is woefully underpriced. All of your fans want you to continue to produce this wonderful software, and support yourselves in a decent manner.
Posted by: David Derbes on February 28, 2008 7:23 AMI trust that when the gold versions, non-beta, are released, we'll receive an e-mail announcing that?
I'm gonna pass on the betas and just wait for your usual great work on the gold releases.
Posted by: David on February 28, 2008 7:30 AMI'm happy to report that Silk and Adobe CS3 seem to be cooperating. (This was not the case with previous versions of either.)
Posted by: Joseph Moore on February 28, 2008 7:57 AMThanks for all the details. I'm still on 10.4 but I have been having problems with WindowShade crashing when trying to minimize-in-place windows of some modern Java programs. Do you think the betas would help this or is it probably not related? (currently Ape 2.0.3 and WindowShade 4.1.2).
Posted by: idea2go on February 28, 2008 8:09 AMi love the new icons (APE, FruitMenu and WindowShade)!! Hope you keep this new style for the future releases...
Posted by: Richard Hess on February 28, 2008 8:19 AMJust downloaded windowshade beta 1 on my MacbookPro. Thank you, Thank you, Thank you!! Tried it on one window so far. IT WORKS!
Posted by: itasarah on February 28, 2008 8:20 AMBecause I'm currently sending the mailing list out to 24k people, I won't have much internet access for the next 2-5 days (the DNS lookups kill my router).
Anywho, for FM, the email I sent out has a possible workaround. Disable image previews. User's that reported the crash when opening the apple menu (which occurs on user input, is easily traced back to Fruitmenu, and can be worked around and thus not considered catastrophic), have also reported it stops if they delete their FM prefs. Doing so sets FM's settings to default. We're trying to track down the cause of the crash now and the specific setting that triggers it.
Most people (including us at Unsanity) have not experienced this crash. Some users have send us their settings file and the only thing in common appears to be Image Previews. Image Previews in this FM 3.7 beta still uses QuickTime (it won't in the final). So if you have a QuickTime component that's not 100%, this may or may not be the cause of the crash (but you should still crash on image preview).
I suggest these people trash everything in ~/Library/QuickTime/ and just make sure they have Perian (perian.org) installed.
Joseph Moore, by default, All adobe and macromedia apps are excluded from Silk. This was to prevent Silk from substituting fonts in DTP workflows.
idea2go, try it, if you don't like it, go back. But when APE 2.5 is released, we will *strongly* recommend all users get it. And some of these new APE modules will require it. Silk will require APE 2.5.
David, yes, you should get an email if you are on the mailing list.
Now, I'm off until these emails send.
Posted by: Rosyna on February 28, 2008 10:48 AMHello,
I would like to report that I am having a problem with WindowShade. QuickBooks Pro 2007 version 9.0.6 R7 (the latest version) will not launch unless I add it to WindowShade's exclude list. Other than that, it seems to work great, and I am glad to have it back.
Thanks.
Posted by: Dennis Bonsall on February 28, 2008 11:58 AMDitto on the FruitMenu Finder and active app crash when accessing the Apple menu. Additionally, Ape wouldn't let me disable FM on three tries, but then disabled it on its own on a restart. WindowShade & FontCard ok so far.
Posted by: editorbob on February 28, 2008 12:18 PMfyi, none of the above solutions helps my Finder crashes with FM.
Thanks
Posted by: Phil Hubbard on February 28, 2008 2:43 PMI'm not a REAL licensed beta tester, but in the furtherance of your work, please accept my bug biography:
WindowShade immediately worked perfectly with everything I threw at it.
With Fruit Menu activated, attempting to access the apple menu caused the following applications (when active and topmost) to immediately and consistently quit. Firefox 2.0.0.12, Adobe Reader 8.1.2, TextEdit 1.5, Safari 3.0.4, System Prefs, Entourage 11.4.0, Word 11.3.8, CopyPaste 2.7.5, Finder (which automatically restarted quickly), Quicktime Player 7.4.1., Calculator 4.2 and Suitcase Fusion 12.1.7 - Unfortunately, basically, anything I threw at it.
It causes FolderShare to freeze requiring a force-quit. When these apps are active the apple menu cannot be accessed.
Initially, TextEdit 1.5, iCal 3.0.2, Adobe Reader 8.1.2, Firefox 2.0.0.12, and Safari 3.0.4 were not affected, and the apple menu could be accessed wherein the contextual menus appeared and operated normally, and eventually the Finder also began not quitting but after a second restart, all of them too would quit immediately on attempting to access the apple menu, i.e. the apple menu simply could NOT be accessed.
Adobe apps Illustrator (CS3) Photoshop (CS2) InDesign (CS2) were excluded so the apple menu works appropriately, sans contextual menus.
After a third restart, the Adobe CS2 apps were still force-excluded and everything else worked fine (including AI CS3) with the apple menu and with FruitMenu except the Microsoft apps (including FolderShare which still quit).
I'm running 10.5.2 on this machine:
MacPro1,1
2xDual-Core Intel Xeon
2.66 GHz
Memory: 3 GB
Hope this helps! --Doc.
Posted by: Edward Haigh on February 28, 2008 3:00 PMI'm having the same problem that some other posts have mentioned. Installed Fruit Menu on a new cleanly installed Leopard 10.5.2 hard drive. Whatever application I have open at the time will consistently quit as soon as I click on the ‘Apple Menu.’
When I first installed Fruit Menu it seemed to work fine. After I shut down the machine and restarted, the problems began. I'll click on the Apple Menu, the menu will not show up, the spinning beach ball starts going, then within about 10 seconds, whatever application I had open quits. Doesn't seem to matter what application I have open. Even the Finder quits (and restarts). Can't access the Apple Menu at all.
I appreciate all your efforts in making this work and know everything will be fine in the end. This is a beta. Take your time and don't get sick again.
My setup:
Mac G4/1.25 MHz/2 GB Memory/10.5.2
woo! thank you! thank you! windowshade how I have missed you!!!!!
Posted by: Bill on February 28, 2008 7:32 PMSounds great. Don't get your heads swollen, but the lack of Unsanity haxies is the only reason I've held back from upgrading to Leopard all these months. As soon as these are out of beta, I'm upgrading everything.
Posted by: Bob's Hope on February 28, 2008 7:46 PMI use Labels X so totally I AIN'T going to use Mac OS X without it. Period.
Posted by: Steve Rogers on February 29, 2008 12:01 AMThank you for your hard work. I too have avoided installing Leopard due to its lack of WindowShade functionality, and it's comforting to know that I'll soon be able to move forward. For now, I've installed your latest betas of APE and WS and am having no problems on a Power Mac G4 running Mac OS X 10.4.11.
However, I'm going to revert back to WS 4.0.2 since you have yet to restore the functionality of that version -- specifically where a collapsed window of a background application will not expand when it is brought to the foreground. I remain hopeful that you will fix this, as the behavior seen since WS 4.0.2 is far less desirable, IMHO. I much prefer that a collapsed window stay collapsed until I specifically direct it to expand.
Posted by: arw on February 29, 2008 5:39 AMMy install of FM was also on a clean 10.5.2.
I did not have Image Previews on
And I don't have a ~/Library/Quicktime folder at all so I cannot clean it out. I don't really want to install Perian - I've never seen it listed as a pre-requsited for FM before...
I deleted my FM prefs, re-enabled it in APE and restarted.
But crash crash crash go the apps when FM is enabled.
Posted by: qb on February 29, 2008 9:39 AMUpdate to my previous post (2/28, 12:18 PM), wherein I noted that APE disabled FruitMenu for me. It now refuses to reload it. Here's what I get: (1) Sys Prefs show FM as "enabled" (and refuses to let me uncheck this), but (2) FM does NOT appear in APE's haxie list. When I try to add it I get the window that says FM needs to be installed (which it already is), but when I click "Install" nothing happens. Any thoughts, anyone?
Posted by: editorbob on March 1, 2008 6:19 AMPS: FYI, I'm running a 2GHz PPC G5, 4GB RAM, OSX 10.5.2. Also have betas for WindowShade & FontCard installed, both working perfectly. ShapeShifter, MightyMouse, & ClerarDock latent, awaiting upgrades. Other stuff too, including X-Assist & Default Folder. Full list available to Unsanity on request if it helps.
Posted by: editorbob on March 1, 2008 6:30 AMRunning 10.5.2 on a macbook. Tried this with both Spaces enabled and disabled. I have Windowshade set to arrange MiP windows on the upper left hand side of the screen. However, if I MiP multiple windows, they stack on top of each other.
Beyond that, the new windowshade and fruitmenu are working flawlessly for me. Excellent work, folks. I'm very happy to see the return of my favorite customizations.
Posted by: sungo on March 1, 2008 9:33 AMI'm now installing the Leopard-compatible haxies one per day (after a Finder crash loop when I tried all at once). Menu Master is working great; it's especially nice to have all of my Tiger shortcuts preserved.
Today is FruitMenu day. Before installing FM, I disabled image previews in Finder. I retained Preferences/com.unsanity.fruitmenu.plist, hoping to preserve my extensive customization.
After install, logout and login, my dozen Login Items started with no problem. Soon after that, Finder got into a tight crash and relaunch loop, so tight that I could not request Restart.
I forced power off and did a Safe Boot. This time I deleted FM's preference file. Finder crashed and relaunched once as I requested Restart.
I'm now running with a stable Finder and a vanilla FruitMenu. Whew!
[10.5.1 on Mac Pro 2x2.66]
Posted by: Ward Clark on March 1, 2008 9:50 AMi don't know if this is funny what ape's access showing to me:
configd 14 root txt REG 14,2 93320 6743585
->
/System/Library/SystemConfiguration/ApplicationEnhancer.bundle/Contents/MacOS/ApplicationEnhancer
...
Posted by: idunno on March 1, 2008 2:01 PMWhy would that be funny?
We want APE to automatically short circuit and be disabled on system migration (when people move from one computer to another using the migration assistant). This allows it.
I also talked about it at length in the post, yet you posted it as if it were a surprise.
Posted by: Rosyna on March 1, 2008 2:10 PMHi,
Love your products, especially WindowShade which I have missed since upgrading to 10.5 . Note that the CDN $ was higher than the US $ for most of the 1970's. Historically there have been times when it was way higher, but generally it has been close. There was a pegging of the CDN$ at .92 US $ which caused a political uproar back in the 60's and after 1976 the CDN$ started falling because of the political instability in the country. Unless you are buying wood, oil, water, etc...why would the value of our dollar have anything to do with your prices...:) I'm sure you all use bikes...
philip
Posted by: pmcd on March 2, 2008 12:35 AM
Ward Clark why you insist on that horrible piece of buggy OS? Why don't you install 10.5.2 update via software update? Some fake troubleshooting sites claim you shouldn't? You are on one of the most buggiest operating systems Apple ever released, please update to 10.5.2 for your own good. It is not just APE, the core OS is buggy, 10.5.2 fixes most of stuff.
Run "Software update" from Apple menu, download install them all.
I accepted Ilgaz's encouragement to upgrade to 10.5.2 (after running DiskWarrior to ensure a valid boot drive and temporarily deleting FruitMenu).
Then I restored FruitMenu's Tiger-era preferences file and re-installed FruitMenu. When logged out and back in, I got the same Finder crash loop.
It seems clear that FruitMenu 3.7b1 doesn't like the older preferences file.
Posted by: Ward Clark on March 2, 2008 2:45 PMwow thats a lot of betas, and a lot overly defensive language usually encountered when people are burning out and often best left unposted until one can approach it with a refreshed mind. honestly it was kind of a put off to unsanity to read through that. there have been so many overly negative sounding blog posts here maybe this one just topped it all off.
ps - remember resex?...oh yeah that is the surest way to not get this messaged posted isn't it? ;)
Rosyna,
I'd love to give you feed back on any glitches I encounter with Windowshade, but the problem is that it's not working AT ALL. It's as if Windowshade isn't installed.
-I'm running Windowshade X 4.2b1 & it's enabled.
-I'm running Application Enhancer 2.5b1 & it's enabled
-The .ape file is in my Library->Application Enhancers folder
-I've logged out AND restarted several times
-I'm runnning OSX 10.5.2
I've never had a problem with Windowshade before, but I must be missing something, since other people are reporting that it is working fine.
Help! :-)
Posted by: Steve on March 3, 2008 7:54 AMRegarding my earlier post @ February 28, 2008 3:00 PM:
My outlined procedure did NOT result from any deletions (like of Codecs or prefs) or disablings (like image previews) just restarts. Since then the problem reappears and disappears without any linear logic I can determine.
As a result, I just deleted FM prefs as instructed, restarted, and the result is that the apple menu again works with FM, but as before, the MS apps still unexpectedly quit - and are the ONLY apps that do.
As to the codec deletions....here I have to opine, I'm just a big booster and end user who is trying to help. 75% of what Rosyna is saying about implementation goes over my head, so please, don't be cross if I ask a stupid question, but.....I just checked my QT codecs and I don't see one labeled "Perian". Are you saying trash all the codecs and run, don't walk and INSTALL Perian?
As for image previews, are you talking about a functionality of FM or of the OS? If the former, I definitely don't have any image preview in FM as I have implemented it.
Please feel free to email if I can be of ANY help.
Posted by: Edward Haigh on March 3, 2008 7:57 AMOh...FYI, here are the codecs I DO have installed:
AppleIntermediateCodec.component
AppleMPEG2Codec.component
DivX Decoder.component
DivX Encoder.component
Flip4Mac WMV Advanced.component
Flip4Mac WMV Export.component
Flip4Mac WMV Import.component
XviD 1.0 Pref App.app
XviD_Codec 1.0 alpha.component
ZyGoVideo.component
I'm still having issues with Fruit Menu crashing, even after deleting the recommended files.
It will work the first time I launch it, but when I restart,
it crashes the system, and nothing under the Apple menu is available.
Any other suggestions for a 2.4 GHz MBP running 10.5.2 ?
BTW, Windowshade works fine.
rob
I just installed WindowShade X and it wasn't working either. I looked in /Library/Application Enhancers and it seems to be there, but it was 0KB! A 2MB copy was in the disabled folder. I deleted the zero-size one, moved the disabled one into the right place, and logged out and back in. Seemed to fix things.
I have no idea why things got into that state.
Posted by: Nik on March 4, 2008 11:25 PMHi folks,
FruitMenu has some troubles with Camino as the front most app. Accessing the Apple menu crashes Camino right away (see thread 1).
Process: Camino [362]
Path: /Apps/Internet/Browser/Camino.app/Contents/MacOS/Camino
Identifier: org.mozilla.camino
Version: 1.6b3pre (1608.03.02)
Code Type: PPC (Native)
Parent Process: launchd [63]
Date/Time: 2008-03-05 08:55:25.191 +0100
OS Version: Mac OS X 10.5.2 (9C31)
Report Version: 6
Exception Type: EXC_CRASH (SIGBUS)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 1
Thread 0:
0 libSystem.B.dylib 0x90d49cb8 __kill + 12
1 talkback.dylib 0x02c7ee2c FCProcessSignal(int, UNIX_EXCEPTION_CONTEXT*) + 196
2 talkback.dylib 0x02c814f0 fcStackDumpCollectorCreator(unsigned long, char*, int, char**) + 356
3 libSystem.B.dylib 0x90d47bc0 _sigtramp + 64
4 ...ple.CoreServices.CarbonCore 0x92d2cf50 PBGetCatalogInfoSync + 640
Thread 1 Crashed:
0 libSystem.B.dylib 0x90cc7978 mach_msg_trap + 8
1 libSystem.B.dylib 0x90cce89c mach_msg + 56
2 com.unsanity.ape 0xc0001bbc __ape_agent + 292
3 libSystem.B.dylib 0x90d09b98 _pthread_start + 316
Thread 2:
0 libSystem.B.dylib 0x90cc7978 mach_msg_trap + 8
1 libSystem.B.dylib 0x90cce89c mach_msg + 56
Ohh, PowerMail as well:
Process: PowerMail [164]
Path: /Apps/Internet/Emailer/PowerMail 5/PowerMail.app/Contents/MacOS/PowerMail
Identifier: com.ctmdev.PowerMail
Version: PowerMail version 5.6.3 build 4504 (5.6.3)
Code Type: PPC (Native)
Parent Process: launchd [63]
Date/Time: 2008-03-05 09:01:52.353 +0100
OS Version: Mac OS X 10.5.2 (9C31)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000050016628
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x9001a030 objc_msgSend + 48
1 com.apple.CoreFoundation 0x90543d9c CFStringCreateCopy + 176
2 com.apple.HIToolbox 0x93916220 HandleMenuEvent(OpaqueEventHandlerCallRef*, OpaqueEventRef*, OpaqueMenuRef*) + 652
3 com.apple.HIToolbox 0x93915f04 AppleMenuHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 124
4 com.apple.HIToolbox 0x938ccf68 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1484
5 com.apple.HIToolbox 0x938cc100 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 464
6 com.apple.HIToolbox 0x938cbf1c SendEventToEventTargetWithOptions + 52
7 com.apple.HIToolbox 0x93913ae8 SendMenuPopulate(MenuData*, OpaqueEventTargetRef*, unsigned long, double) + 208
8 com.apple.HIToolbox 0x939280f4 SendMenuOpening(MenuSelectData*, MenuData*, double, unsigned long, __CFDictionary*, unsigned char, unsigned char*) + 252
9 com.apple.HIToolbox 0x93927d0c DrawTheMenu(MenuSelectData*, __CFArray**, unsigned char, unsigned char*) + 248
10 com.apple.HIToolbox 0x93927a98 MenuChanged(MenuSelectData*, unsigned char, unsigned char) + 524
11 com.apple.HIToolbox 0x93926b64 TrackMenuCommon(MenuSelectData&, unsigned char*) + 1292
12 com.apple.HIToolbox 0x93922390 MenuSelectCore(MenuData*, Point, double, unsigned long, OpaqueMenuRef**, unsigned short*) + 228
13 com.apple.HIToolbox 0x939b17d0 MenuSelect + 100
14 com.ctmdev.PowerMail 0x003257a4 LTSMMenuBar::MenuCommandSelection(EventRecord const&, long&) const + 36
15 com.ctmdev.PowerMail 0x002d6c48 LEventDispatcher::ClickMenuBar(EventRecord const&) + 88
16 com.ctmdev.PowerMail 0x002d6e80 LEventDispatcher::EventMouseDown(EventRecord const&) + 160
17 com.ctmdev.PowerMail 0x0032526c LTSMDocApp::ProcessNextEvent() + 268
18 com.ctmdev.PowerMail 0x0000fda0 __darwin_gcc3_preregister_frame_info + 52896
19 com.ctmdev.PowerMail 0x002d0b24 LApplication::Run() + 180
20 com.ctmdev.PowerMail 0x00014a54 __darwin_gcc3_preregister_frame_info + 72532
21 com.ctmdev.PowerMail 0x00002bf8 start + 808
22 com.ctmdev.PowerMail 0x000028fc start + 44
23 ??? 0xbffffbd8 0 + 3221224408
Shoot, after a day of flawless behavior, the Finder starts crashing as well when accessing the Apple menu:
Process: Finder [401]
Path: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
Identifier: com.apple.finder
Version: 10.5.3 (10.5.3)
Build Info: Finder_FE-6071400~5
Code Type: PPC (Native)
Parent Process: launchd [63]
Date/Time: 2008-03-05 11:25:48.259 +0100
OS Version: Mac OS X 10.5.2 (9C31)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000001
Crashed Thread: 0
Thread 0 Crashed:
0 com.apple.CoreFoundation 0x90543d30 CFStringCreateCopy + 68
1 com.apple.HIToolbox 0x93916220 HandleMenuEvent(OpaqueEventHandlerCallRef*, OpaqueEventRef*, OpaqueMenuRef*) + 652
2 com.apple.HIToolbox 0x93915f04 AppleMenuHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 124
3 com.apple.HIToolbox 0x938ccf68 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1484
4 com.apple.HIToolbox 0x938cc100 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 464
5 com.apple.HIToolbox 0x938cbf1c SendEventToEventTargetWithOptions + 52
6 com.apple.HIToolbox 0x93913ae8 SendMenuPopulate(MenuData*, OpaqueEventTargetRef*, unsigned long, double) + 208
7 com.apple.HIToolbox 0x939280f4 SendMenuOpening(MenuSelectData*, MenuData*, double, unsigned long, __CFDictionary*, unsigned char, unsigned char*) + 252
8 com.apple.HIToolbox 0x93927d0c DrawTheMenu(MenuSelectData*, __CFArray**, unsigned char, unsigned char*) + 248
9 com.apple.HIToolbox 0x93927a98 MenuChanged(MenuSelectData*, unsigned char, unsigned char) + 524
10 com.apple.HIToolbox 0x93926b64 TrackMenuCommon(MenuSelectData&, unsigned char*) + 1292
11 com.apple.HIToolbox 0x93922390 MenuSelectCore(MenuData*, Point, double, unsigned long, OpaqueMenuRef**, unsigned short*) + 228
12 com.apple.HIToolbox 0x939b17d0 MenuSelect + 100
13 com.apple.HIToolbox 0x939b1724 HIMenuBar::HandleMouseEvent(OpaqueEventRef*) + 84
14 com.apple.HIToolbox 0x938cd540 HIObject::EventHook(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 200
15 com.apple.HIToolbox 0x938ccf68 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1484
16 com.apple.HIToolbox 0x938cc100 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 464
17 com.apple.HIToolbox 0x938e90e0 SendEventToEventTarget + 52
18 com.apple.HIToolbox 0x938fd098 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 2472
19 com.apple.HIToolbox 0x938cd3bc DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2592
20 com.apple.HIToolbox 0x938cc100 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 464
21 com.apple.HIToolbox 0x938e90e0 SendEventToEventTarget + 52
22 com.apple.HIToolbox 0x93957ec4 ToolboxEventDispatcher + 84
23 com.apple.HIToolbox 0x93954400 RunApplicationEventLoop + 164
24 com.apple.finder 0x00024dec 0x1000 + 146924
25 com.apple.finder 0x00103308 0x1000 + 1057544
26 com.apple.finder 0x00009db4 0x1000 + 36276
27 ??? 0xbffffc48 0 + 3221224520
I had no idea how much I'd miss WindowShadeX until it wasn't there. I've tried (unsuccessfully) to get by with other solutions in the meantime, but none of them worked the way WSX just does.
I realize that it's only funny money, but you're welcome to some more of mine just as soon as you're prepared to ask for it again.
Nice work, you've just made my day.
Posted by: Stephen R. Smith on March 5, 2008 6:42 AMHi. I just wanna know when CTM will have an update or a public beta. Thanks.
--
Sérgio Miranda
If you're having problems with fruitmenu not loving you, try adding the "Log Out" menu item to your apple menu in the Fruitmenu preference pane. It does not need a key equiv.
Posted by: Rosyna on March 5, 2008 1:16 PMI tried your tip Rosyna and it crashes even more. Surprisingly opening my Downloads folder and visually "cleaning" my entire desktop. FruitMenu is still no go for me.
Posted by: Mike on March 6, 2008 7:58 AMHere's a bug in WindowShade. When I minimize in place a window and then click on the app's icon in the dock, it acts like it's going to maximize the window but then it totally disappears. From there, the only way to get the window back is to minimize in place again, and then click on the small window to maximize it.
I'm running 10.5.2 on the following system:
Model Name: MacBook Pro 15"
Model Identifier: MacBookPro2,2
Processor Name: Intel Core 2 Duo
Processor Speed: 2.16 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
I caution Unsanity with regard to increasing prices. Yes, I do think they can probably increase the prices a little, perhaps by a $5 or $10 increase to some of them. However, I urge you not to start charging for upgrades. Haxies, like WindowShade and FruitMenu are very nice, but hardly commercial level software. They are user-interface tweeks which are helpful and that's it. If you do start charging for upgrades, then at least provide a substantial period of time for users to get free upgrades (at least two years).
Posted by: iGreg on March 9, 2008 11:06 AMiGreg
I don't believe I've ever been charged for any Unsanity upgrades. In addition, I seem to remember getting FruitMenu, Xounds, and Windowshade at a very low bundle price. Considering what was apparently a lot of work to get things Leopardized, I am considering donating an upgrade fee as soon as some of the bugs are fixed and the full versions are available. Please do not denigrate what I consider great and elegant enhancements. "...hardly commercial level software." Indeed.
Any solution for the FM crash? It basically crashes EVERY app on both my MacBook Pro and my Mac Pro. It's unusable.
Posted by: Josh B on March 10, 2008 3:24 PMAh, relief!!!! Thank you so much for the return of WindowShade. Yes, I would definitely pay for upgrades, or whatever. I'll give you my credit card and you decide what to charge me. I'm that happy!
Posted by: Stevo on March 11, 2008 10:37 AMThank you so much! & I wish you all good health! Cheers!
Posted by: mglory on March 13, 2008 3:03 AMBeta bust? So how about a b2 of FruitMenu??? Any progress after 2+ weeks of both good and crash report???
Posted by: qb on March 13, 2008 10:29 AMThe Compatibility page shows the latest FruitMenu to be 3.7b2, while this Weblog thread is still offering 3.7b1. I did manage to download this new release, but I'm reluctant to install it with no formal announcement or list of changes.
Is this thread the official source for the latest haxie betas?
Posted by: Ward Clark on March 16, 2008 11:00 AMAh, thanks, FruitMenu b2 works so far! Downloaded it from Versiontracker, which listed b1 but downloads b2. THX again!
k.
Posted by: kliere on March 16, 2008 2:10 PMExcellent! FM 3.7b2 working great now-no crashes.
Thanks guys!
Posted by: Phil hubbard on March 16, 2008 3:58 PMThe betas here may be updated at any time. That's why we recommend switching auto update checks to daily. The links here will automatically download the latest betas.
For example, Menu Master 1.4.3b1 was never available, it was always at least b2.
Posted by: Rosyna on March 16, 2008 8:06 PMFM 3.7b2 seems to work fine on my first-generation Intel Core Duo iMac, running OS 10.5.2.
Posted by: Al Friedman on March 17, 2008 3:06 AMFM 3.7b2 is running fine on my 24" iMac running 10.5.2.
Thanks
Posted by: Darrell on March 18, 2008 7:31 PMThank you very much for the updated Ape+sdk. I've succesfully built Windowdragon from source and everything runs fine.
It's awesome to have Windowdragon back!
Started up my Mac this morning and WindowShade wasn't working :(
Running 5.2 on a 2.4 GHz MacBook Pro with 4GB; APE 2.5b1 and WindowShade X 4.2b1. No other installs or system processes (like repairing permissions) over the last few days that might explain the difference, so I'm at a loss. I hadn't put in my previous registration information (with 3 days to go as of today), but I would have figured some sort of notice if that was the issue. In the "these applications are enhanced with WindowShade X" window, there are no applications showing at all. I tried to restart, repair permissions, &c., all to no avail.
Three things I've done to "fix" the problem:
1) entered my registration information and restarted. This didn't change anything.
2) I downloaded and installed APE 2.5b1 SDK. Not sure why this should do anything, but I figured I might as well.
3) I installed the latest Apple Updates that popped up on my screen this morning (Time Machine & Airport, and a Security Update).
I'm pleased to say that the WindowShade X is now working again. Unfortunately, since I didn't use Best Practice (doing the APE 2.5b1 SDK and the Apple Updates at the same time), I can't say what it is that fixed the problem). I also can't, of course, say that they problem is fixed for good since I don't know the original cause to begin with.
Thanks for the great program, and I would definitely pay for WindowShade X. I don't know about the rest, but WSX is essential to how I use my computer.
This is really an awesome app that is the only way to do certain things on the Mac -- kudos to my favorite developers for making this Leopard compatible despite all the challenges. I had an issue with InDesign while using this program, which caused the Help menu to pop up after every action -- no matter what I did, the help menu would pop up in the middle, forcing me to hit escape to clear it. It turns out to have been related to Menu Master. Removing MM keeps the bug in place, so the fix if anyone should need it is to keep the program installed but add InDesign to the "ignore apps" list.
Now in the immortal words of LOLCats, I can haz new Labels X update 4 Leoprdz?
Posted by: Peter Payne on April 7, 2008 11:59 PMJust a brief comment. ETAs are absolutely essential in all industries, including software. In my line of work, an ETA off by 0.1% could mean the death of a few hundred people. I wouldn't hold Unsanity to the same standard, but give it a rest and get some fresh product out already.
Posted by: Ishan Bhattacharya on April 9, 2008 4:52 PMIshan,
Have you been using the software updater from within each haxie? FontCard just had an update.
Posted by: F451 on April 9, 2008 7:53 PMYes, I've been using the Software update mechanism on an at least daily basis. WSX keeps losing its preferences in 10.5.3, FM keeps telling me on two of my Macs that it has expired, although it says it is also registered (which it is). All very confusing, which is why a tiny little update on all these haxies and the progress being made might be helpful. My 4 €...
Posted by: ishan on April 11, 2008 5:29 PMNew engine
Posted 12:48 pm, January 8th by ResEx Team 2512
So, after investing time into some new back-end technology for the past month or so, Slava stayed up pretty much all night a few nights ago to completely start over in PHP. This is a Good Thing™ for the site in general. We were excited about playing with new technology, but the learning curve was slowing things down too much. We hope this change is going to speed up our schedule significantly. We do apologize for the delay, but we’re determined to get this right. We’re not going to repeat past mistakes and open something that we’re not totally satisfied with.
Thanks for hanging in there!
so anyone expecting timely news knows, this was the last message, January 8th.... 2007
Posted by: madisonsuicide on April 11, 2008 5:36 PMYou did note there were over 2,500 comments in response to that January 8th post, right?
Windowshade doesn't really work on xcode 3 , but i bet you already know that.
Posted by: Christopher on April 23, 2008 8:00 PMWell it's been a few months now.
I'm sure we're all eager for an update on the state of things.
How's it going? Any more progress, like say, a leopard shapeshifter beta maybe sometime?
Posted by: Johannes on April 29, 2008 8:45 PMThe Betas are working nicely on my 2.4 GHz 20" Intel iMac. I do notice a small knock to my system's performance when running them, but it's not enough to complain about. I'm just happy to have Windowshade and Fruitmenu back.
Keep up the fine work! I look forward to the days of Shapeshifter's return!
Posted by: Matt Granz on May 5, 2008 11:18 PMJust like to endorse the last comment, everything works. Windowshade has issues with spaces if you minimize in place at the bottom of the screen, but no crashes or conflicts.Thanks
Nice stuff on macthemes.net to take the place of Shapeshifter. No problems with a couple of different themes using 10.5.3 9D34. OTOH, WS keeps forgetting its setting periodically. It's been three months since the last update, Unsanity. Is it the "no news is good news" approach you're using?
Posted by: ishan on May 25, 2008 6:59 PMHas anyone else been having trouble reaching Unsanity by email? I've been trying to contact them regarding a license issue for several weeks with no reply. I'm wondering if it's an issue with my email or whether they've gone on vacation.
Posted by: Noam Sturmwind on May 28, 2008 9:40 AMI think they have gone bust. Not even a blog update since February. I'm bummed, i bought shapeshifter and would love to be able to use it again, it worked great.
Posted by: Tristan Brotherton on May 28, 2008 7:41 PMWaiting for LabelsX to return. No way to upgrade to Leopard before this! But please, let us now if this return is NOT planned...
In the meantime, thanks for all you did for us.
Kindest regards,
Gérald
Posted by: Gérald on June 2, 2008 5:20 PMRe: Noam's question
It seems its a permanent "vacation." On a positive note, I've learned a lot of UNIX "geeky" stuff reading through macthemes.net and using some of the themes that are in development there. Make sure you clone your boot drive before playing around though :)
Posted by: on June 8, 2008 5:38 PMSmart Crash Reports has just been updated in case there's anyone out there that's still interested. That means someone in Unsanity is still out there. ;-)
P.S. You'll have to check Version Tracker as it has the current update version.
Posted by: Mac007 on July 20, 2008 7:55 AMThe support page lists a beta version available for Chat Transcript Manager that works in Leopard. Can anyone point me towards how to get that? From the outside it would seem a simple change, to recognize the folder structure now that chats aren't all stored in a single folder anymore. VersionTracker still shows the version that I have from 2006 which does not handle it.
Posted by: on July 22, 2008 1:32 AMFruit Menu 3.7b2 works perfectly since installed on 2 computers March 17 2008. Thanks, thanks, thanks!.
Posted by: jlgca on July 24, 2008 9:05 AMThey're alive. FM 3.7b3 has just automatically downloaded.
Posted by: Geoff on July 30, 2008 11:37 AMExcept that aliases in the Fruitmenu folder no longer produce a submenu ....
Posted by: Geoff on July 30, 2008 1:16 PMConfirmed, aliases no longer create a submenu. On the bright side application load times are faster with FruitMenu on.
- Jay
Posted by: Jay on July 30, 2008 2:04 PMFruit Menu 3.7b2 aliases in the FruitMenu Items folder produce's a submenu but in Fruit Menu 3.7b3 aliases in the FruitMenu Items folder no longer produce a submenu.
Posted by: Ross on July 30, 2008 3:07 PMThe lack of submenus in Fruit Menu 3.7b3 is a showstopper for me. My next step is to choose between downgrading to 3.7b2 (if possible) or reviving my copy of MaxMenus.
Posted by: Ward on July 30, 2008 3:24 PMAnother thing I've noticed with FruitMenu 3.7b3 is that no folders appear to be listed in the recent folders submenu, even though the finder "recent folder" menu still works as expected.
- Jay
Posted by: Jay on July 30, 2008 8:12 PMWow, just noticed after I posted the last comment that 3.7b4 is linked from the download link above. It fixes the alias submenu problem, and is still quicker in application launching than b2 was, Thank you !!! Sadly though the recent folders submenu still stays blank. Keep up the good work !
- Jay
Posted by: Jay on July 30, 2008 8:20 PMI took the downgrade to 3.7b2 option (because FruitMenu is more capable than MaxMenus).
BEWARE: Downgrading to FruitMenu 3.7b2 caused my Finder icon size and grid spacing to change to 48-bit icons and fully expanded grid (which was easy enough to adjust). But it resulted in the 74 icons on my three monitors moving to random locations.
The silver lining here is I'm forced to do some long overdue housekeeping.
Posted by: Ward on July 30, 2008 9:26 PM3.7b4 works fine. There's been no submenu from the Recent Folders menu item since at least 3.7b2, so this is nothing new. 3.7b4 displays icons in submenus a lot faster than previous versions. It's just so good to have Unsanity back. Thank you
Posted by: Geoff on July 31, 2008 4:59 AM"There's been no submenu from the Recent Folders menu item since at least 3.7b2, so this is nothing new."
Hmmm... I'm sure it worked here with b2. Very strange. I'm just glad for the speed boost.
- Jay
Posted by: Jay on July 31, 2008 7:49 AMI notice that Jay (July 30 2008) downloaded 3.7b4. Even though the FruitMenu pfd and the .dmg say 3.7b4, after 3 attempts to install 3.7b4, version 3.7b3 was installed, which is my presently installed version. When the FruitMenu window is opened it shows 3.7b3, not 3.7b4.
Posted by: jlgca on August 2, 2008 2:24 PMI had to do a archive and reinstall and now the Window Shade beta with APe 2.5b1 no longer works. Double Clicking in the menu bar simply minimizes the page to the dock. I've tried everything to get Window Shade back but nothing works. Anyone got any ideas.
Posted by: Norm on August 3, 2008 10:49 AMAfter reading the post from jlgca, I checked my version of FruitMenu, which I thought was 3.7b4. It main preference panel reports 3.7b3. Since this version *is* displaying submenus, it's *not* the same b3 from several days ago. (I reverted to b2 in the interim.)
Posted by: Ward on August 3, 2008 11:06 AM"I had to do a archive and reinstall and now the Window Shade beta with APe 2.5b1 no longer works. Double Clicking in the menu bar simply minimizes the page to the dock. I've tried everything to get Window Shade back but nothing works. Anyone got any ideas."
Had the same issue. You have to reinstall WS -it recognizes you're registered, but I'm guessing there's a hidden file somewhere that isn't brought across.
WindowShade 4.2.1 doesn't work, sort of, for Firefox 3.0.1. Actually the current stable version is even worse for Firefox 3.0.1 in that it doesn't seem to do anything. The beta under Leopard will do the basic windowshade (and built-in minimize to dock) but can't do float on top or minimize-in-place.-kby
Posted by: Kimo B. Yap on August 30, 2008 8:13 PMFor the most part window shade is working great and I am on osX 5.5.5. There is one change I'd like to mention, ITUNES 8. WINDOWSHADE does not work with ITUNES 8. . When I press the + button, I get a smaller window sitting on my desktop, which is nice, but I would prefer that window shade would work, Hopefully you can find a fix for this.
Thanks.
Is there anything we can do to get Labels X on Leopard? Anyone at Apple to write to? Money? Prayers?
Posted by: Steve Rogers on September 18, 2008 2:39 AMKeep comments on topic. If a comment is unrelated to this post, it may be removed or moderated.