Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

9 years of Apple text editor solo dev

papereditor.app

Post reply on HN
Print view View original

291–300 of 405 posts

Re: 9 years of Apple text editor solo dev

#291

Post by deergomoo »

papereditor wrote: post #274
deergomoo wrote: post #267

Great read! A question for the author (as I see they're in this thread and hopefully still around!) -- do you have any good resources and recommendations for learning AppKit and Mac development in general? I've been (very slowly) dabbling around writing a Game Boy emulator in Swift and, surprisingly, some of the biggest difficulties I've had have been actually getting stuff on-screen, rather than the emulation itself…

Thanks! Can't recommend anything specific, to be honest. I've been piecing together information from old Apple docs, StackOverflow, API header files, and a bunch of really weird blogs. A lot of trial and error as well. I think your best bet is ChatGPT. It has seen every possible use-case of Apple APIs from GitHub so it should know a lot. I've gotten some good tips from it for very specific things that did not exist o…

Thanks!

Re: 9 years of Apple text editor solo dev

#292

Post by hbn »

monkeynotes wrote: post #45

All the "fringes" stuff is where the magic is. The author suggests that no one notices some of the refinements, well this may be true on day one, but people discover these touches as they grow more familiar. Those subtle thoughtful additions are what makes the difference between an app I like using, and one I love using. They help me feel a couple of things: 1) A connection; I feel like I noticed something just for t…

Apple has a lot of niceties like this in their software. I've had so many times I thought "I wonder if I can do this?" and it just works because a designer thought of it before me.

Prime example I stumbled upon recently: In Apple Music, you can press+hold an album or song to pop open an action menu. I use this a lot for adding songs to the queue. There's an item to add it next in the queue, and another to add it last in queue. Usually if I want it somewhere specific in the queue, I'd just add it next and then move the song where I wanted it, but if I'm adding an album partway through the queue, that means you'll be dragging a bunch of tracks manually. So I thought, "it'd be nice if I could just drag things exactly where I want in the queue and drop it there." And then I figured I'd actually try it. If you press and hold a song/album and yank it from its place, it stays under your thumb. You can then either operate with another finger to open up the queue, or hold your thumb over it to pop it open, and then just drop it exactly where you want in the queue.

Not the first time I've come across something like this, but it's the kind of thing I only find on Apple platforms, particularly with their own apps. As much as I liked Google Play Music, you couldn't do it there, and I just checked Spotify and it doesn't let you do that either.

Re: 9 years of Apple text editor solo dev

#293

Post by leonheld »

skydhash wrote: post #82
leonheld wrote: post #44

Earlier quoted context omitted.

Let's put it like this: you want a nice drawer to store clothes. It has one purpose and one purpose only. You can either go to Ikea and get a 50 EUR drawer that will do the job, or you can pay 500 EUR to a local artisan for a nice cabinet with solid wood, an elegant design, a nice finish and even good wood for the back part. Literally depends on who you are, but I don't see how this is any different. And before "soft…

Is software cheap? Even a small project can a few weeks to hack things together, and if you try to price it based on your hourly salary, the cost can climb in the thousands really fast.

I meant as in the material itself. Software scales a lot, to the point it's not even comparable to some raw assets like wood.

Re: 9 years of Apple text editor solo dev

#294

Post by pappereditorrr »

papereditor wrote: post #288
pappereditorrr wrote: post #265

Nice app but your marketing make me not want to use the app. 1. The blog is flooded with SEO oriented posts https://papereditor.app/blog This vs That, Top this, Top that 2. In the App Store a whole bunch of other text editors are mentioned in the app description text in order to be included in the results when people search for other text editors. I'ts just shady and unnecessary if you trully believe in your app.

Thanks! 1. What's wrong with SEO? People discover the app from Google. Some of them even become paid customers. If people discover and purchase what they need - what's the harm? 2. That does not affect the App Store search results. If it would have - everyone would be doing it. App Store allows a lot of text in the description, so I thought I would fill it with something useful. I've also ordered the names from short…

1. Nothing is wrong with SEO. But I expected a blog in a similar fashion as your .dev page but I was highly disappointed when all I saw where these "empty" click-bait esque posts.

2. I've seen plenty of apps doing the same trick in the App Store. But if it doesn't affect the search indexing why even bother putting up a long list of apps that could hurt your business.

Nothing but respect for the work that you do and the app you've created.

Re: 9 years of Apple text editor solo dev

#295

Post by raydev »

lenkite wrote: post #255
jimbokun wrote: post #158

Earlier quoted context omitted.

When I tried using SwiftUI, the performance for scrolling through lists past a certain size was very painful. I guess there were ways to mitigate this slowness, but they were very unintuitive and did not give me confidence in the developers commitment to keeping apps snappy and responsive. The APIs for NSTableView and NSCollectionView, in contrast, were always very responsive and performant when used in the default w…

I wish Apple had stuck to Model-View-Controller instead of shoehorning React philosophy into their native UI framework. Personally, I find the "old-school" way of doing things far easier to follow and understand.

The existing UIViewController and how it's implemented breaks the model-view-controller pattern, so there was nothing to stick to.

Re: 9 years of Apple text editor solo dev

#297

Post by fsckboy »

monkeynotes wrote: post #45

All the "fringes" stuff is where the magic is. The author suggests that no one notices some of the refinements, well this may be true on day one, but people discover these touches as they grow more familiar. Those subtle thoughtful additions are what makes the difference between an app I like using, and one I love using. They help me feel a couple of things: 1) A connection; I feel like I noticed something just for t…

> people discover these touches as they grow more familiar

people discover these touches in the breech, when they need to move on for some reason or other, and all that's familiar is lost. in the words of Joni Mitchell, "you don't know what you've got till it's gone"

Re: 9 years of Apple text editor solo dev

#298

Post by eslaught »

rubymamis wrote: post #272
eslaught wrote: post #216

Since the author seems to be in the comments, have you ever considered implementing a Typora-style live preview? (Typora, for those who don't know, hides the Markdown formatting as you type, and shows it again when you move the cursor back onto the text.) Paper appears to have a more traditional split between text mode and preview mode, and you can't properly edit the formatting in preview mode (e.g., you cannot turn…

As someone that implement this right now in my block editor[1] I must say it's a HUGE pain in the ass. Synchronizing the underlying plaintext/markdown with the rendered rich-text/HTML is a big undertaking. Especially so, since Qt's QML TextEdit conversion between its rendered HTML and Markdown is so inconsistent and broken. I've been thinking of ditching it, but I might persevere and continue to try. [1] https://www.…

I totally get that.

I'm just one person, but for me, this was the feature that made me switch to a minimalist text editor for writing.

Otherwise, why not stick with Emacs? Plain text with light syntax highlighting is something Emacs already does fine, it's relatively distraction free, it has keyboard shortcuts I've already memorized forward and backwards.... The biggest downside is that I have to pop over to another window to get proper syntax rendering and to be 100% sure it's parsing the way I expect.

Anyway, just my two cents. I could totally understand it not being worth the effort to implement, but when it works, it's really nice.

Re: 9 years of Apple text editor solo dev

#299

Post by timestretch »

hbn wrote: post #292
monkeynotes wrote: post #45

All the "fringes" stuff is where the magic is. The author suggests that no one notices some of the refinements, well this may be true on day one, but people discover these touches as they grow more familiar. Those subtle thoughtful additions are what makes the difference between an app I like using, and one I love using. They help me feel a couple of things: 1) A connection; I feel like I noticed something just for t…

Apple has a lot of niceties like this in their software. I've had so many times I thought "I wonder if I can do this?" and it just works because a designer thought of it before me. Prime example I stumbled upon recently: In Apple Music, you can press+hold an album or song to pop open an action menu. I use this a lot for adding songs to the queue. There's an item to add it next in the queue, and another to add it last…

I'm surprised to see an example from Apple Music. That app is an perfect example of design neglect too. The ability to filter your song list for a specific track is now hidden in Apple Music.

To reveal the filter field, you must select the "View" menu, and "Show Filter Field". Worse each time you relaunch Music, this field is again hidden, and you have to select the menu item again.

Post reply on HN