WinSwitch leopard compatible?

I haven't tried it myself yet but I've had several people report that it doesn't work.

It is open source so if people are interested in updating it for Leopard compatibility then that's an option. I myself won't be able to get to it for a while yet due to other stuff that is more urgent.

I haven't explored this fully yet but I believe the breakage is most likely due to an incompatibility between "MenuCracker" and Leopard:

http://sourceforge.net/projects/menucracker

MenuCracker is what loads WinSwitch into the menu bar; the hack is necessary because Apple explicitly tries to stop third-party menu extras from loading and has done so since Mac OS X 10.2, I believe.

The trouble is that MenuCracker hasn't been updated since 2003; although fortunately it worked with Jaguar, Panther and Tiger, it looks like it might not work with Leopard.

So I need to find an alternative method which does work on Leopard. At this stage that's just speculation though because I haven't been able to confirm that MenuCracker is the source of the failur; it may be that the incompatibility stems from somewhere else.

This issue is being tracked here:

https://wincent.dev/a/support/bugs/show_bug.cgi?id=599

For those who can't be bothered clicking on the link above, the post briefly describes how to manually install WinSwitch on Leopard.

Installing, Go to Macintosh HD > Library > Menu Extras > WinSwitch.menu open with SistemUIServer.app

WinSwitch in you menu bar.

Finish

Thanks for the comments, Martin.

The short answer is: that if WinSwitch didn't appear on the right then I would be inundated with user complaints, requests, and questions about the location. It's free software, and the donations have never covered the development or hosting costs, so I can't really afford to take the kind of action which would produce a large support burden.

The longer answer...

I actually happen to agree with most of what you say (the technical points), Martin, and if you look at another product of mine which loads in the menu bar (Synergy), you'll see that it uses the public NSStatusItem API rather than the private NSMenuExtra one. (And this is despite many requests from users for it to be relocatable in the menu bar.)

But WinSwitch is a replacement for the Fast User Switching menu, and users expect it to appear on the right. I think your point of view is a very rational one, but my experience with user feedback is that you are probably very much alone in preferring an NSStatusItem. I understand why it would be attractive to you (for the stability and the likely compatibility with future OS releases), but I also know that for 99.9% of users those concerns pale in comparison next to the issue of where on the menu bar the menu appears. It's only a cosmetic detail, but it really does matter to a lot of users.

As far as stability goes, WinSwitch itself is extremely simple and unlikely to cause a crash. It's open source so you can check it out yourself. You'll see that it's split into two pieces.

• a background application which is not loaded into the SystemUIServer and therefore can't cause it to crash; this app handles things like preferences management, hot key control, notifications etc
• a tiny menu extra which does nothing but draw the menu; it is only three files and it is fairly easy to audit (I'm not saying it is bug free — no software is — but it is not difficult to check over the code and state with a high degree of confidence that it is free of crashing bugs).

But I do think the ability to optionally run WinSwitch using NSStatusItem API is a good one. This was previously requested, albeit indirectly, in ticket #456. But the motivation for the request and the implementation were slightly different, so I'll open a new ticket for this particular issue: ticket #1266.

I remember playing with some Unsanity "Haxies" in the very, very early days of Mac OS X, probably around the Cheetah (10.0) timeframe, I think. But from very early on (roughly 2001) I've always tried to maintain a "clean" system so that I can do development in an environment that is as close as possible to the one that Apple ships with new machines. So I can't really comment on Unsanity's stability track record in intervening years... Nevertheless, as their very name suggests, they are and always will be "hacks". The name of "MenuCracker" also indicates its nature: it exploits a flaw in the API to circumvent Apple's attempt at preventing third-party use.

My main concern with Menu Extra Enabler is not that its a "hack" but rather that it is not open source. At least MenuCracker was open source. As such, I am not really interested in shipping a binary-only installer for a closed-source product alongside WinSwitch. It would be another story if it were open source, but it's not...

So what I am currently thinking of is going down two routes:

• Offer an NSMenuExtra-based version of WinSwitch, but do not distribute an installer with it. Instead, it would come with instructions which state that it requires Menu Extra Enabler in order to work, and telling people where to download that if they want it. Then to "install" WinSwitch the user would just have to put it wherever they want to keep it and double-click it.
• Offer an NSStatusItem-based version as an alternative.

This plan isn't entirely satisfactory seeing as the first option is quite complicated and will generate a lot of support requests; the vast majority of users really do prefer simple one-click installs. And the second option is much easier, but that will generate its own support requests from people who don't like where the menu appears in the menu bar.

So in any case, I would like to leave this issue for a while before making a final decision. Usually when I am not sure what course of action to take, I find that taking a step back and reflecting on things usually helps me arrive at the right solution. (Unfortunately only "usually" and not "always"...)

Let's not forget the third option:

3) Do nothing, and allow people who are interested in taking the project forward take advantage of the fact that WinSwitch is open source and can do whatever they want with it (your option 1 or 2, or theoretical possible options 4, 5, 6, 7, or anything else). I'm more than happy to accept patches and will incorporate them if they're up to scratch.

This is actually a fairly attractive option considering that:

• I don't use WinSwitch myself
• I haven't really used it since the Panther days
• I have no interest in using it seeing as the built-in Fast User-Switching menu already does everything just as I personally would like
• there's absolutely no economic incentive to work on it seeing as it is free and the donations never even came close to covering the bandwidth costs
• there's no non-economic incentive either because I already have plenty of stimulating development projects on my plate
• any less-than-optimal release will only generate support queries

I've already said what I think the options are — either pursue the NSMenuExtra path, or purse the NSStatusItem path — so your comment doesn't really add anything new (other than the fact that you put what I view as an excessively negative spin on the NSMenuExtra option, given the widespread successful use of the API by third party developers over the years). I could repeat the points that I've already made in this thread, but instead I'll just incorporate them here by reference.