> Categories in Objective-C are a way to add new methods to any existing class, including framework classes (categories can also be used to replace methods, which is both powerful and scary ). I use them to harmonize the API. So if a method in UITextField is called text and in NSTextField it is called stringValue I can add a stringValue method to UITextField that calls text (or vice versa). > By the way, I also use c…
Keeping my fingers crossed it will not happen. :D
9 years of Apple text editor solo dev
241–250 of 405 posts
Re: 9 years of Apple text editor solo dev
#242Earlier quoted context omitted.
What do you mean by "smoothing the caret"? I just tried the app to see if I can make sense of it; do you mean that the caret does not blink if you continuosly insert characters?
Something like this: https://www.youtube.com/watch?v=FCUi_dRU0tY
Re: 9 years of Apple text editor solo dev
#243Re: 9 years of Apple text editor solo dev
#244Re: 9 years of Apple text editor solo dev
#245The ability to go low/no-dependencies, as mentioned in the blog post, is one of my favorite things about Apple platforms. It’s not just possible but practical to build a capable, highly polished app without bringing in anything third-party thanks to the richness and depth of AppKit/UIKit. Few frameworks can compete, with even other juggernauts like Qt coming up short in comparison.
Contrast with a lot of the web frontend ecosystem, where stuff might go stale within a few months. And the overall pervasive feeling of jank that comes when you're building UIs. (Though, I presume this goes away once you internalize browser layout engines better.)
For my two Mac apps, I use very few third party deps. They're simply not needed! They serve small, discrete purposes and could be replaced by bespoke code at a moment's notice. This is how software should be built! We've just forgotten about this because the browser ships with so little in terms of UI components.
Re: 9 years of Apple text editor solo dev
#246The ability to go low/no-dependencies, as mentioned in the blog post, is one of my favorite things about Apple platforms. It’s not just possible but practical to build a capable, highly polished app without bringing in anything third-party thanks to the richness and depth of AppKit/UIKit. Few frameworks can compete, with even other juggernauts like Qt coming up short in comparison.
And you are now locked down to one environment.
The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.
Re: 9 years of Apple text editor solo dev
#247> I had little trust in my ability to pick the right dependencies from an ecosystem that I was not familiar with For me this is an invaluable lesson to learn. A pet peeve of mine are tutorials or guides which consist of a list of external packages and libraries to add before writing a line of code. This write up is excellent though, some of the gripes I have with the Apple eco system the OP has turned into a 'learnin…
> For me this is an invaluable lesson to learn. A pet peeve of mine are tutorials or guides which consist of a list of external packages and libraries to add before writing a line of code. likewise, 80% of the tutorial is preamble to prepare for the 20% you care about. just don't.
And it's still the most useful guide to setting up Qt because it's the only first-page result that mentions Berkeley.
Re: 9 years of Apple text editor solo dev
#248Earlier quoted context omitted.
The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows. Cross-platform applications have their place, but sometimes I like h…
This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.
And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead.
There's no silver bullet here.
Re: 9 years of Apple text editor solo dev
#249Re: 9 years of Apple text editor solo dev
#250Earlier quoted context omitted.
The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows. Cross-platform applications have their place, but sometimes I like h…
This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.
This fundamentally doesn’t work for UI/UX. You have to pick a paradigm and implementation details at some point and the high level UX design of Windows UI dejure and Mac are just different, in ways that cannot be factored out of a framework without leaky abstractions.
Your choices are: the Qt/Tk/Swing approach write once, a solid if dated UX that is themeable but not truly native anywhere, the web app (or its QML/Flutter/FX equiv), wxwidgets etal which sort of tried to be native everywhere last century and looks and works that way, or at least two parallel independent native UI implementations which is a gargantuan more effort.
Or go whole hog with FLTK or your own custom thing. a11y? WTF is that?
“ Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.”
I wouldn’t call wxwidgets basic, but it is a mess. It can’t be any other way. If it could someone would have made it in the last 30 years.
Just because you use Cocoa/AppKit rather than drawing on a canvas does not magically make your app feel like a Mac app.
Literally 100s of side projects have started down this path. People eventually learn you can’t abstract everything away, at least not the labor intensive part.