What random formatting do you mean, other than what go fmt would produce? What unidiomatic naming conventions? I thought I removed all the dead code... which ones do you still see? What suggestions can you make about organization?
63 karma · joined June 6, 2014
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.
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...
And yes, this is still rather incomplete (I'm surprised it's getting so much attention this early!); please feel free to make suggestions!
The only real issue is that the things you shove into Objective-C containers must themselves be Objective-C types, which means using NSNumber and NSValue everywhere for raw C types. The new Objective-C @literal and @(expression) syntax, however, should make such code cleaner in the future...