Native GUI library for Go

Nana looks interesting - I'm always looking at C++ toolkits to better understand how they work. I was looking at it's event system, seems pretty nice. gtkmm also has a nice signals system also.

But yes, rewriting in D would be more than complex. LO has over 7 million lines of code, the real issue is that there is still a lot of cruft (e.g. the Resource class, tools, etc) and we are progressively working on removing this and replacing with saner libraries, such as boost.

Interestingly, VCL actually works pretty much by itself. I recently resurrected some VCL demos and got them to work as standalone executables. VCL could actually be as clean to work with as nana, but the guts need a rewrite. And it would do it in a cross-platform way, but with largely native widgets.

I'm beginning to think that "idiomatic" is actually a portmanteau of "automatic" and "idiotic" because it's such a knee-jerk reaction in the community now.

If it's flaws in your variable naming and indentation, let it slide. If it's flaws in the logic or functionality, deal with it.

EDIT: Granted, it is an unusual formulation, and far less convenient.

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.

GNOME's guidelines (https://developer.gnome.org/hig-book/stable/controls-lists.h...) say > Consider using a check box list for multiple-selection > lists, as these make it more obvious that multiple > selection is possible:

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

So there's that.

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.

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."

As for screenshots, I suppose I could upload a screenshot of the test program, but I'm not sure how much that would accomplish. I think a basic tutorial with screenshots at each step would probably be more useful, as it shows how the package works...

> Oh please, what kind of excuse is that?

Just demonstrated tptacek's point. The author could be at a point where he wants others to see, but isn't quite ready for places like HN yet. In that case, it's not an excuse. Attitudes like this encourage pathological perfectionism.