4 ms·

While I appreciate the time invested in researching all this, I feel this is "reinventing the wheel". Native GUIs almost always offer superior performance and a

While I appreciate the time invested in researching all this, I feel this is "reinventing the wheel". Native GUIs almost always offer superior performance and already offer everything that the developer(s) of a new framework would have to reinvent. Thus, a wrapper around native GUIs makes the most sense. (GUI frameworks on Linux though does need an improvement or a complete revamp. )

novok 5y ago
In practice wrapper types have been done many times before, and failed to make something good. Rendering everything yourself is actually as performant or potentially more performant than a 'native' set because what everyone is doing in the end, including native frameworks, is rendering on a rectangle using opengl, vulkan or metal.
- webmobdev 5y ago
  VCL on Delphi and LCL on Lazarus ( https://www.lazarus-ide.org https://www.lazarus-ide.org ) are pretty neat and feature rich wrappers. It's not the rendering that's the issue - it's the work involved in making them conformant to the different OS guidelines, and dealing with the intricacies and quirks of each OS. It's more practical to extend and enhance what is lacking, rather than rebuild the whole thing again in 4 (Windows, macOS, Linux, FreeBSD) different ways.
  - dgb23 5y ago
    I think the author agrees with you. From the same blog: https://tonsky.me/blog/skija/ https://tonsky.me/blog/skija/
linguae 5y ago
One question regarding wrappers around native GUIs as someone with little experience writing GUI software: how does the wrapper handle different UI/UX guidelines? It’s one thing to wrap a common button class around Win32, AppKit, Qt, and GTK buttons. It’s another thing to have the application simultaneously comply with the UI/UX guidelines for each desktop environment.
- deleted 5y ago
  [deleted]
- webmobdev 5y ago
  > how does the wrapper handle different UI/UX guidelines? Most of it is automatically handled by the native interface of the OS when it renders the UI. Some cases have to be dealt by the wrapper library developer, and some of it has to be done by the developer creating the app using the wrapper library. For example, a Window usually has the default UI elements of a Title Bar, the title text, Max-minimize buttons, window resize handlers etc. In Windows, this is rendered with the max-minimise buttons on the top-right corner, and the title left aligned in the title bar (if I remember right). On macOS, the same Window will be rendered with the max-minimise button on the top-left corner and the title centered in the title bar. When you create a window on MS Windows OS using the Win32 API for it - http://www.winprog.org/tutorial/simple_window.html http://www.winprog.org/tutorial/simple_window.html - the rendered window will be, by default, according to Microsoft UI / UX guidelines. Similarly, when you create a window using the cocoa framework on macOS, the window will be rendered, by default, according to the UI / UX guidelines of Apple - https://github.com/lukakerr/NSWindowStyles https://github.com/lukakerr/NSWindowStyles . This highlights how some UI / UX guidelines are baked into the native frameworks. But if the wrapper library developer wants to offer some multi-platform custom UI component not available natively, they will have to ensure that the component is compliant with UI / UX guidelines of the OS they are rendered in. (If you want to see this in action with an actual wrapper library, check out Lazarus IDE - https://www.lazarus-ide.org/index.php https://www.lazarus-ide.org/index.php ... create a window on it on MS Windows, Linux or macOS with its GUI designer and compile the code to the see the native window it generates, on each OS.) Most of the other things described in the article are also already available in the native GUI frameworks. It would make more sense to extend and enhance what is lacking, rather than re-inventing the whole thing again (which, as you noticed, can be a pain if you have to conform to different OS guidelines).
  - jms55 5y ago
    I can't speak for other platforms, but for GTK it's pretty obvious what is actually a GTK app, and what uses GTK as a wrapper. Sure, it might have the GTK titlebar and context menus. But all good GTK apps don't use a titlebar for the app title, they put widgets inside of it. They use libadwaita and get adaptive layouts for smaller app sizes. Reusing native stuff is fine - it provides rendering, text, accessibility, window management, and other hard stuff for you. But it's not equivalent to a native app, because you'll never conform to each platform's UI guidelines without significant work per app.
deleted 5y ago
[deleted]

novok 5y ago

In practice wrapper types have been done many times before, and failed to make something good. Rendering everything yourself is actually as performant or potentially more performant than a 'native' set because what everyone is doing in the end, including native frameworks, is rendering on a rectangle using opengl, vulkan or metal.

webmobdev 5y ago
VCL on Delphi and LCL on Lazarus ( https://www.lazarus-ide.org https://www.lazarus-ide.org ) are pretty neat and feature rich wrappers. It's not the rendering that's the issue - it's the work involved in making them conformant to the different OS guidelines, and dealing with the intricacies and quirks of each OS. It's more practical to extend and enhance what is lacking, rather than rebuild the whole thing again in 4 (Windows, macOS, Linux, FreeBSD) different ways.
- dgb23 5y ago
  I think the author agrees with you. From the same blog: https://tonsky.me/blog/skija/ https://tonsky.me/blog/skija/

linguae 5y ago

One question regarding wrappers around native GUIs as someone with little experience writing GUI software: how does the wrapper handle different UI/UX guidelines? It’s one thing to wrap a common button class around Win32, AppKit, Qt, and GTK buttons. It’s another thing to have the application simultaneously comply with the UI/UX guidelines for each desktop environment.

deleted 5y ago
[deleted]
webmobdev 5y ago
> how does the wrapper handle different UI/UX guidelines? Most of it is automatically handled by the native interface of the OS when it renders the UI. Some cases have to be dealt by the wrapper library developer, and some of it has to be done by the developer creating the app using the wrapper library. For example, a Window usually has the default UI elements of a Title Bar, the title text, Max-minimize buttons, window resize handlers etc. In Windows, this is rendered with the max-minimise buttons on the top-right corner, and the title left aligned in the title bar (if I remember right). On macOS, the same Window will be rendered with the max-minimise button on the top-left corner and the title centered in the title bar. When you create a window on MS Windows OS using the Win32 API for it - http://www.winprog.org/tutorial/simple_window.html http://www.winprog.org/tutorial/simple_window.html - the rendered window will be, by default, according to Microsoft UI / UX guidelines. Similarly, when you create a window using the cocoa framework on macOS, the window will be rendered, by default, according to the UI / UX guidelines of Apple - https://github.com/lukakerr/NSWindowStyles https://github.com/lukakerr/NSWindowStyles . This highlights how some UI / UX guidelines are baked into the native frameworks. But if the wrapper library developer wants to offer some multi-platform custom UI component not available natively, they will have to ensure that the component is compliant with UI / UX guidelines of the OS they are rendered in. (If you want to see this in action with an actual wrapper library, check out Lazarus IDE - https://www.lazarus-ide.org/index.php https://www.lazarus-ide.org/index.php ... create a window on it on MS Windows, Linux or macOS with its GUI designer and compile the code to the see the native window it generates, on each OS.) Most of the other things described in the article are also already available in the native GUI frameworks. It would make more sense to extend and enhance what is lacking, rather than re-inventing the whole thing again (which, as you noticed, can be a pain if you have to conform to different OS guidelines).
- jms55 5y ago
  I can't speak for other platforms, but for GTK it's pretty obvious what is actually a GTK app, and what uses GTK as a wrapper. Sure, it might have the GTK titlebar and context menus. But all good GTK apps don't use a titlebar for the app title, they put widgets inside of it. They use libadwaita and get adaptive layouts for smaller app sizes. Reusing native stuff is fine - it provides rendering, text, accessibility, window management, and other hard stuff for you. But it's not equivalent to a native app, because you'll never conform to each platform's UI guidelines without significant work per app.

deleted 5y ago

[deleted]