Would it be possible, long term, to use Qt? I mean switch the current components to be based on Qt and then, over time, actually start using Qt?
It's getting there, but I've only really done any real coding in anger in the last 5 months and this is a 25 year code base...
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 notice the Linux APIs call GTK which, while I can understand the logic of, I rather liked the Qt Go Bindings I played around with last year.
And yes, this is still rather incomplete (I'm surprised it's getting so much attention this early!); please feel free to make suggestions!
> What random formatting?
> What unidiomatic naming conventions?
L35-37 I'm not sure what problem that has; I just put the very long bitmask on its own line.
The underscores in our_xxx_xxx_xxx I don't think would be much of an issue. They unintentionally match the GTK+ naming conventions. I don't know why I did them, but I don't consider it a world-ending issue worth fixing. Same for _xSysData, but in that case the _ is there in case I accidentally said xSysData somewhere else.
or lines 10-12 of this file:
those were the first to files I picked.
I have no comment on organization--something I struggle with.
As for area_darwin.go, though it's a comment, it's actually C code being sent to an FFI: http://tip.golang.org/cmd/cgo/
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.
> 'idiomatic' is used as newspeak for 'not the style I
> personally recognize as being the true Go way'.
There's a true Go way, the style used in the stdlib; but even the stdlib is not consistent and you need to pick and choose. Then the standard library doesn't cover all possible cases.
My definition of idiomatic Go code is:
1. It passes gofmt
2. It passes govet
3. It passes golint
4. It checks it's errors.
5. It looks like code in the stdlib.
6. For the rest, it looks like code written by other
people that I recognize as being good Go developers.
7. For the rest, it looks like my own code.
(wakeup doesn't run with the current version though, missing window w in args, but that's an easy fix..)
So from 10 minutes of looking at it and getting wakeup built, I've learned some new Go stuff. Thanks for that! :)
EDIT: Granted, it is an unusual formulation, and far less convenient.
Granted, there are some quite complex systems out there where generics could deliver truly valuable type safety. I doubt all the systems that are that complicated really need to be.
The likelihood that a programming language feature will be over/mis-used is directly proportional to how nifty it is.
EDIT: Surprisingly, programmers do a lot of this "just knowing." You'd think that a supposedly quantifiable field would have more, quantification. Going by "guts" is particularly bad in big enterprises, where decisions are often more about politics than about quantifiable results.
The former means more code. That can be hidden out of view, but it means more work when fixing bugs in that code, introduces subtle bugs when one forgets to apply a bug fix to a 'copy', and slows down compiles.
The latter means adding casts to your code that make it harder to read and (more code is buggier code) also runs the risk of introducing bugs.
The two-and-halfth option is to use some preprocessor to generate code variants for you. IMO, that is just a bad implementation of generics.
Yes, that is not quantified, but I think it covers the how* part.
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...
Your post is a good post.
GTK+ on Windows doesn't really have a particularly good reputation among myself and some of the people I know, and I didn't know native GTK+ for Mac was a thing until very recently.
It's written by the same guy who made the awesome MongoDB driver for Go, so I have high hopes!
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.
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 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.
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.
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."
It's a shame no one invented the web browser yet :)
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.
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.
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)
Looking and feeling native involves so much more than just using native controls.
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.
If this code works and is tested on OS X, Windows, and Linux, then one would assume the author has at least one test implementation, so it wouldn't be too far of a stretch to screenshot it, especially given that cross-platform toolkits have never, in my experience, actually looked or felt native on OS X.
This library is clearly not written for the authors own personal benefit. Just look at the old readme; it's obviously written for other people to use and play with.
Examples and screenshots are good; there's no reason for anyone to be defensive about not having them; the author can just add them. It's no big deal; it's helpful feedback.
> 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.
You don't need to polish something into a shiny gem of perfection before showing it to people; and you certainly don't need to get defensive about feedback (which in this case wasn't harsh at all); especially not for something out in the public that various people are already using.
Iterative feedback and improvement can only happen if you get feedback.
It's tempting to say that something isn't quite ready for others to see yet, it needs a bit more polish, and bit more internal beta testing, a bit more perfecting before you show it people.
...but I'd say that most cases, it's not the right attitude to encourage (although there are some very specific cases; like product launches where a botched launch has long term negative ramifications).
Have a think about what you wrote there.
You're endorsing self defensive attitude of perfectionism that you're criticizing.
No. I'm endorsing thinking a few steps ahead when criticizing. I think that should be the lower bar for feedback. Otherwise, it's too easy to engage in "feedback" as a means of self aggrandizement while humiliating others, which is as close as we can get to the Internet's official sport. (In particular, knee-jerk statements can be used to win over an uninformed crowd. They are the favorite ammunition of trolls.)
Is it unreasonable to expect some kind of demonstration of what the code will
accomplish before having to actually write a project which uses it?
Perhaps word it in a more friendly way somehow?
Perhaps that it was a bit too harsh, and humiliated the original author?
I totally get the basic point you're making, but it's just completely ridiculous to be making it in this specific case.
Yes, and he should produce a tree of possibilities and if he doesn't have evidence precluding them all, he should briefly hypothesize about the most likely positive possibility while making his request for further information.
Another way to interpret this: He should think like a creator as opposed to a consumer. I think it's fair to ask this of visitors to GitHub, as it's fundamentally a site facilitating the process of creation.
We all need to do more reflection before writing, myself very much included. Unfortunately, the reward structure of the Internet combined with human nature seems to encourage the opposite.
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...
.net itself is what you're thinking of.