4 ms·

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

> 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.
- webmobdev 5y ago
  True, that's an issue - maintaining the wrapper library and keeping featuring parity with native UI features is a cumbersome task and many do fall behind in that. I think most wrapper libraries are still on GTK2, and perhaps working on GTK3. That said, wrapper libraries do help you make it much easier to develop for multiple platforms with one core code base. The final work of tweaking and customising for each OS, before distribution, is true even if you build the product with the native OS frameworks. (Some compromises will ofcourse have to be accepted.)

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.

webmobdev 5y ago
True, that's an issue - maintaining the wrapper library and keeping featuring parity with native UI features is a cumbersome task and many do fall behind in that. I think most wrapper libraries are still on GTK2, and perhaps working on GTK3. That said, wrapper libraries do help you make it much easier to develop for multiple platforms with one core code base. The final work of tweaking and customising for each OS, before distribution, is true even if you build the product with the native OS frameworks. (Some compromises will ofcourse have to be accepted.)