3 ms·

> It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise betwee

> It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code. I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed. There are not multiple "native toolkits" on Windows or macOS. > Different platforms are just slightly too different from each other to make it work well. So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.

catiopatio 4y ago
> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position. Can you name a single cross-platform application that is indistinguishable from a native application?
- PaulDavisThe1st 4y ago
  I don't even know that this question means. Is Photoshop a cross-platform application? Protools? Chrome?
  - scarface74 4y ago
    Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”. And do you really want to bring up the battery killing Chrome as a great cross platform app? Safari is much more efficient and ironically from reports, so is Microsoft’s Chromium based browser.
    - PaulDavisThe1st 4y ago
      I wasn't trying to name "great" cross-platform apps. The question was "what is a cross platform app". Is Chrome or Firefox a cross-platform app or not, regardless of how they shitty they may or may not be? > Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”. Every GUI application that runs on macOS has a "shit ton of Cocoa" inside it. There's essentially no other way to create a GUI app for macOS, regardless of the toolkit you use. There's a separate question like "are the buttons drawn by Cocoa, or app-specific, or toolkit specific?" but I regard that as a separate question.
      - scarface74 4y ago
        The discussion is about cross platform “frameworks” versus writing apps using the native frameworks. Adobe and Microsoft basically use native frameworks for most of their apps. It’s the difference between most of Office and Teams and VSCode.
        mroche 4y ago
        On the flip side, nearly all groups in the VFX industry author their apps with Qt and deliver across Linux, macOS, and Windows. The "native" side of things is where people usually end up having the most debate, typically around appearance. VFX and creative apps tend to choose to look and behave consistently across platforms within their own context, rather than trying to utilize the human interface guidelines (HIG) of each respective platform. The standard place where this differs is usually on the file picker component. That being said, even with these toolkits you can make applications that are themed and behave similar enough to the native runtimes that most users wouldn't notice. But that's a developer's choice to do so, or to completely customize the app for themselves and the UX they're looking to deliver. To me the concept of cross-platform desktop applications is pretty interesting, as when you include the Linux ecosystem into the fray it's not macOS, Windows, and Linux (Qt/GTK), but rather macOS, Windows, GNOME (libadwaita), KDE (KDE Frameworks), etc etc. And that is significantly more difficult to support "native" for, even if the latter are using GTK and Qt under the hood of their respective platforms. Apple can make first party applications that abide exclusively by their HIG, and the same with Microsoft, but asking vendors targetting multiple platforms to do so and essentially support multiple versions of their apps to achieve "true native" when "seemingly" or "close-to" native via the toolkits widgets, built in theming capabilities, and backend abstractions are available can be a bit of a tall ask.
klodolph 4y ago
> I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed. You're kind of fighting against Qt or GTK when you do that. Qt and GTK have their own widgets. React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations, and has better interoperability with platform features. > There are not multiple "native toolkits" on Windows or macOS. I'm confused by this comment. I don't know what kind of point you are trying to make here, or what you are responding to. > So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position. Yeah, let's dial the "it's a position" condescension back one or two notches. When I said, "Different platforms are just slightly too different from each other to make it work well," the "it" refers to cross-platform toolkits like GTK and Qt, which provide their own widgets. This explains why so many people use Electron and just embed a web browser (let's say "fuck it" and make one UI inside a big window), or choose to use something like React Native. Maybe I'm drawing too fine a line here--I think of Qt and GTK as cross-platform toolkits, I think of React Native as a framework without the toolkit parts, and I think of Electron as some kind of cross-platform box that you can something inside. I'd rather not talk about the definition of "toolkit" or "framework" because the definitions are not material. Qt is a big honking mess, and GTK is worse. Speaking as someone who has written apps using both, and fixed UI problems in people's open-source Qt and GTK projects.
- PaulDavisThe1st 4y ago
  > This explains why so many people use Electron and just embed a web browser I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here. > React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect. Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows. Almost all DAWs, drawing programs and image editors just treat their windows as a big 2D drawing surface, and do their thing without regard for UI/UX widgets or rules designed around productivity/business/system utility apps. The "native" aspect kicks in only when they interact with the rest of the desktop environment, and they vary quite a bit in how native they go (they also keep changing this; Logic has gone back and forth with using the native file browser vs. an app-specific one several times over its life, and in different contexts within the app). This also has implications for the extent to which Qt/GTK/etc. toolkits impact the UX. If someone writes a widget-heavy app, then the toolkit design & implementation will have a strong impact. If the widgets are limited to some toolbar at the top, it doesn't really make a lot of difference as long as the devs get system tray/notification right, and don't screw with window management.
Macha 4y ago
> There are not multiple "native toolkits" on Windows or macOS. This is just not true on Windows. What is native Windows these days? Win32? WPF? WinUI? Even if your view is that Win32 is the one true native toolkit, MS alone produces multiple abstractions over Win32 like Windows Forms or MFC.
- PaulDavisThe1st 4y ago
  My definition works like this: is there an API layer on which (a) everything else is based and (b) people sometimes use directly for app development? macOS: Cocoa/Quartz - yes and yes windows: win32 - yes and yes linux: X Window - yes, no (though of course Wayland is changing the "yes" a bit) GTK, Qt, WxWidgets, FLTK etc - no, yes
  - Macha 4y ago
    But that's my point, WPF (the Vista-7 era primary toolkit), is not based on Win32. Neither is WinUI (the 8-11 era primary toolkit) calling Win32 or WPF. Win32 is mostly used for legacy apps, you'll find some random usages still like pre-Win11 notepad or the services configuration menu. WPF is the primary UI framework of Windows Vista/7 and still the framework which the majority of the OS is in for Windows 8/8.1. It doesn't call Win32, it implements its own widgets, something that would most often be exposed in differences in high-dpi support. These do generally try to align with the Win32 widgets from that Windows version visually, but there's plenty of discrepencies. WinUI is the new framework which isn't even shipped with the OS as of the latest versions, but even if you're using the built in verison it's not calling Win32 widgets or WPF widgets, it's once again implemented a new set. The lower level APIs share some similarities with WPF as it basically started as a fork of WPF modified to implement Windows 8 UI patterns, but neither WinUI or WPF are implemented in terms of the other.
    - PaulDavisThe1st 4y ago
      Thank you for a brief update on the situation on Windows. I didn't know all that, and now I know a bit of it.

catiopatio 4y ago

> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position. Can you name a single cross-platform application that is indistinguishable from a native application?

PaulDavisThe1st 4y ago
I don't even know that this question means. Is Photoshop a cross-platform application? Protools? Chrome?
- scarface74 4y ago
  Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”. And do you really want to bring up the battery killing Chrome as a great cross platform app? Safari is much more efficient and ironically from reports, so is Microsoft’s Chromium based browser.
  - PaulDavisThe1st 4y ago
    I wasn't trying to name "great" cross-platform apps. The question was "what is a cross platform app". Is Chrome or Firefox a cross-platform app or not, regardless of how they shitty they may or may not be? > Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”. Every GUI application that runs on macOS has a "shit ton of Cocoa" inside it. There's essentially no other way to create a GUI app for macOS, regardless of the toolkit you use. There's a separate question like "are the buttons drawn by Cocoa, or app-specific, or toolkit specific?" but I regard that as a separate question.
    - scarface74 4y ago
      The discussion is about cross platform “frameworks” versus writing apps using the native frameworks. Adobe and Microsoft basically use native frameworks for most of their apps. It’s the difference between most of Office and Teams and VSCode.
      - mroche 4y ago
        On the flip side, nearly all groups in the VFX industry author their apps with Qt and deliver across Linux, macOS, and Windows. The "native" side of things is where people usually end up having the most debate, typically around appearance. VFX and creative apps tend to choose to look and behave consistently across platforms within their own context, rather than trying to utilize the human interface guidelines (HIG) of each respective platform. The standard place where this differs is usually on the file picker component. That being said, even with these toolkits you can make applications that are themed and behave similar enough to the native runtimes that most users wouldn't notice. But that's a developer's choice to do so, or to completely customize the app for themselves and the UX they're looking to deliver. To me the concept of cross-platform desktop applications is pretty interesting, as when you include the Linux ecosystem into the fray it's not macOS, Windows, and Linux (Qt/GTK), but rather macOS, Windows, GNOME (libadwaita), KDE (KDE Frameworks), etc etc. And that is significantly more difficult to support "native" for, even if the latter are using GTK and Qt under the hood of their respective platforms. Apple can make first party applications that abide exclusively by their HIG, and the same with Microsoft, but asking vendors targetting multiple platforms to do so and essentially support multiple versions of their apps to achieve "true native" when "seemingly" or "close-to" native via the toolkits widgets, built in theming capabilities, and backend abstractions are available can be a bit of a tall ask.

klodolph 4y ago

> I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed. You're kind of fighting against Qt or GTK when you do that. Qt and GTK have their own widgets. React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations, and has better interoperability with platform features. > There are not multiple "native toolkits" on Windows or macOS. I'm confused by this comment. I don't know what kind of point you are trying to make here, or what you are responding to. > So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position. Yeah, let's dial the "it's a position" condescension back one or two notches. When I said, "Different platforms are just slightly too different from each other to make it work well," the "it" refers to cross-platform toolkits like GTK and Qt, which provide their own widgets. This explains why so many people use Electron and just embed a web browser (let's say "fuck it" and make one UI inside a big window), or choose to use something like React Native. Maybe I'm drawing too fine a line here--I think of Qt and GTK as cross-platform toolkits, I think of React Native as a framework without the toolkit parts, and I think of Electron as some kind of cross-platform box that you can something inside. I'd rather not talk about the definition of "toolkit" or "framework" because the definitions are not material. Qt is a big honking mess, and GTK is worse. Speaking as someone who has written apps using both, and fixed UI problems in people's open-source Qt and GTK projects.

PaulDavisThe1st 4y ago
> This explains why so many people use Electron and just embed a web browser I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here. > React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect. Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows. Almost all DAWs, drawing programs and image editors just treat their windows as a big 2D drawing surface, and do their thing without regard for UI/UX widgets or rules designed around productivity/business/system utility apps. The "native" aspect kicks in only when they interact with the rest of the desktop environment, and they vary quite a bit in how native they go (they also keep changing this; Logic has gone back and forth with using the native file browser vs. an app-specific one several times over its life, and in different contexts within the app). This also has implications for the extent to which Qt/GTK/etc. toolkits impact the UX. If someone writes a widget-heavy app, then the toolkit design & implementation will have a strong impact. If the widgets are limited to some toolbar at the top, it doesn't really make a lot of difference as long as the devs get system tray/notification right, and don't screw with window management.

Macha 4y ago

> There are not multiple "native toolkits" on Windows or macOS. This is just not true on Windows. What is native Windows these days? Win32? WPF? WinUI? Even if your view is that Win32 is the one true native toolkit, MS alone produces multiple abstractions over Win32 like Windows Forms or MFC.

PaulDavisThe1st 4y ago
My definition works like this: is there an API layer on which (a) everything else is based and (b) people sometimes use directly for app development? macOS: Cocoa/Quartz - yes and yes windows: win32 - yes and yes linux: X Window - yes, no (though of course Wayland is changing the "yes" a bit) GTK, Qt, WxWidgets, FLTK etc - no, yes
- Macha 4y ago
  But that's my point, WPF (the Vista-7 era primary toolkit), is not based on Win32. Neither is WinUI (the 8-11 era primary toolkit) calling Win32 or WPF. Win32 is mostly used for legacy apps, you'll find some random usages still like pre-Win11 notepad or the services configuration menu. WPF is the primary UI framework of Windows Vista/7 and still the framework which the majority of the OS is in for Windows 8/8.1. It doesn't call Win32, it implements its own widgets, something that would most often be exposed in differences in high-dpi support. These do generally try to align with the Win32 widgets from that Windows version visually, but there's plenty of discrepencies. WinUI is the new framework which isn't even shipped with the OS as of the latest versions, but even if you're using the built in verison it's not calling Win32 widgets or WPF widgets, it's once again implemented a new set. The lower level APIs share some similarities with WPF as it basically started as a fork of WPF modified to implement Windows 8 UI patterns, but neither WinUI or WPF are implemented in terms of the other.
  - PaulDavisThe1st 4y ago
    Thank you for a brief update on the situation on Windows. I didn't know all that, and now I know a bit of it.