Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go + gxui: Rendering native app GUIs on any platform?

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Go + gxui: Rendering native app GUIs on any platform?

#21

Post by cm3 »

fla wrote: post #14
jalfresi wrote: post #7

I've not tried this but I thought I'd mention that I've been using the QT QML packages for building desktops apps and the results are amazing! 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 sta…

Qt is an amazing framework which got many things right! 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 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.

Re: Go + gxui: Rendering native app GUIs on any platform?

#22

Post by jalfresi »

WaltPurvis wrote: post #20
overlord_tm wrote: post #17

Earlier quoted context omitted.

Anyone else has experience with this combo (golang + qt qml). Is it worth giving a shot for production quality cross platform app (win,osx,linux)?

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…

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.

Re: Go + gxui: Rendering native app GUIs on any platform?

#23

Post by laumars »

imaginenore wrote: post #15
laumars wrote: post #13

Earlier quoted context omitted.

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.

If the widgets had to be reimplemented, they are not native by definition.

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.

Re: Go + gxui: Rendering native app GUIs on any platform?

#24

Post by laumars »

roel_v wrote: post #16
laumars wrote: post #13

Earlier quoted context omitted.

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…

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.

Re: Go + gxui: Rendering native app GUIs on any platform?

#25

Post by fla »

cm3 wrote: post #21
fla wrote: post #14

Earlier quoted context omitted.

Qt is an amazing framework which got many things right! 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 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.

Yes that's one of the downside. Also, the binaries can get fat really quick. Especially when you link statically with some of the Qt components.

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.

Re: Go + gxui: Rendering native app GUIs on any platform?

#26

Post by roel_v »

laumars wrote: post #24
roel_v wrote: post #16

Earlier quoted context omitted.

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…

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…

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

Re: Go + gxui: Rendering native app GUIs on any platform?

#27

Post by jfb »

laumars wrote: post #23
imaginenore wrote: post #15

Earlier quoted context omitted.

If the widgets had to be reimplemented, they are not native by definition.

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 s…

I'm sorry, but that reading is in clear contravention of the well understood meaning of "native" in the context of a UI.

Re: Go + gxui: Rendering native app GUIs on any platform?

#28

Post by coldtea »

laumars wrote: post #24
roel_v wrote: post #16

Earlier quoted context omitted.

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…

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…

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

Re: Go + gxui: Rendering native app GUIs on any platform?

#29

Post by imaginenore »

laumars wrote: post #23
imaginenore wrote: post #15

Earlier quoted context omitted.

If the widgets had to be reimplemented, they are not native by definition.

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 s…

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.

Re: Go + gxui: Rendering native app GUIs on any platform?

#30

Post by [deleted] »

jfb wrote: post #27
laumars wrote: post #23

Earlier quoted context omitted.

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 s…

I'm sorry, but that reading is in clear contravention of the well understood meaning of "native" in the context of a UI.

[deleted]
Post reply on HN