On Mac OS, it's extremely rare that 'platform-native' cross-platform GUI libraries actually 'look like your platform'. Most are subtly wrong, feel less usable, don't conform to platform guidelines, etc.
It's extremely rare to see a cross-platform GUI on OS X that doesn't feel like it's just a reskinned Windows or GTK+ app, which makes it cumbersome to use.
I wrote a cross-platform library that is the thinnest possible layer around Cocoa, and creates the actual Cocoa controls directly. They are truly 100% native widgets.
And yet, it's exactly like you say. It has nothing to do with the base widgets. The problem is that to look native on OS X, you have to use widgets that only exist on OS X, like their merged titlebar+toolbar that changes and resizes the entire window content used on preferences dialogs, or the blue left navigation sidepanel, or the big question mark button, or the segmented control, or the color selection popup menu with the wide color boxes in each list item, or the combo box zoom setting in one segment of the status bar.
And then your labels have to be right-justified while the controls are left-justified against those. You have to add about three times as much spacing between widgets as on other platforms. You have to have a single menubar that's outside the main window, and always has a "program name" menu where your preferences option has to be, a view menu, a window menu, and a help menu.
You have to be sure to tie in to all the OS X only things like AppleScript, Core(Image, Audio, ...), dialog sheets that slide down on a window and then are only modal to just that one window, etc. Your message boxes can't have titles anymore, but everywhere else expects one.
Even if you tried to add the extra spacing and hack in those OS X only widgets to Windows and Linux, then the Windows/Linux versions would be super hideous and unnatural. By the time you customize all of that, the code's a bigger mess than just making two separate GUIs. Defeats the entire purpose of using a cross-platform toolkit.
Bottom line is that Apple just does way too much stuff differently to be able to craft a cross-platform app that looks great everywhere with no platform-specific customizations.
And now Metro, Gnome 3, Unity and KDE 4/5 are trying to go in entirely different directions as well. And iOS and Android are big targets now, too. Sadly, the dream of write-once, run-anywhere and look nice is dead.
I keep hearing this kind of defeatism about cross-platform GUI items and it rubs me the wrong way. 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.
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.
> I keep hearing this kind of defeatism about cross-platform GUI items and it rubs me the wrong way.
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."
The web works for many classes of application, but it definitely does not work at all if you need raw CPU performance. And it never will with the likes of dynamic languages like Javascript. You're never going to see Dolphin, the Wii emulator, running decently inside of a web browser on top of JS, just because there's WebGL. It would also be idiotic as all hell for someone to run John the Ripper in Firefox.
The web is also the antithesis of platform consistency. Every last web page and web app is increasingly more and more about demonstrating artistic style.
Plus I really don't like being at the mercy of web apps. Google has shown me that they'll yank them away whenever they want, or just radically redesign it overnight and force me to use the new version, even if it loses functionality I needed.
I have a very good feeling telling that to byuu isn't going to end well...
That being said, byuu is absolutely correct. It's one thing to make a program look like all the other programs on the target platform, but it's something else entirely to make it feel like one as well. You'll need to compromise quite a bit, as even when you go into raw event-handling no two systems are alike. You can see olddocs/areaplan.md in my repo as an example of where this gets especially hair-pulling, or all the places in the documentation where I mark some subtlety as implementation-defined or system-defined.
Not even the big packages are immune. Look at Qt's QFormLayout type, which is a dedicated layout for aligning labels properly on each platform. (I'm going to have a similar thing eventually; that's why my docs presently have a TODO on vertical alignment with Label.)
And yes, human interface guidelines can differ in very subtle ways. As an example, take multiple-selection listboxes. There are two ways you can implement this: as a normal listbox that you can select multiple items of, or as a list of items with checkboxes that you check to mark as selected.
Microsoft's guidelines (http://msdn.microsoft.com/en-us/library/windows/desktop/dn74...) say (emphasis preserved)
> Given this clear indication of multiple selection, you
> might assume that check box lists are preferable to
> standard multiple-selection lists. In practice, few tasks
> require multiple selection or use it heavily; using a
> check box list in such cases draws too much attention to
> selection. Consequently, standard multiple-selection
> lists are far more common.
And Apple's guidelines (https://developer.apple.com/library/mac/documentation/UserEx...) don't say anything too clearly, but DO say that
- scrolling lists are selected traditionally (not checkboxed)
- but a menu-style list should use check marks instead
As someone who has worked extensively within Gnome's HIG, Apple's HIG, and with frameworks such as QT/GTK+/Cocoa, I fully agree with your and byuu's comments.
I was merely pointing out that the market seems to be pretty content with web apps as a solution to "write once, run anywhere, look nice" (even if here, the "look nice" doesn't include "look native" - but those are 2 different things)
In that case, I should have clarified "look nice, and native." I think most Qt applications do look nice on OS X. Nice alone just isn't good enough, though. They want consistency with their other applications.
There are a million different ways to look "platform-native". I'd like to know what exactly they got right and what they got wrong before simply jumping in.
For the record, and this applies to all comments above and below: by "platform-native" for this package, I do no custom drawing; everything is deferred out to the underlying system APIs. So this actually uses Cocoa on Mac OS X (you can see the .m files as well) and the Windows API on Windows (which is part of the reason I didn't go with just having Qt bindings).
wxWidgets and <del>Swing</del>SWT are also platform-native. Now find me a single wxWidgets and SWT app that doesn't look slightly off on Linux and OS X.
Looking and feeling native involves so much more than just using native controls.
Swing is NOT platform native, that's why SWT was developed in the first place. Swing can use native look-a-like theming but it's not the same thing as SWT's actual, truly native widgets (with native keyboard shortcuts, system services..).
wxWidgets and SWT are about as native at it can be in a cross platform GUI library. I don't see why you'd need a screenshot of the go library, it would look the same as a typical wxWidgets or SWT app, which is to say, it uses native controls, but might not be designed according to the "common" UI conventions of the platform.
I use SWT quite a lot and while it's not perfect I find that it works brilliantly in most cases. I encourage the authors of this Go UI library to study SWT and crib heavily from the library internals. Otherwise they'll be sorting out bugs and corner cases that IBM has fixed in SWT long ago.
