To be fair, I do it anyway. My applications run on Windows, OS X, Linux and BSD. I even have a 'stub' GUI so that many can run on the command-line anywhere. I still believe that a Mac app that "sort of looks like a Windows app" is better than "no app at all." But I know that if I were selling a product, "good enough" wouldn't cut it.
It's a bit annoying though how Microsoft and Apple have extensive HIGs, and yet they constantly violate them and go in totally new directions anyway. At the least, it'd be nice if third-party vendors got the same apologist leeway to violate the HIGs, but I understand why first-party vendors get that and we don't, since it's their OS.
> I mean, a unified menubar vs the separate mene/titlebar of Windows/Gnome is exactly the kind of thing I'd expect to be abstracted away by a unified GUI kit.
It sounds like it, sure. Qt tries really hard to do a lot of this stuff. There are special flags you can set on menu items so your preferences and about items automagically move to the right spot. But it's deeply limited: sure it moves your about option, but it doesn't collapse the menu item separator above it, so your menu ends with a separator. Yes you can have a generic FileOpen dialog API, and there's a flag in Qt to make it use sheets too. But what if your app didn't expect another window to remain active during that modal event? This goes on and on and on and on and on.
"But you don't have to take my word for it," look at the reception of Qt apps among OS X users. The only time it's really accepted is when there's no Cocoa-native alternative.
And the more you abstract, the less control you have to really refine the end product. Probably the best and worst solution to cross-platform is going to be declarative user interfaces, something Qt has been dabbling in lately. I just really don't see that approach scaling to rich applications like graphics editors and music libraries.
> I absolutely would expect a unified GUI kit to be tremendously limited by selecting a common baseline of widgets that share functionality and forcing you to fit into a common paradigm that can be easily translated across platforms.
And end users won't like that. Windows users like that little spin box to select numeric values, and jump lists. OS X users like their badges on the dock icons. Gnome 3 users like their new fused title bar to system menu thing.
It's like 3D graphics and the uncanny valley. 90% isn't good enough. It's the little details that make someone say, "yeah, this is definitely a Mac OS X application."
I absolutely would expect a unified GUI kit to be tremendously limited by selecting a common baseline of widgets that share functionality and forcing you to fit into a common paradigm that can be easily translated across platforms.
The problem is that in experience I see the exact opposite - I see "cross platform" kits that make me define my own right-click context entries when the conventions for those are heavily platform dependant. I need a right-click properies dialog... on Mac, I'd expect my toolkit to realize that this is called Get Info.
Again, that means creating more rigorous definitions. Where suddenly you just slapped on right-click menu items willy nilly, suddenly you actually have to consistently define "this is my properties menu-item" so that it appears correctly across multiple platforms. And that's a good thing - so many platform-specific GUI conventions are just that: conventions instead of being hard-coded.
How many times have people copied the Windows-standard menu items and re-coded "file->save, exit edit->copy, paste, select all help->about" and yadda yadda yadda.
I'd always expected to find GUI kits that properly codified these things, because they do exist on almost every program on platform they just have slightly different conventions that could easily be handled by the middleware.
But instead we just give the coder "here's a menu class" and they re-build teh Windows menu and nobody's surprised to find it's still the Windows menu on a Mac.
tl:dr;
The problem is that GUI kits encode just the implementation of the platform, when they also need to encode the conventions of a platform. I think we could see the "cross platform" kit have some measure of success if this were done.