[TheSpaz]

Some of you may remember my thread about lagging Tiger menus back in 2005 but, I FINALLY found a fix for it.

Okay, I have to explain what this one actually means. In Panther, all
menus had a full speed refresh rate which made the menu selections a
lot smoother when you were navigating through a menu quickly. When
Tiger came out, suddenly a lot of menus in the newer Apps used a
slower refresh rate resulting in jumpy menu selections when rolling
your mouse through a menu.

Here's how to test it.

Open iTunes and click on the Apple menu and then quickly move your
cursor up and down and watch the menu item selections follow your
cursor exactly. Nice and smooth right?
Now switch to the Finder and do the same thing. Notice the selection
jumping around and even skipping completely over items here and there?
It's not nearly as smooth as it is in iTunes. That's because there's a
setting in iTunes' info.plist file. I'll explain that in a second.

To get the faster menus (such as in iTunes) simply find any App that
you want to modify and control-click on the icon and choose "Show
Package Contents". Then open "Contents". Next, while you still have
that window open, find and open Terminal.app in your Utilities folder.
Then type in the following text.

[codex]defaults write [/codex]

Edit: Make sure there's a space after "defaults write "

Now click on the "Contents" folder we left open and drag "Info.plist"
into the Terminal window. It should now show you the path of the
info.plist file. Now, we can't have .plist on the file name so delete
".plist" and hit the space bar again.

Then paste the following text after it:

[codex]HIWindowFlushAtFullRefreshRate -boolean Yes[/codex]

Now you should be able to open the App you modified and the menus will
now be exactly as smooth as iTunes.

I hope all of this made sense. I'm happy now anyways.

If you have developer tools installed you can simply edit the info.plist file with Property List Editor. It's a little bit easier to do with Property List Editor but, it does require developer tools which not everyone has installed.

Here's the old thread in case you want to see it.
http://forums.macnn.com/90/mac-os-x/...-menu-hilites/

[Big Mac]

Interesting find, thank you. Btw, small quibble - it's not called the cursor; it's called the pointer.

[Don Pickett]

I don't know about you, but Leopard's interface flies on my machine. Easily the fastest OS X interface yet.

[TETENAL]

Originally Posted by Big Mac 

Interesting find, thank you. Btw, small quibble - it's not called the cursor; it's called the pointer.

[TheSpaz]

I guess nobody cares still. Oh well... at least I am happy... I just figured others would like the same but, I bet a lot of you never even had Panther to compare it to. *sigh* Whatever.

While you're at it... instead of commenting on my thread... just fix my spelling to be jerks. Thanks.

[Don Pickett]

Originally Posted by TheSpaz 

I guess nobody cares still. Oh well... at least I am happy... I just figured others would like the same but, I bet a lot of you never even had Panther to compare it to. *sigh* Whatever.

While you're at it... instead of commenting on my thread... just fix my spelling to be jerks. Thanks.

Dude, on my machine Leopard is visibly faster than either Panther or Tiger.

[Thinine]

I don't think this setting will work for anything but Carbon programs, and even then, only Carbon programs that use an HIView (which is quite a few, but not 100%). But yeah, Leopard's UI flies.

[eggman]

I'm glad you're happy. I remember your issue with this in the original thread, and it occurred to me (and still does) that the reason most folks never noted that items were being skipped rather than highlighted when moving quickly through the menu is that the entire purpose of highlighting these items is as a guide to assist targeting the selected element... and if you're sliding over menu items that fast, you're certainly not about to choose that item - and in that sense, the transitory flashing of those intermediate items, which may look smooth to you, may actually serve as a distraction to others.

It's only when you slow down sufficiently to be able to stop and actually select an item, and are proximate to other items that may be selected in error, that you really need the visual feedback.

As it is, I find Leopard to be more responsive than Tiger, Tiger more responsive than Panther, etc, all the way back to 10.0, which crawled!

[TheSpaz]

Originally Posted by Thinine 

I don't think this setting will work for anything but Carbon programs, and even then, only Carbon programs that use an HIView (which is quite a few, but not 100%). But yeah, Leopard's UI flies.

Every app that I have applied this to so far has worked without a hitch. EVERYTHING! I even did it to the spotlight menu, iChat menu, Clock menu, and almost all of my Applications... Carbon and Cocoa Apps. They all work.

Also, I don't understand how people can say that their Leopard menus are faster and more responsive than Panther or Tiger because I have seen tons of Leopard installs so far and I've seen this "feature" on all of them. I don't care WHY Apple reduced the refresh rate on the menu items to make them "appear" skippy... I'm just glad their fluid and smooth again. So... Go me! I thought maybe others felt the same way as me... that's all. Give it a try and test for yourself if the menus got faster.

By the way, I'm talking about browsing through a menu and how accurately the highlight follows the cursor... not about how fast a menu opens or how fast you can switch between menus... just to clear that up. I think some people are thinking it has to do with the actual selecting of menus and not the items from inside the menus.

Although I do not FLY through my menus... I do notice it during normal use and it's kind of distracting to see that blue selection blink only most of the time and not for every single item (as it was in OS 9 up until the end of Panther).

I can't believe how much negative feedback I get from this. When I use OS 9, or Panther, or even Windows, the menu item selections are very smooth... and it's embarrassing to have it jump and skip around causing confusion to my eyes rather than a smooth seemless experience. Everybody wants smooth... smooth window resizing, smooth scrolling, smooth window minimizing and why not smooth menus? I don't understand you guy's logic.

[Horsepoo!!!]

Originally Posted by Big Mac 

Btw, small quibble - it's not called the cursor; it's called the pointer.

Not really. It's called a cursor (which is almost the same as a pointer).

The big difference is that there's only 1 pointer on the screen but there could be 2 cursors (the mouse cursor/pointer and the text insertion cursor. One indicates where alphanumeric characters will be inserted while the other shows where the next mouse click will land.

[cybergoober]

Glad you finally found a fix, but this doesn't affect me in the least.

[TheSpaz]

Thanks to all of you who supported what I did... which was actually none of you. Did anyone try it... anyone see a difference? I know I'm not crazy... there's a big difference between iTunes and virtually any other App. I prefer the iTunes style menus and I will be changing all of my Apps.

[stevesnj]

Originally Posted by Don Pickett 

Dude, on my machine Leopard is visibly faster than either Panther or Tiger.

Same here...I thought my 1GhZ Powerbook would lag a lot but i found just the opposite!! It's much quicker than Tiger IMHO

[cybergoober]

Sorry for not "supporting" you. I did not try it, because it doesn't bother me. At all.

[voodoo]

Yeah I notice these slow redraws. Leopard is fast, but redraw is obviously faster in iTunes than other apps.

This is on a 2GHz Core2Duo iMac.


Silly Apple. iTunes also has those new fancy scrollbars

All the good stuff.

V

[Kevin]

My Leopard has the new iTunes scrollbars.

You just have to hack them that way.

[TheSpaz]

Originally Posted by Kevin 

My Leopard has the new iTunes scrollbars.

You just have to hack them that way.

Can we have the files?

[P]

Originally Posted by Horsepoo!!! 

Not really. It's called a cursor (which is almost the same as a pointer).

The big difference is that there's only 1 pointer on the screen but there could be 2 cursors (the mouse cursor/pointer and the text insertion cursor. One indicates where alphanumeric characters will be inserted while the other shows where the next mouse click will land.

While you're technically correct, Apple's suggested terminology has been (ever since the eighties) to refer to the blinking text bar as an insertion point and the black arrow as a pointer and to not use the term cursor at all. Windows does the same these days - although there are still places where the term cursor is used, such as the official name for the pointer icon files, the interface generally refers to them as pointers. If you want to avoid misunderstandings, don't use the word cursor.

[Kevin]

Originally Posted by TheSpaz 

Can we have the files?

Depends if you have a PPC Mac or a Intel Mac.. .and it's not totally finished yet.

Follow this thread.

http://forums.macnn.com/94/gui-custo...ds-gui-thread/

BTW i think someone made a just scrollbar and thumbs hack for Intel Macs and linked it there.

[red rocket]

Hmm.

I'm still on Panther, so I can't reproduce the issues TheSpaz is describing, but, from the sound of it, this is something that would indeed piss me off.

Thanks for the posted fix, I've saved the thread to disc and will try it out once I've upgraded.

[osiris]

Originally Posted by TheSpaz 

Thanks to all of you who supported what I did... which was actually none of you. Did anyone try it... anyone see a difference? I know I'm not crazy... there's a big difference between iTunes and virtually any other App. I prefer the iTunes style menus and I will be changing all of my Apps.

I'll try it when I get my Leopard disk.. in about 2 weeks. : /

I wish there was a general preference to turn off all menu flashing when selecting an option - kind of like General Controls back in the OS 9 days. (Why blink 3 times - just do it!)

[Thinine]

Honestly, I've never noticed this. And frankly, I think you're imagining things, since that setting can't possibly apply to Cocoa apps (or at least apps that use NSView). iTunes, yeah, Finder, yeah, but it's unlikely that all apps will be affected by it.

[Don Pickett]

Originally Posted by Thinine 

Honestly, I've never noticed this. And frankly, I think you're imagining things, since that setting can't possibly apply to Cocoa apps (or at least apps that use NSView). iTunes, yeah, Finder, yeah, but it's unlikely that all apps will be affected by it.

That was the consensus of the original thread.

[TheSpaz]

What are you guys talking about? All Apps that were compiled in Tiger or Leopard have the choppy menu item selections... ugh... I wish I could make a movie of it to show you exactly what I mean. It's not something you have to see... it's more of a feel. It feels choppy the way the menu item selection skips over random menu items as it tries to catch up with your cursor as fast as it can... those lost frames make it look like it's skipping around. However, when you do this edit, you see ALL the frames resulting in a much smoother animation. For example... a 15fps movie clip will look choppy and a 30fps movie clip will be smooth and seemless... this is the effect I'm experiencing. It doesn't mean the selections are moving slower but, at less frames per second rather than full speed motion.

[Horsepoo!!!]

Originally Posted by TheSpaz 

What are you guys talking about? All Apps that were compiled in Tiger or Leopard have the choppy menu item selections... ugh... I wish I could make a movie of it to show you exactly what I mean. It's not something you have to see... it's more of a feel. It feels choppy the way the menu item selection skips over random menu items as it tries to catch up with your cursor as fast as it can... those lost frames make it look like it's skipping around. However, when you do this edit, you see ALL the frames resulting in a much smoother animation. For example... a 15fps movie clip will look choppy and a 30fps movie clip will be smooth and seemless... this is the effect I'm experiencing. It doesn't mean the selections are moving slower but, at less frames per second rather than full speed motion.

Hardly anyone can notice this. Nobody really cares about this but you. Nobody shakes their mouse really fast on an open menu and wonder "geez, why is the menu item selection so jumpy?"

[MindFad]

This is a visually perceived performance hit, something that has no impact whatsoever on usage in any form. Why is there—yet another—thread about it? If it's affecting your daily computing and you just can't bear with the fact that the Finder's filed menu skips two or three items every redraw as opposed to iTunes's zero-delay redraw, then by golly, write Apple.

[cybergoober]

Indeed. As long as the selection is at my pointer when I reach the menu item that's all that matters to me. Not to mention I use keyboard shortcuts whenever I can.

[Chuckit]

I just tried this with Safari and it doesn't do anything. Not that I really mind, because the thing it's supposed to fix doesn't ever draw my attention.

[voodoo]

On faster Macs the delay isn't really a problem. Go try this on a 1.33 GHz iBook and it becomes very visible.

On a 2GHz iMac, not so much.

V

[CharlesS]

Don't try this trick on an app that's code-signed, or you'll break it...

[sc_markt]

Originally Posted by Don Pickett 

I don't know about you, but Leopard's interface flies on my machine. Easily the fastest OS X interface yet.

Same here. It rocks and I've been loving it...

[TheSpaz]

Originally Posted by CharlesS 

Don't try this trick on an app that's code-signed, or you'll break it...

How do we know which Apps are code-signed and is it possible to re-sign it? It's not a big change... it's very small.

[CharlesS]

Originally Posted by TheSpaz 

How do we know which Apps are code-signed

All Apple's apps are code-signed. You can check other apps by using codesign -vv plus the path to the app in the Terminal, but considering that code-signing is dead simple to do and increases security, you shouldn't be surprised to see code-signing in third-party apps that are developed for Leopard, especially since Apple recommends that all applications developed for Leopard should be code-signed, and hints that non-signed apps may not work in future releases of OS X by saying that Leopard will accept unsigned code, for now.

and is it possible to re-sign it?

Not unless you have Apple's (or in the case of third-party software, the developer's) private key.

It's not a big change... it's very small.

Code-signing doesn't care how small the change is. If it's changed at all, the code-signing is invalid. Some apps can be hacked in very evil ways just by changing one byte of the code.

[voodoo]

I'm experiencing a fast-increasing dislike of codesigning applications. The possibilities of abuse are immense.

I don't approve.

V

[CharlesS]

You'd better get used to it.

Sure, I miss the old days of ResEditing everything, but let's face it - in a world where applications get trusted with keychain settings, application-specific firewall rules, and even root access, we can't have every process on the system being able to modify apps willy-nilly. It's security, and frankly, we need more of it right now.

Plus, I'm personally sick of getting tons of crash reports that were caused by evil third-party hacks rewriting my app in memory. Code signing ought to put a stop to that.

[voodoo]

Originally Posted by CharlesS 

You'd better get used to it.

Sure, I miss the old days of ResEditing everything, but let's face it - in a world where applications get trusted with keychain settings, application-specific firewall rules, and even root access, we can't have every process on the system being able to modify apps willy-nilly. It's security, and frankly, we need more of it right now.

Certainly there are benefits, I'm am wary of the abuse potential nevertheless. It doesn't seem fair to me that the system can decide whether I can or cannot run an app - regardless of my intent or desire.

If this codesigning could be overridden, then it would be very nice. Very nice. While it does provide much needed security it doesn't make sense to have it mandatory.

I wouldn't approve if the firewall in OS X was always on, whether one wished it or not - though there is no denying the security of a firewall.

I doubt this will affect me or many of us in any way, but the way it is implemented is not of my liking. That is all.

V

[CharlesS]

Well how would you propose to override it? The purpose of code-signing is to determine that the application you have is exactly as it came from the developer, and that it hasn't been tampered with. If you allow it to be modified and still pass the code-signing check, then it kind of defeats the purpose.

[voodoo]

Originally Posted by CharlesS 

Well how would you propose to override it? The purpose of code-signing is to determine that the application you have is exactly as it came from the developer, and that it hasn't been tampered with. If you allow it to be modified and still pass the code-signing check, then it kind of defeats the purpose.

Yes, I would prefer to choose personally as the operator of my computer whether or not to defeat this purpose.

Much like I can choose whether I have a firewall active or not, possibly allowing all sorts of nasty things to happen to my machine.

But it is my choice. That I like. It is just my humble opinion.

Code-signing checks could be on by default, advising the user that an app has been modified, but allowing the user to override this and execute the application at his/her own risk.

V

[Kevin]

Originally Posted by voodoo 

I'm experiencing a fast-increasing dislike of codesigning applications. The possibilities of abuse are immense.

I don't approve.

V

If enough people don't buy code signed apps... and if Apple gets enough negative attention from it, they will either find another way so that certain things can be patched, or they will have to deal with all the user complaints that their computers are broken. If OS X had a major security problem like Windows.. maybe I could understand all this. But it doesn't.

Plus, I'm personally sick of getting tons of crash reports that were caused by evil third-party hacks rewriting my app in memory. Code signing ought to put a stop to that.

Just put in your agreement that if you run any third part applications that hack the system you get no help. Like people have been doing for ages.

[Kevin]

Originally Posted by voodoo 

Code-signing checks could be on by default, advising the user that an app has been modified, but allowing the user to override this and execute the application at his/her own risk.

Agreed. Not that code signing, or it's usage is dead set in stone anyhow.

[voodoo]

Originally Posted by Kevin 

Agreed. Not that code signing, or it's usage is dead set in stone anyhow.

True, true. I'm optimistic that this won't be a major issue. Sorry to the OP for the derailing.

V

[Kevin]

It just feels like a very microsonian way of doing things.

[voodoo]

Originally Posted by Kevin 

It just feels like a very microsonian way of doing things.

Microsoft is deeply commited to this.

Not much of a surprise.

Driver Signing Requirements for Windows

Kernel-Mode Code Signing Walkthrough



V

[Kevin]

Originally Posted by osiris 

I wish there was a general preference to turn off all menu flashing when selecting an option - kind of like General Controls back in the OS 9 days. (Why blink 3 times - just do it!)

Yeah I have wished that since OS X came out. A lot of features OS 9 had OS X simply doesn't give you. Even 8 years later.

[CharlesS]

Originally Posted by voodoo 

Code-signing checks could be on by default, advising the user that an app has been modified, but allowing the user to override this and execute the application at his/her own risk.

Well currently, you can run an app even if the code-signing is invalid - it's just that it won't have access to trusted resources such as the Keychain, the firewall won't let it open ports, etc. Because if a virus or other piece of malware infects an app, the last thing you want is for it to be able to get all your passwords off the Keychain and do what it wants with them. The docs do carefully avoid promising that it will always be this way, though.

Of course, the developer can make an app refuse to start up if the code signing is invalid, and in fact I did this for Pacifist. Because you know, my app asks for root access from time to time, and the idea of a virus infecting my app and then either tricking the user into giving it the admin password or just doing whatever the heck it wants with root access frankly gives me the willies.

Originally Posted by Kevin 

If enough people don't buy code signed apps... and if Apple gets enough negative attention from it, they will either find another way so that certain things can be patched, or they will have to deal with all the user complaints that their computers are broken.

Well, I've been doing a more limited form of checksumming on Pacifist for years, and I've received very few complaints about it. Those few that I did receive were all related to people wanting to either delete localizations or strip out architecture code out of the binary to save space, neither of which break Leopard's code signing (each architecture inside a universal Mach-O binary is actually signed separately). Not a single complaint yet about the Leopard version even though my app is signed more tightly than pretty much any other app for OS X. So I wouldn't count on any big revolt due to code-signing, especially if people understand the security benefits of it.

If OS X had a major security problem like Windows.. maybe I could understand all this. But it doesn't.

Yet. An ounce of prevention is worth a pound of cure, especially in this case, where the cure would come after hackers had already stolen millions of people's bank account passwords via a virus infecting an application that accessed the Keychain.

[Kevin]

Originally Posted by voodoo 

Microsoft is deeply commited to this.

Not much of a surprise.

Driver Signing Requirements for Windows

Kernel-Mode Code Signing Walkthrough



V

Guess I wasn't too far off then.

[Kevin]

Well, I've been doing a more limited form of checksumming on Pacifist for years, and I've received very few complaints about it. Those few that I did receive were all related to people wanting to either delete localizations or strip out architecture code out of the binary to save space, neither of which break Leopard's code signing (each architecture inside a universal Mach-O binary is actually signed separately). Not a single complaint yet about the Leopard version even though my app is signed more tightly than pretty much any other app for OS X. So I wouldn't count on any big revolt due to code-signing, especially if people understand the security benefits of it.

Give it time. Not being able to delete localizations is ridiculous. I think I'll send you an email complaint.

But seriously, if you can't delete localizations there is no need for Apple to have that feature built in.

[CharlesS]

Microsoft is doing it because if you want to be taken seriously about security, you have to close certain really obvious security holes, and Microsoft would like to improve their poor reputation for security. Arguing that something must be a bad idea just because MS does it, though, is a fallacy. Just look at it - you've got all these systems that allow an application password-free access to things by adding the app to a list of apps that are trusted - the Keychain, the application-based firewall, etc. If you're going to automatically trust these apps, you've got to be sure that you can safely trust those apps, and the only way to do that is to make sure you're dealing with the same app that you think you are. The only alternative is to do what Tiger did, and throw up a dialog about whether to give an application Keychain access or not every time you detect that it's changed. Aside from being confusing, failing the "mom test" every time, and asking the user a question that he/she can't really know the answer to (the app has changed. should I still trust it? I don't know!), this dialog just ends up training the users to allow it every time, and is therefore worthless as security. Every time you run Software Update, a bunch of apps will throw up another dialog the next time you run them. Cancel or allow? It also allows things like haxies to rewrite an app in memory while leaving the on-disk representation intact, thus allowing a way to get in and stick your nose where it doesn't belong without setting off any alarms.

The thing about code signing is, you can say one time that you trust Mail.app, signed by Apple, to access the Keychain. Afterwards, if a new version of Mail.app shows up, and it's still signed by Apple, we know we can trust this new version, since the only way it could otherwise be signed by Apple would be if someone else got ahold of Apple's private key. So it's more security, less "Cancel or allow", and it's easier to use. It's just that if the app changes, the code signature is now worthless, so it can't be trusted anymore.

[CharlesS]

Originally Posted by Kevin 

Give it time. Not being able to delete localizations is ridiculous. I think I'll send you an email complaint.

But seriously, if you can't delete localizations there is no need for Apple to have that feature built in.

Well, I did make an exception for deleting localizations in my custom checksumming code so many years ago. That was not long after the original 1.0 release five years ago. The only thing that has been able to set it off for a really long time has been stripping the PPC or x86 code, which isn't something that concerns me too much since I consider Monolingual to be malware anyway. And like I said, I have received very, very few complaints about it over the years (and none at all since people started discovering that Monolingual has a way of completely fubaring the OS).

As for Apple, I guess you didn't read my post very carefully, because I already said that Leopard's code signing feature doesn't get set off if you delete a localization, or even if you strip architectures out of the binary.

[Kevin]

Because OS X was having SO MUCH trouble with security before this. No, this seems more like Apple trying to match MS's code signing ability for other things. Like say, selling mp3s. I just read an article about it a few minutes ago. It seems Apple's main concern here is having the ABILITY to do such a thing.

You can increase security without having to go into measures were one can't even change an icon they don't like. That's going backwards instead of forwards. That is WHY I said it was MS like.

What seems to be happening in certain parts of the Application will be signed. Parts that can cause trouble. Parts that most people don't mess with in the first place.

I think some people are running around exaggerating what will and wont happen with code signing. When even Apple hasn't even put anything in stone yet.