Biggest flaw/mistake in Windows are Personalize Menus (that horrible feature that reorganize/hide part of PullDown menu in e.g. Office 2003).

If you use PieMenu (or any other) most important part is that all options are always at same place! - if I need to search/look/analyze every-time when PieMenu open than I rather stick to PullDown menus because

1. all available options in program can be see in less than a minute - they are all in PullDown menus, there is no need do guess what Icon in ToolBar represent - in PullDown menu you always have writen items.

2. PullDown manus are always same! IF some option is not available at certain moment than it is grayed (but you still know that it exist!).

these two things are greatest strength of Mac (and for Atari OS ;) ) and I am not sure it could be kept with PieMenu… (PieMenu will reorganize it self depending from object (and other variable) so you will never know what are all available option in program and you can not be sure that option that you are need are at same place all the time)

——–

Considering Carbon app - it should be droped! If I turn on Quartz2DExtreme (I forgot new name for it) than everything works fine and FASTER except Adobe application! Only Adobe application have some glitches in UI and I suppose it is because code is Carbon based.

———

One more thing: I am not sure about Multitouch - what are exiting one input devices for desktop computer that are multitouch capable ? I am not sure about this… combine desktop + multitouch trackpad + I will need mouse for Adobe app anyway. Only multitouch monitor will be step forward (like Wacom monitor table + multitouch capabilities)

@worker201: Hear, hear. Even if we didn’t get full-on skinnability, a few more options would be nice.

True Resolution Independence can’t come too soon! From Tiger to Leopard, the amount of information available in the Finder window Sidebar has increased dramatically, but with that, the text has shrunk with equal drama. Tiger’s scaling Sidebar icons and text was a good feature, which I do miss (somewhat).

Not all of us have perfect vision, nor do we want to work with a magnifying glass either. There’s got to be some way of adjusting that. If I could assign a Condensed font to the Sidebar text, that way text size could be cranked up a few notches, while limiting the horizontal spread.

The number of Menu items that third party applications and utility developers have added to OS X is out of hand!

On my MacBook Pro, they go nearly halfway across the Menu Bar. Granted, I’ve got lots of things loaded, but over half are Mac OS X items: Bluetooth, Displays, clock, battery, Airport, volume, clock, Spotlight, Input menu. There are more menu items I’d add if there were room Menu bar real estate!

I’d love to see some kind of Master Menu Items thingamajig to manage all these things. The old Control Strip wasn’t half bad, actually. Even if Apple somehow combined all the hardware related items (Airport, Volume, Displays, Bluetooth, etc.) into one item would be a big help.

So, what’s with the movement toward dark and darker windows, toolbars and menus? Personally, I find the drifting toward darkening nearly every GUI element a bit claustrophobic feeling. Though it does make sense to have darker control elements and whiter working areas.

Dark does not necessarily equal elegance or enhanced usability. Ideally, there would be some way to control the lightness or darkness of these things.

As OlsonBW mentions, Grab is the perfect example of this: in order to make those menu items available, you need to have Grab.app running in the background first. So what’s the point of it being a Service anyway?

Then there’s the Look Up in Dictionary item. Okay, this works fine and does exactly what you’d expect, but I’d argue that the floating dictionary/thesaurus invoked by Ctrl-Cmd-D is more useful and feels a lot more like a service: it doesn’t demand a change of focus to another application to accomplish the task while fully leveraging that application’s functionality, and offers one-click access to the full application.

As it stands, Services are one of those funny little “power user” nooks of OS X that have a lot of power and functionality to expose, but I very much doubt they’ve been lurking there in the application menu all this time purely because nobody could be bothered to remove them.

Here’s a short bit I’d like to comment on: “We didn’t have the processing capacity to rapidly draw menus like this ten years ago, but we sure do now.”

No, that’s simply not the case: we had more than enough power back then with currently available hardware to rapidly draw menus of fairly large capacity with bitmaps galore, if you wanted, and it wouldn’t matter if you were referring to using a PPC processor or x86 available at that time. I speak this from having an old Mac of that era (266 Mhz G3 Sonnet upgrade card Hackintosh with a 40 Mhz FSB) running BeOS 5.03 that can update menus quite fast, thank-you-very-much, combined with having written Windows NT/95 software for 80486 boxes in CNC machines that not only were controlling CNC hardware in real-time, but also updating an OpenGL rendering of the part as it was being machined, combined with scrolling through the CNC program it was executing, and all of that far faster than any menu needs to be displayed, with no tearing of the screen. It all comes down to proper use of graphics buffering, and appropriate data buffering, something that’s been old-hat to serious developers interested in making things look nice and work smoothly: it isn’t rocket science, it’s only a matter of wanting to make things look/act right, and doing it.

The Apple Mac OS before OS X may have had a harder time doing it and smoothly multitasking, since it was still largely cooperative multitasking, so you were at the mercy of whatever the application that was running that had the CPU at that instant. If it is the one that needs to process the menu, you’re fine, but otherwise, well… That’s no longer the case, however, and yes, that can make a HUGE difference.

So, could hardware of that time do the smooth rendering of scaled graphics you can see now with the Dock? Again, if you had things cached and pre-scaled, that’s not a problem from a technical standpoint. However, the machines of that era (Windows and Macs) didn’t have as much RAM 10 years ago as they do now on average. It all comes down to what your priorities are.

Oh, a fun tidbit about how “slow” menus in Windows 95 and some other systems are perceived to be: there’s actually an artificial delay between a right click and when a menu is displayed, to minimize false triggers. This parameter is modifiable via the Registry, and can be set with Power Toys (I think that’s the name) or you can hack it yourself. In other words, when setup appropriately, a Windows 95 box from 1995 with enough RAM can be quite snappy for the GUI!