5 ms·
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 w
by mroche 3y 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.
- scarface74 3y agoSo if it’s “themed” to look “native”, what happens when the vendor chooses to change the theme of the native widgets? Do the themed widgets automatically support the user’s localization and internationalization preferences? Does it support the accessibility affordances that you could get for free when you use the native toolkit? > 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. And could that be part of the reason that Microsoft and Adobe - both with a multi decade history of writing cross platform apps that use the native frameworks of the target platform are really the only two software companies that are really still successful making desktop consumer/prosumer software?
- PaulDavisThe1st 3y agoI can only speak to the land of DAWs: The biggest DAW of the last 20 years: Ableton Live (Windows/macOS) The next biggest DAW of the last 20 years: Reaper (Windows/macOS/Linux) The most rapidly expanding DAW right now: Bitwig (Windows/macOS/Linux) The most deliriously loved DAW: FL Studio (Windows/macOS) Most widely used DAW by paid professionals: Digidesign ProTools (Windows/macOS) Other DAWs not made by Adobe or Microsoft (neither of whom make an actual DAW): every single other DAW, most of which run on Windows & macOS, except Logic, which was cross-platform until Apple bought it. But I could make a guess at other worlds too: Biggest splash in the video editing world: DaVinci Resolve (Windows/macOS/Linux) Most widely used 3D/animation: Blender (Windows/macOS/Linux) Not really sure what you're talking about claiming that Adobe & Microsoft are the only two software companies that are really still successfully making desktop consumer/prosumer software, unless you are deliberarely excluding actual "pro" software. In which case ... I just don't really care.
- scarface74 3y agoI’m considering massively successful as two companies that have literally been selling versions of the same software for Mac and PC software for over 35 years. Another poster cited this as far as how much “native” code is in PhotoShop > But Russell still has MacApp to contend with — it most recently flared up during the Mac Cocoa conversion. Millions of lines of code had to be changed, and for a time the entire team was engaged on the project. And let’s talk about ProTools. It is even in a worse position than Adobe with respect to being able to use cross platform frameworks. The backend leverages Mac and Windows specific APIs https://www.pro-tools-expert.com/production-expert-1/is-there-any-difference-between-mac-and-pc-for-pro-audio-in-2022 https://www.pro-tools-expert.com/production-expert-1/is-ther... It specifically leverages Core Audio on the Mac.
- PaulDavisThe1st 3y ago> same software for Mac and PC software for over 35 years You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so. CoreAudio is not a "front-end" toolkit/framework/library. You cannot do audio or MIDI I/O on any platform without ultimately talking to the platform APIs for that (not totally dissimilar to how all GUI toolkits ultimately having to talk to some low level drawing/event API). The backend of every DAW, audio editor, audio player etc. uses platform-specific APIs, either directly via their own platform-specific code, or via a wrapper such as JUCE, or RtAudio (JUCE is extremely popular these days, though it is also a large cross-platform GUI toolkit that is increasingly dominated startup audio software development). None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.