5 ms·

How is this a 'native app GUI'? It's only OpenGL as far as I can tell?

by roel_v 11y ago

laumars 11y ago
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.
- imaginenore 11y ago
  If the widgets had to be reimplemented, they are not native by definition.
  - laumars 11y ago
    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.
    - jfb 11y ago
      I'm sorry, but that reading is in clear contravention of the well understood meaning of "native" in the context of a UI.
      - deleted 11y ago
        [deleted]
        Glide 11y ago
        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.
        laumars 11y ago
        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...
        jfb 11y ago
        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.
        deleted 11y ago
        [deleted]
    - imaginenore 11y ago
      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.
      - deleted 11y ago
        [deleted]
        imaginenore 11y ago
        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.
        deleted 11y ago
        [deleted]
        laumars 11y ago
        Which is exactly the point I made as well (several times in fact). So thank you for finally agreeing with me on something.
- roel_v 11y ago
  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 11y ago
    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.
    - roel_v 11y ago
      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'.

How is this a 'native app GUI'? It's only OpenGL as far as I can tell?

by roel_v 11y ago

How is this a 'native app GUI'? It's only OpenGL as far as I can tell?

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.

imaginenore 11y ago
If the widgets had to be reimplemented, they are not native by definition.
- laumars 11y ago
  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.
  - jfb 11y ago
    I'm sorry, but that reading is in clear contravention of the well understood meaning of "native" in the context of a UI.
    - deleted 11y ago
      [deleted]
      - Glide 11y ago
        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.
        laumars 11y ago
        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...
      - jfb 11y ago
        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.
        deleted 11y ago
        [deleted]
  - imaginenore 11y ago
    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.
    - deleted 11y ago
      [deleted]
      - imaginenore 11y ago
        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.
        deleted 11y ago
        [deleted]
        laumars 11y ago
        Which is exactly the point I made as well (several times in fact). So thank you for finally agreeing with me on something.
roel_v 11y ago
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 11y ago
  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.
  - roel_v 11y ago
    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'.