Building Google Material themed apps easily with a Golang back end? Lovely!
I really hope the Golang team are considering the QML package as part of the standard library in Go v2, it would an absolutely awesome GUI kit to have as standard!
I also prefer Qt but starting with Qt4 it imposes a minimum memory overhead of 25MiB to 30MiB for even a simple single window application with nothing in it. QML is likely higher. I don't like Gtk3 but they don't have this particular disadvantage. It's too much overhead and I haven't found a fix.
I don't have experience with this specific Go-QML bridge, but I've developed a number of applications with a QML front-end talking to a Go background process via HTTP and/or WebSockets, packaged together to appear as a single app. Works very well.
Qt is obviously very solid, definitely "production quality," while QML is solid in the sense of not buggy and the UI looks/feels/performs quite well on Windows/Mac (haven't tried on Linux). But QML can be slightly to considerably irritating to use because it's not always clear or intuitive how to accomplish something or why something isn't working the way I expect, and I usually don't find many examples/tutorials when I turn to Google. That said, it's far, far more enjoyable to build an app with QML than with HTML/CSS/JS; I'm way more productive and the result is an actual application rather than a weird facsimile.
Yup[ thats exactly how I'm using it: a simple Golang program that just wraps the QML program and the websockets, JSON-RPC features to make calls and receive events from a Golang backend process.
SOOOO much nicer than HTML/JS/CSS trainwreck that is modern web development.
> "This is so figgin cool, I woke up my wife this morning and showed her. She had no idea what she was looking at, but I know she recognized it as figgin cool as I'd normally get punched for waking her that early on a Saturday."
OpenGL is native. I assume you're thinking of the native WIMP APIs such as Win32, Cocoa, and so forth. But OpenGL does run natively on the client OS - even if the widgets then have to be re-implemented.
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.
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.
>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.
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'.
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.
The widgets are running natively on the client. There's no interpretation / JIT layer between the two like with a web stack. All you're doing with OpenGL rather than Win32 is drawing your widgets to the graphics buffer directly rather than using Win32 libraries to draw the widgets. So, to go back to the original comment, it is a "native GUI" it's just not calling Microsoft or Apple's toolkit libraries.
This might sound like nitpicking, but you also have to bare in mind that it's not always as simple as saying "You want to write a native app, use Win32 or Cocoa". Half the time developers are running wrappers around the toolkits such MVC, .NET and wrappers to allow non-C et al languages to call C libraries. And even if you do want to directly call the "native" OS libraries, often there's more than one to choose from, eg on Linux things gets pretty complicated as there's several toolkits available (GTK, Qt, Motif, etc) and then a multitude of version of many of those libraries. Granted this doesn't solve the "many standards" problem, but at least it's a single dependency that runs natively on the client and draws directly to the graphics buffer - which has got to be better than the plethora of other cross platform implementations out there.
You still don't get it. Native widgets are not just a few state pictures that you draw. They have all kinds of behaviors that are tied to the OS settings.
Please forgive me if the title isn't 100% accurate. After thinking about it, this possibility of combining both native and web view rendering seems like it could be an interesting approach for a wide variety of potential use-cases.
Are there any nice tools out there for creating apps that render to both native + web?
https://github.com/go-qml/qml
Even better with the Material additions from here:
https://github.com/papyros/qml-material
Building Google Material themed apps easily with a Golang back end? Lovely!
I really hope the Golang team are considering the QML package as part of the standard library in Go v2, it would an absolutely awesome GUI kit to have as standard!