It is very rudimentary; all the basics are there, but there are some glaring things I couldn't figure out yet - like how to move the Window to a new screen position, things like that. Might be my ignorance though, I've only had 15 minutes of glance at it, and as I'm mostly interested in learning Go casually, maybe there's some things I've missed ..
It may have been done with Wayland in mind, where there is no client-side way of setting the window position, or even querying it, since wayland does not let the client know. The position of windows is managed entirely by the wayland server.
While I do have Wayland in mind, that's specifically for what I can do with the GTK+ backend when running against GTK+'s limits. For this particular feature, there's a different rationale, but I can't remember what it was right now. That being said, I may add such a thing in the future (there's something in futureplans.md about centering the window right now, so...).
And yes, this is still rather incomplete (I'm surprised it's getting so much attention this early!); please feel free to make suggestions!
With the caveats that I haven't used it yet, and that I don't know if it reflects actual product quality: after a skim, I can say the code itself is pretty messy. Randomly formatted, nonidiomatic naming conventions, lots of commented-out blocks and dead code, haphazardly organized.
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?
All indentation ones except the L35-37 ones are lack of go fmt. I will go fmt once I can double-check exactly what go fmt changes.
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.
Don't sweat it too much. The first thing that happens whenever anyone publishes any Go code on the internet is a random commenter pops up and criticises it for being "unidiomatic".
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 not an objective term, but people use it like if it were.
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.
I think that's a stricter definition than what most people think of when they criticize code as being unidiomatic. However it's still very subjective. From 1 to 4 are objective measurements. Point 5 is somewhat subjective. Points 6 and 7 are simply a matter of my personal experience through life and how circumstances led me to encounter a specific subset of code; entirely subjective.
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.