<p><a href="https://github.com/google/gxui">GXUI</a> was probably our best shot for a cross platform GUI library written in pure Go.</p>
<hr/>**评论：**<br/><br/>lapingvino: <pre><p>I think for a cross platform GUI more than anything we need a good plan and a good design. I think we would get the most using a design similar to database/sql: a simple UI system with drivers, so we can e.g. start designing commandline/curses and then deploy as web or GUI. The problem there is of course that SQL is a relatively well-defined language you can use on most databases, and we don't really have something like that for UI, so creating something similar, e.g. using the template system, would be a great help :). Maybe use the Glade file format for that, so we plug right in with existing external tools?</p></pre>koffiezet: <pre><p>Cross platform GUI frameworks are a hugely complicated mess which involves inventing your own GUI API, and it'll never be as good as a native GUI. The only option here is to create Go bindings for existing frameworks imho, preferably QT.</p></pre>boomshroom: <pre><p>Which is a cross-platform GUI framework that isn't a native gui.</p></pre>koffiezet: <pre><p>I'm well aware of that, which is why I pointed it out. Why re-invent the wheel?</p></pre>boomshroom: <pre><p>My point was that QT has a lot of the problems you were complaining about. The only thing you said that doesn't apply to QT is "inventing your own GUI API".</p></pre>lapingvino: <pre><p>Those are already out there, and tbh I really want cross-platform above native in most cases.</p></pre>computesomething: <pre><p>Agreed, I'd rather have a consistent GUI look and behaviour of my application across all platforms than doing a 'emulation' of each platform's native GUI.</p>
<p>I also think mobile/consoles etc have shown that users don't really have a big problem jumping between different looking GUI's as long as the core principles remain consistent, so I don't think a non-native look/feel is a barrier.</p>
<p>And from a pure Go perspective, it would certainly be interesting to see a whole GUI framework implemented natively.</p></pre>iends: <pre><p>A pretty solid one exists in <a href="https://github.com/go-qml/qml" rel="nofollow">https://github.com/go-qml/qml</a>.</p></pre>koffiezet: <pre><p>With every commit being over a year old, it doesn't look like it's being maintained...</p></pre>iends: <pre><p>Or maybe it's stable?</p></pre>dmikalova: <pre><p>Nope, it's "<a href="https://godoc.org/gopkg.in/qml.v1">in an alpha stage, and still in heavy development.</a>"</p></pre>cheemosabe: <pre><p>There's always <a href="https://github.com/golang/go/issues/11818">https://github.com/golang/go/issues/11818</a> (<a href="https://github.com/golang/exp/tree/master/shiny">https://github.com/golang/exp/tree/master/shiny</a>).</p></pre>boomshroom: <pre><p>I think there are plans to write a gui toolkit on top of shiny, but they're waiting until it becomes stable enough.</p>
<p>I have personnally been using shiny for a proof-of-concept game engine with the main issues I've run into being extreme input lag anywhere except linux and many input events not being implemented.</p></pre>dfab54: <pre><p>Is go-gtk being maintained? Would you consider this the most complete out of all the gui libs?</p></pre>computesomething: <pre><p>Last commit was about a month ago, but I imagine it's quite stable since it's more or less just bindings.</p>
<p>edit - there's this for GTK3 as well, which seems more active:</p>
<p><a href="https://github.com/gotk3/gotk3" rel="nofollow">https://github.com/gotk3/gotk3</a></p></pre>iends: <pre><p><a href="https://github.com/go-qml/qml" rel="nofollow">https://github.com/go-qml/qml</a> is probably your best bet.</p></pre>Sk1LLb0X: <pre><p>you guys should take a look at <a href="https://github.com/oskca/sciter" rel="nofollow">https://github.com/oskca/sciter</a>
the gui is made of HTML/CSS so it will look the same on all platforms, its really small compared to webkit</p>
<p>theres also Qt bindings in go <a href="https://github.com/therecipe/qt" rel="nofollow">https://github.com/therecipe/qt</a></p></pre>Testiclese: <pre><p>Out of curiosity - <em>why</em> do you need a native GUI framework in Go? I don't think it's a problem that many people are bent on solving. It might help to take the web app approach here. </p>
<p>I write my web GUI's exclusively in HTML/Javascript/CSS. <em>That's</em> the language of the Web, period. That thin GUI talks REST api's to my backend, which is Go. I use Go where Go is appropriate, not everywhere for the sake of "everywhere".</p>
<p>Sure, someone's basement project might be "Go->Javascript" generator, but:</p>
<ol>
<li>It will be abandoned, guaranteed - just like the ones mentioned here</li>
<li>You're swimming against the tide</li>
</ol>
<p>Same here. Yeah, it's more <em>pleasant</em> to keep your stack Go from top-to-bottom, but that's becoming more and more a pipe dream. </p>
<p>Write the <em>thin</em> GUI in Qt, or GTK, or Cocoa, or WPF or whatever, and if you insist on using Go, follow the web app model - make a Go RPC server and let the GUI be the client. You could still keep the majority of important code in Go. </p>
<p>In fact, that's probably better design anyway - if you separate your layers well enough, you could then port the GUI portion to a whole different GUI toolkit down the road with less effort. </p></pre>neoasterisk: <pre><blockquote>
<p>Out of curiosity - why do you need a native GUI framework in Go?</p>
</blockquote>
<p>Because by using Qt and friends we are bringing the C world in our project, along with all it's flaws. The Go team recently got rid of all the C code in the project and for very good reasons. Go is easier to write, easier to debug, it has better tooling, profiling, testing and makes concurrency easier. Not to mention better modularity and trivial cross compilation.</p></pre>Fwippy: <pre><p>I don't think it's really fair to categorize <a href="https://github.com/gopherjs/gopherjs" rel="nofollow">gopherjs</a> as a "basement project."</p></pre>
