4 ms·
Coming from AppKit/UIKit I tried to learn Qt and it was just awful. I hated how tightly coupled with C++ it was. Everything was based around subclassing and ove
by jhatemyjob 3y ago
Coming from AppKit/UIKit I tried to learn Qt and it was just awful. I hated how tightly coupled with C++ it was. Everything was based around subclassing and overriding methods, there was no way to just have a dumb UIView and set its frame and add a bunch of subviews to it. There was also no clean way to expose a C ABI to use a scripting language (with an FFI) to configure the UI easily
All of the Qt apps I know about (Ripcord, Dolphin) are fast but the aesthetics of the UI was just terrible. So I gave up on learning Qt. But this thing you made, Plume, actually looks good. If there isn't a monstrosity of hacks and boilerplate underneath this UI I might give Qt another shot. Otherwise I think I might just build my own thing from scratch on top of OpenGL or something....
- rubymamis 3y agoI feel ya! I thought the same, until I discovered the world of combining Qt C++ and QML. QML is extremely easy to learn (I studied all the basics in one day using this Udemy course[1] (not affiliated, just love his work). BTW, he has many free awesome YouTube videos for Qt C++. Creating an aesthetically pleasing app in any framework takes a lot of effort (it's mostly about being focused on what necessary and then creating a lot of white space around it, haha). It's so easy to create beautiful, fluid UI with QML. I've created a short video that demonstrate what I'm working on currently[2] - a Kanban view inside my block editor (kinda buggy now, still WIP). Hopefully, this does inspire you that it's possible. And it's actually pretty easy to write the C++ code. I don't really use custom sub-classing much. I use Qt's QtObject which allows me to create C++ object that work beautifully with QML. Bryan's course doesn't delve deeper as that, I had to do a lot of searching to figure it out. I hope to open source some of Plume's components to inspire others to do the same. Another point regarding aesthetics, it really takes effort, but Qt can be extended using community libraries. For example, if you want your app to look native on macOS and Windows with a sexy frameless border with a transparent window, then you could use the awesome qwindowkit[3]. Another example, I wanted to position the window buttons on macOS (the traffic light buttons) differently, but couldn't figure it out, and obviously this can't be done using Qt alone, so I looked at Electron's source code and saw how they do it there in Objective-C and incorporated it in my app (ChatGPT-4 wasn't very helpful at that). Now I really want to have these buttons' fill color transparent like Things 3 does, so I'm looking at how to achieve that haha. I already got some ideas. If you need any further help, let me know![4][5]. EDIT: A cool feature of combining Qt C++ with QML is that you get the performance of a compiled language like C++ with the reactivity, ease-of-use, fluid and easy animations (and more) of QML. You can see on Plume's website that it's 4x faster than the fastest comparable native app on macOS. [1] https://www.udemy.com/course/qml-for-beginners/ https://www.udemy.com/course/qml-for-beginners/ [2] https://www.loom.com/share/b40009316f6b420b9ece15a1f99e987c https://www.loom.com/share/b40009316f6b420b9ece15a1f99e987c [3] https://github.com/stdware/qwindowkit https://github.com/stdware/qwindowkit [4] https://twitter.com/mamistvalove https://twitter.com/mamistvalove [5] ruby AT mamistvalove DOT gmail
- jhatemyjob 3y agoThanks for the candid reply. Man... this sounds like too much for me. Oh well. Guess I'll use AppKit for now and if I wanna add Windows/Linux I'll bring in Qt. Definitely will come back to this comment if/when that happens.
- rubymamis 3y agoNo problem mate, let me know if you need any help. Good luck with AppKit!
- jwells89 3y agoI know what you mean. Would love to just have AppKit/UIKit with some platform integrations (e.g. correct widget themes) on other platforms. Closest that exists to that is GNUStep, but it’s stuck on an old version of Objective-C (no Swift) and targets something like OS X 10.6 with API compatibility. Outside of the that the next closest I’ve tinkered with is GTK, but since version 3 it kinda gave up on looking right running under anything but GTK/Qt-based desktops. It’s easy to make idiomatic bindings for which is nice though.
- jhatemyjob 3y agoYea, GNUstep isn't bad. It uses an old version of ObjC? Are you sure that's correct? ObjC is open source right? There is no reason to be using an old version. Yeah the frameworks are kinda old but the new frameworks (since ~2014) don't really bring anything new to the table. And Swift is overrated anyway.
- jwells89 3y agoNot entirely sure about Obj-C version. Disagree regarding frameworks, though. The newer snapshot-based APIs for NSTableView, NSOutlineView, and NSCollectionView (added in 2020 as part of macOS 11) are a massive improvement over the old index-based ones for example, and there’s been numerous polish and quality of life improvements scattered throughout. Also disagree about Swift if only for the large number of things it comes with out of the box that’d require a third party dependency with Objective-C, but so many more errors being caught at compile time, no need to maintain header files, and no awkward split between C and Obj-C for basic types are nice too. I still enjoy Obj-C for some types of projects but as project complexity increases so too does my preference towards Swift.
- jhatemyjob 3y agoOh I didn't realize they were still adding APIs to AppKit. That's cool. Yea I mean the ObjC vs Swift thing.... a matter of preference. I trust Steve Jobs more than I trust Tim Cook. I hate the feature creep in Swift. I hate Swift optionals. ObjC compiles faster than Swift. The ObjC ABI/runtime is superior to the Swift ABI/runtime (which allows for cool stuff like https://cycript.org https://cycript.org). I like the dynamic typing a lot. Managing headers is a non-issue for me, I just consolidate everything into one monolithic header file. I've worked in pretty big ObjC codebases (1M+ lines) so I know most of the tricks to deal with complexity. For Swift, max I've dealt with is 100k lines and it was crippled with tech debt. Frankly, the other engineers on the team were terrible, so maybe that's why. They abused the shit out of RxSwift and refused to use the `!` force-unwrap optional feature