Comments
-
Greg Hurrell
Thanks for the report. I'll see if I can reproduce it here once I get my hands on a copy of Leopard. Apple hasn't yet announced when they'll be mailing out the final version to developers, but if it's anything like Tiger was I expect it to be within the next few weeks.
-
Greg Hurrell
Created
,
edited
For reference, see the forum discussion on this topic:
-
Greg Hurrell
Looks like Menu Extra Enabler by Unsanity might work with Leopard, or at least that's what I've heard from users.
The Menu Extra Enabler page itself says that it is not compatible with Leopard, but I think that's some old text that they forgot to clean up seeing as the compatibility page claims that it is compatible.
So seeing as MenuCracker is unlikely to be updated, ever, it would seem, I am going to reword the summary of this ticket to reflect what needs to be done to get WinSwitch installing on Leopard.
-
Greg Hurrell
Summary changed:
- From: New installation of WinSwitch 3.2.1 on Leopard cannot be completed
- To: WinSwitch Leopard compatibility (use Menu Extra Enabler instead of MenuCracker)
-
Greg Hurrell
I've migrated the old Subversion repository over to Git
You can now create a clone of the repo using:
$ git clone git://git.wincent.dev/WinSwitch.git
More notes in "Migrating the WinSwitch repository from Subversion to Git".
-
anonymous
[cross posted from the Leopard discussion thread]: I may be missing something, but why does WinSwitch have to load into SystemUIServer's context at all (which is the only reason to use MenuCracker)? yes, granted, having WinSwitch be draggable to the spot the user would expect the fast user switching menu is great, but Apple has reserved NSMenuExtra for a reason (SystemUIServer is a core OS component whose stability is not be jeopardised by third parties). Why not simply create a NSSatusItem and live with the fact it will appear further left on the menu bar? Such a status bar item would not need to rely on potentially disruptive hacks, and would survive OS updates far more easily. I for one would actually prefer that, never mind menu placement?
Martin (who didn't feel like signing up to another forum to post).
-
Greg Hurrell
Rather than reply in both places, I'll reply to your forum topic.
-
Greg Hurrell
There has been some activity on the MenuCracker front lately.
- Project page: http://sourceforge.net/projects/menucracker
- Version 2 source code (under development): http://menucracker.cvs.sourceforge.net/viewvc/menucracker/menucrackertwo/
- Code comments on new version: http://menucracker.cvs.sourceforge.net/viewvc/menucracker/menucrackertwo/MenuCracker.m?revision=1.1&view=markup (replicated below)
// Design Notes: // ============= // // This is a reimplementation of the original MenuCracker. Though it serves // same purpose, this implementation's design differs in several important // ways. // // New Loader // ---------- // In this design the loading mechanism is changed. When SystemUIServer // (SUIS) decides to load a NSMenuExtra it looks at the NSPrincipalClass key of // the bundle's Info.plist to decide if it will allow the class (string // comparison). If the principal class is on the whitelist the bundle is // loaded and an instance of the principal class is sent through the plumbing. // // Prior versions of MenuCracker worked by defining an empty implementation // of the CHUD tools processor extra (CPUExtra) and then loading the crack // class out of the same bundle. The problem with this approach was that it // permanently blocked the load of the actual CHUD menu. Redefinition of an // existing runtime class is undefined in Obj-C, and so the empty class from // the cracker kept winning. Similarly, if an old version of MenuCracker was // loaded it would prevent newer versions from loading (because the cracker // class was already defined). This was a common bug, especially with very // old copies of MenuCracker bundled with some software. // // This version of the cracker tricks SUIS in a different way. It declares // an NSPrincipalClass on the whitelist, but doesn't implement it. When // SUIS loads the bundle a constructor function handles the menu cracking. // Since this implementation declares nothing in the Obj-C runtime and uses // all private symbols it can be loaded safely multiple times in the same SUIS. // // Multi-Version Cooperative Loading // --------------------------------- // A second major difference in design is the handling of multiple versions // of MenuCracker itself. Not every developer bundling MenuCracker has kept // up to date and even if they did not every end user will update their // software regularly. // // Prior versions of MenuCracker assumed that eventually the new version of // MenuCracker would be loaded because old copies sorted the crackers in // SUIS's list of menu extras by comparing version numbers. Unfortunately in // practice this mechanism sometimes failed, usually because of bugs in the // older implementation. The most common failure was the problem with CPUExtra // class redefinition discussed above, but other bugs with path validation, // etc. have also been problems. // // This implementation takes a new approach. First and foremost, the new // load design (see above) allows multiple MenuCrackers to load at once. // Rather than try to resolve this down to a single winner which gets // loaded first, we now use a cooperative approach that allows newer versions // loaded later to overtake previously loaded versions. // // The first MenuCracker to load establishes a global in SUIS that contains // an indirection table. SUIS methods are swizzled to redirection routines // that then call through the table to the desired implementation. // // When a second MenuCracker loads it has access to the indirection table and // can coordinate with the original MenuCracker to decide which version is // "best". If the second copy wins it replaces the indirection table content // with its own, completely taking all but the redirection calls from the // first MenuCracker out of the code path. // // Since each method of SUIS is swizzled only once for all MenuCrackers // other tools that swizzle the same routines are safe. Secondary swizzlers // always have valid pointers to the first loaded redirection routines. If // new swizzles are needed for later versions they can be added to the // indirection table using newer redirection routines but still leaving // the older redirection routines in place. // // Less Aggressive Housekeeping // ---------------------------- // Once upon a time we checked for other loaded crackers, specifically // old versions of MenuCracker or Enable.menu from older Keychain Access. // If they were loaded we went through a restart dance to try to become // the only loaded cracker (assuming we won the version comparison) by // rewriting the SUIS preferences and killing SUIS. The problem with that // approach was twofold: // // - In the real world SystemUIServer never loaded duplicate MenuCrackers // (see above). // - The most common alternate cracker, Unsanity MEE, couldn't be unloaded // my modifying the preferences and restarting SUIS. // // It's not clear there's any advantage to trying to be the only cracker. // This design doesn't require it, so we don't even try. We only remove // old MenuCrackers from the next load and try to peacefully coexist with // whatever else is loaded.
-
Greg Hurrell
There has been a bit of interesting activity on this front lately, including reports that it works on Snow Leopard (see http://sourceforge.net/tracker/index.php?func=detail&aid=2674886&group_id=59300&atid=490562).
I am going to close this ticket and move onto the new ticket, ticket #1378, which is about WinSwitch/Snow Leopard compatibility.
-
Greg Hurrell
Status changed:
- From: open
- To: closed
Add a comment
Comments are now closed for this issue.