News for hackers. Stuff that matters.
Re:Cross-Platform GUI Toolkit Trainwreck (2016) by Wowfunhappy on Thursday April 25, 2019 @02:50PM (#19751317)
> 2.1) I want to ship something that looks the same on Windows / Linux / MacOS

Why?

I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements. (There is no one native Linux UI, so we can leave that one aside...)

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by jcelerier on Thursday April 25, 2019 @04:03PM (#19751983)
I want the complete opposite. I use the three systems almost daily, and I freaking hate to have to context-switch to the platform's look-and-feel. Thankfully KDE apps work mostly everywhere nowadays.

Most of the users of the FOSS software I'm developing also switch platforms depending on the project they're in, but they want the software to be the same everywhere for instance.

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by Wowfunhappy on Thursday April 25, 2019 @07:10PM (#19753384)
Are differently-styled UI elements really a mental burden? I'm not advocating for wholly different UI's on each platform—just that if your application uses checkboxes, and I'm on a Mac, I should see Mac checkboxes.
Re:Cross-Platform GUI Toolkit Trainwreck (2016) by Retra on Friday April 26, 2019 @11:42AM (#19758671)
It's probably more the behavior things. Keyboard shortcuts, focus behaviors, menu placement, file dialogs, etc. Settings panels in MacOs should take effect immediately, while in windows you have to click ok/apply... inconsistencies like this can lead to frustration.
Re:Cross-Platform GUI Toolkit Trainwreck (2016) by Wowfunhappy on Friday April 26, 2019 @02:40PM (#19760608)
But not doing this brings about an even worse kind of context switching—between apps on the same platform.

As annoying as it is to switch form cmd+C to ctrl+C when I go from Mac to Windows, it's even worse when a Mac app uses ctrl+C.

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by jcelerier on Friday April 26, 2019 @01:18PM (#19759746)
this, and also the need to write three (or four if you want to do separate stuff for KDE & GNOME) times the amount of documentation to accomodate for the different "default" behaviours.
Re:Cross-Platform GUI Toolkit Trainwreck (2016) by Macha on Thursday April 25, 2019 @03:12PM (#19751509)
Because someone gave the brand team authority and they can't have their brand take second place to Microsoft's or Apple's.

Branding teams are in my experience very picky about lots of stuff. For example, my employer's brand design team recently released a rule that when our logo is included alongside others logos in a list of companies involved in a partnership, it may not be included in a vertical list, only a horizontal list.

Using the standard background colour for the platform on your app when it's not one of the brand design team approved colours? Also out.

etc. etc.

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by phtrivier on Thursday April 25, 2019 @03:14PM (#19751520)
I maybe biased after doing web work for toi long, but "hey, the site does not look the same in safari than on edge" has occupied a lot of my time.

It's a common concern to avoid confusing users who switch OS often (eg when demoing on someone else's machine.)

The fact that it contradicts the other requirement ("but it does not look like the other apps") is lost on no one.

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by bryanphe on Thursday April 25, 2019 @03:45PM (#19751799)
This is less fashionable now in the era of Electron apps - users are starting to expect apps that look _the same_ everywhere.

See VSCode, Discord, Spotify...

It's easier to get a single code-base that 'just works' across platforms if you have an abstraction that is truly cross-platform. One of the major value propositions of developing with Electron is this ability to develop cross-platform 'with confidence' - I can build an app on Windows and be 99% sure it's going to look function the same on OSX / Linux.

> I want my macOS apps to use Mac-native UI elements, and Windows apps to use Windows-native UI elements

That's a fine goal but it means you end up needing more platform-specific code. It's a trade-off, and there isn't a one-size-fits-all solution.

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by zapzupnz on Thursday April 25, 2019 @06:50PM (#19753252)
But do people expect the apps to look the same? I think people want them to behave the same with a few visual features kept intact.

To take Discord as an example, I don't know that people actually can't live without the UI slavishly copied for every platform; I think people rather want light and dark themes on all platforms, message formatting to look basically the same, and for everything to be found in roughly the same place.

This idea that users expect apps to look the same is, I feel sure, something someone said and everybody has gone along with. In my experience, people want things to behave consistently — so if Discord had a native Windows client and a native macOS client, people would be more interested in whether or not they could still find the little microphone and headphone buttons at the lower-left of the screen, sod if the icons and colours are identical.

Re:Cross-Platform GUI Toolkit Trainwreck (2016) by dekhn on Thursday April 25, 2019 @06:05PM (#19752929)
I don't really have an attachment to any of the three platforms; I use all three. Moving between different windowing environments and UI designs is a huge context switch and provides no value to me (it's just eye candy).
Re:Cross-Platform GUI Toolkit Trainwreck (2016) by favorited on Thursday April 25, 2019 @03:23PM (#19751608)
The only valid case for this (IMO) is really expensive professional apps. Where someone is going to spend years getting really, really good at using a piece of software, and you want them to be able to just use it the same way regardless of platform. And you especially don't want people to have to re-learn how to use your really complicated software if the host OS changes how scroll bars appear or the position of window chrome.

But I suspect lots of software companies would think that describes them, when in reality there's probably fewer than 10 products that meet that bar.