|
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'. |
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.