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?
> "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."
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.
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.
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.
One can easily extend that logic by saying something that is running Cordova is giving a native GUI to a iOS or android application, because all of it is natively rendering on the device.
Usually it means people are running the widgets that are coming from the vendor's toolkits. Windows: Win32/WPF, OS X: Cocoa, iOS: CocoaTouch, Android: etc. and so on.
That distinction is somewhat important because it also means the easiest way to get stuff like that running is typically with the language those libraries are written in: C++, Objective-C (or now Swift), Java, etc. It's like the holy grail of write once, run everywhere. Write it in one language and somehow have it run on the native (vendor) toolkit on every platform out there.
I've not had any exposure to Cordova so I'm not going to comment on that specific comparison. But semantics aside, I do think all these arguments are very much against the spirit of this submission. And that's a large part of the reason I was defending their usage of "native" and "GUI". I just didn't realise the can of worms I was opening...
But that's not the sense that "native GUI" has ever had. Widgets are only part of the picture, regardless -- a GUI is defined by the layout, behavior, interaction model, and widgets.
No, nothing at all is native. That it's rendered in GL doesn't make it native. It uses a cross-platform events layer, which is by definition non-native.
Anyway, this argument is ridiculous because all my point was, is that this project only means "native GUI" in the sense that it's a GUI that runs without an intermediate rendering engine (ie web browser). I was just trying to defend an interesting project against the hoards of negative semantic-Nazi's. I get rather sick of the poisonous attitude some have towards other peoples hard work so felt it was only fair to offer a counter argument defending it. But I did so forgetting just how vehemently opinionated many are and now really wish I hadn't bothered because this argument has spiralled well beyond the original point.
Sure, in an ideal world this project would be using vendor APIs rather than OpenGL - but this does actually work and is pretty damn cool, even if it is a bit of hack. And if we're honest, isn't hacking meant to be the point of this forums? Or is this community now just a place for intelligent people to belittle other intelligent people?
Honestly, sometimes I just sigh at the number of pot-shots people make on here and how it's now become the acceptable norm. I'm sure it wasn't like this when I first joined.
I'm sorry you felt that the responses were hostile, that certainly wasn't my intent. Mood is awfully tough to get right on a bulletin board.
Speaking only for myself, I feel that words are very powerful, and that it's important for us to be precise in usage. I certainly didn't mean to denigrate this project, or the talented folks behind it.
To be honest, I think a lot of my frustration is that I don't actually disagree with most of the points being raised, but I'd back myself into the position of playing devils advocate. I mean, I do think they way this submission was described as "native app GUI" is acceptable because it's also pretty clear that it's in the context of using OpenGL in place of HTML and thus it's just a concise / terse / lazy / whatever way of saying "renders natively on device" (summarising git repositories and titling them can be a deceptively hard job after all). But I can also understand why people would nitpick the semantics of that title; and had the context not been clearer (ie the project was a little more opaque about it's usage of OpenGL) then I likely wouldn't have defended it's usage.
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.
What can be done and what's actually done are two very different things. Fully replicating something as simple as a button can be very hard. Its look depends on the OS, OS version, OS theme, OS scaling setting, OS font settings, the language (left-to-right, right-to-left). It has to support all kinds of OS accessibility hooks. It has to support all kinds of input devices. It has to follow the tab-focus rules. These are just the things I'm aware without looking them up, I'm sure there's a lot more.
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.
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.
>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.
44 comments
[ 3.0 ms ] story [ 114 ms ] threadAre there any nice tools out there for creating apps that render to both native + web?
But i think you still need all the libs and stuff.
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!
http://papyros.io/2014/11/20/introduction-and-initial-plans....
http://papyros.io/monthly-update/2015/02/05/monthly-status-u...
The combo C++ QML QtQuick made my life so much easier for a cross-platform OSX/Win app.
I was able to develop most of it on Linux, and it even looks nifty!
What else can you wish ? :)
I guess it's a fair trade-off when you target today's desktop systems. Otherwise, it might worth looking at Qt for Embedded Linux.
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.
SOOOO much nicer than HTML/JS/CSS trainwreck that is modern web development.
http://doc.qt.io/qt-5/qtquickcontrols-gallery-example.html
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.
Usually it means people are running the widgets that are coming from the vendor's toolkits. Windows: Win32/WPF, OS X: Cocoa, iOS: CocoaTouch, Android: etc. and so on.
That distinction is somewhat important because it also means the easiest way to get stuff like that running is typically with the language those libraries are written in: C++, Objective-C (or now Swift), Java, etc. It's like the holy grail of write once, run everywhere. Write it in one language and somehow have it run on the native (vendor) toolkit on every platform out there.
Best not tell that to the Qt devs ;)
Anyway, this argument is ridiculous because all my point was, is that this project only means "native GUI" in the sense that it's a GUI that runs without an intermediate rendering engine (ie web browser). I was just trying to defend an interesting project against the hoards of negative semantic-Nazi's. I get rather sick of the poisonous attitude some have towards other peoples hard work so felt it was only fair to offer a counter argument defending it. But I did so forgetting just how vehemently opinionated many are and now really wish I hadn't bothered because this argument has spiralled well beyond the original point.
Sure, in an ideal world this project would be using vendor APIs rather than OpenGL - but this does actually work and is pretty damn cool, even if it is a bit of hack. And if we're honest, isn't hacking meant to be the point of this forums? Or is this community now just a place for intelligent people to belittle other intelligent people?
Honestly, sometimes I just sigh at the number of pot-shots people make on here and how it's now become the acceptable norm. I'm sure it wasn't like this when I first joined.
Speaking only for myself, I feel that words are very powerful, and that it's important for us to be precise in usage. I certainly didn't mean to denigrate this project, or the talented folks behind it.
- 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.
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.
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.
This instead seems to be taking the Kivy OpenGL controls approach. It looks very nifty and as though it took effort by some smart folks.
I was only hoping for truly native controls so as to provide access to screen readers and other a11y solutions by default.
Second, the GUI looks atrocious. What is wrong with designers nowadays that they think we live in a cartoonish world?