| ▲ | dagmx 5 hours ago | |
You’re shifting goalposts in ways that not even AppKit follows. It was originally whether it can feel native and it can. - Yes Qt doesn’t get the default context menu items but it’s trivial to add them. Meanwhile you can also override them in AppKit to look non standard. - The original response was about whether Qt can provide modern looking and native looking apps. You’ve now shifted your goalpost from modern looking to being exactly what AppKit or SwiftUI does. - Qt by default has basic accessibility support on macOS the same way AppKit does. It’s not always perfect but it’s not as dire as you make it out to be. - Qt6 also supports theme changes fine. But again, none of this is the premise of the original argument I was replying to. Your argument is all over the place because you then also claim that AppKit can make non native looking UIs but we should just ignore those while disregarding that you can also trivially make Qt look macOS like. The point isn’t that Qt apps will look and behave 100% identical, the point is you can make them do so. But cross platform apps will always be somewhat alien on any platform unless you’re actually designing for each platform. That’s not really inherent to the UI framework that prevents it. | ||
| ▲ | zapzupnz 3 hours ago | parent [-] | |
> You're shifting goalposts Where? > It was originally whether it can feel native Yes, and feeling native includes behaviours, not just looks. > and it can. Except it doesn't. Still waiting on a single example of a proper Mac-feeling app written with Qt, looks and behaviour included. > It's trivial to add them If you're comparing to using a native toolkit, 'trivial' should mean 'for free' given that Qt already presents the developer with the option to use the native toolkit. There's nothing trivial about integrating a proper Cocoa-provided NSToolbar into a Qt app. It's downright impossible to make a QToolBar both look and behave like NSToolbar. > The original response was about whether Qt can provide modern looking and native looking apps Yes, and then I mentioned that looking like a native app isn't the end of the story. The conversation moved on but, contrary to the assertion that the goalposts shifted (it didn't, the goalpost was always about the better UX of native toolkits), all I did was add detail as to what desktop UI toolkits provide that Qt doesn't. Even then, AppKit is as old as Mac OS X. Hardly native. And in all that time, Qt never caught up. > It's not as dire as you make it out to be No, it actually is. So much of it just straight up doesn't work, things that AppKit provides for free without any effort at all. One would expect the native styling to be able to help with it but it simply doesn't. > You've now shifted your goalpost from modern looking to being exactly what AppKit or SwiftUI does Actually, I'll quote myself: "I'm still waiting for a single Qt-based app on macOS that feels like a macOS app" — no emphasis added, I even italicised 'feels' in my first reply. Feeling native is more than just looks. It's behaviours. I'm repeating myself because even GP mentioned "better UX", not "better UI". The experience includes how things work. Your assertion was "You can make Qt look however you want. The point is that it will give you native UI by default" — it was actually you who decided the discussion was all about looks, not about experience. > Qt by default has basic accessibility support on macOS thce same way AppKit does Not a single Qt app on my system supports Large Text. Simply doesn't do anything when I hold Cmd and move my pointer over things. > It's not always perfect Agreed that no accessibility system ever is, particularly if developers don't test it, but… > but it's not as dire as you make it out to be. Spoken like somebody who doesn't rely on accessibility features. Not just use, rely. > Qt6 also supports theme changes fine. My computer would say no to that, with random bits of the UI not changing colour at all when I change the system light/dark mode. It was such a problem that one of the most-used cross-platform apps written with Qt, OBS Studio, completely disabled the native theme for its theming inconsistencies. > But none of this is the premise of the original argument I was replying to. Okay, so that just means you're having a new discussion with me, then. Besides which, GP's premise to which you replied was "Qt feels too locked in to old decisions that were the right choice at the time". I don't see that I'm contradicting that. With late-90s to early-2000s design decisions (like toolbars that tear off with drag handles, like Office 2001/2003 and Visual Studio) the cornerstone of what each widget is designed to do and how its appearance should be, how it should behave, and how these things interconnect with other aspects of the UI system, those "old decisions" really do get in the way of the "better UX" that GP described. Like I said, Qt apps feel like they're wearing a Mac skin over the bones of a Windows 95 program (okay, maybe more like 2000 or XP, but that's still almost 30 years old). Mac OS X has been out and supported all the things I've talked about in Cocoa and Carbon for as long and yet Qt still remains a poor facsimile on the Mac all this time later. The experience is just as GP said, a clash of old and new. Probably less noticeable on Windows and Linux but sticks out like a sore thumb. I continue to await any suggestion of a proper native-like app written in Qt that looks AND behaves like a modern Mac app. And look, I don't mean for this to be an argument. It's got the shape of one but I really do enjoy discussing this with you. I guess, at the end of the day, that the idea that something might look acceptable on a system is sufficient to say that its toolkit is up to the job is not one that leads to the best user experience. | ||