[roel_v]

For 20 years, 'native GUI' has meant 'using the system's toolkit', not 'doesn't use web page to half-ass impersonate local application'. If this is really only OpenGL, then a more apt title would be 'Go + gxui: Rendering triangles very fast on any platform?'. There is quite a gap (like, Grand Canyon sized gap) between 'able to render what OpenGL provides' and 'render GUI'. Even building a UI as primitive as Motif is many man-months of effort for any serious application, if all you have to work with is OpenGL.

[laumars]

I don't think anyone has ever said "native GUI" in the last 20 years. It's pretty nonsensical if you actually break down that passage to it's core components because it doesn't actually describe what specifically is "native":

- the libraries? But that's a programming interface for drawing graphics, not itself a graphical interface.

- the aesthetics of the widgets? This would be a more accurate interpretation, but the problem with that interpretation is that you could design web pages to look like Win32 forms and people widely consider HTML applications to be native.

- the layers of abstraction between your code and the rendering of your user interface? What about people who use .NET, MVC's or other wrappers?

- the author of the toolkits (eg MS toolkits for Windows, Apple for OS X)? So would that mean there's no native Linux GUI's because Linus Torvalds hasn't written any Linux widget libraries?

Saying "native GUI" doesn't really describe your point. Which is why I made the distinction between widget reimplementation being drawn natively on the OS vs widgets being drawn via Microsoft or Apples own APIs. This project being the former and your point being the latter - both being native in their own way yet different in their details.

[coldtea]

>I don't think anyone has ever said "native GUI" in the last 20 years. It's pretty nonsensical if you actually break down that passage to it's core components because it doesn't actually describe what specifically is "native"

They have, and they have said it exactly as the parent mentions.

See for example complaints about webkit based apps not looking and behaving native on iOS, and similar complaints for all kinds of desktop apps using some third party toolkit: from Eclipse and Firefox to Opera (when it used to do that) and GIMP on OS X, anything Swing.

>it doesn't actually describe what specifically is "native"

It's pretty much agreed what's native is the specific, OS-based (or user-chosen-toolkit-based on Linux) implementation of widgets and controls, as it pertains to both look and feel.

There are even whole terms often associated with such complaints, such as "uncanny valley" etc.

>So would that mean there's no native Linux GUI's because Linus Torvalds hasn't written any Linux widget libraries?

No, for a Gnome user, non native is anything non Gnome (GTK). For a KDE user anything non KDE. But the analogy is not perfect, because Linux doesn't come with a pre-built specific GUI lib for all users, so users are accustomed to a hodgepodge of varying behaving and looking apps to serve all their needs anyway, with some sugar of cooperation for things like drag and drop on top.

[roel_v]

Well I guess we have to agree to disagree. Anything using the word 'native', in a UI toolkit context, has, in my experience, meant for over 20 years: 'uses the system-provided API's to render widgets, to ensure exact match with what the user is used to on the platform'. So, Qt is not 'native', because it uses only the most basic underlying drawing API's to approximate how controls look on that platform.

The concept of 'native' being 'not through a html/css rendering engine' is only a few years old anyway (as in, 'Cordova is not native, Objective C app is native). The whole circumstance that things that are trivial and have been non-issues for 2 decades are, the last few years, newsworthy because first someone injected a huge, straight jacketed abstraction layer (a browser) and then someone else pierced that layer (webgl, LocalStorage, <audio> etc) is a never ending source of (alternating) amazement and annoyance for me, but I guess that's just because I'm a grumpy not even that old man who used to be with it, but then they changed what 'it' was, and now what I'm with isn’t it. And what's 'it' seems weird and scary to me. But I digress.

But then still - this project doesn't even do what you call 'widget reimplementation being drawn natively on the OS'. It's just a very basic OpenGL interface. Which might be quite an accomplishment in the Go ecosystem, I don't know, I've never even downloaded the language. Mostly because I could find few to none examples of it being used for non-serverside applications. My point was that the title, and the bug report, and the discussion in that bug report evoked (in me) a cascading sequence of 'oh, is that all'.

[laumars]

This project just means the GUI is drawn natively rather than via a browser rendering engine.

Which isn't that impressive on the face of things, but bare in mind that Go is really known more for command line applications and web serving. So the ability to draw anything natively - be it via OpenGL or using Window et al's own toolkits - isn't a concept that's been explored by many.