Another issue: Paper was tied to your Dropbox account.
From Dropbox's perspective, this sounds great. Accounts become more useful and valuable. The addressable market of a Dropbox account grows! Plus, everyone has a Dropbox account already, right?
Unfortunately, it turns out that business customers generally don't deploy Dropbox wall-to-wall. It's expensive. Not all employees need file sync.
A Dropbox account ends up being an obstacle to adoption.
And a distraction: a common account creates an irresistible urge to spend a lot of time finding ways to tie this new product into the old one.
The micro-interactions and hotkeys in GIMP are just so poor though.
For example, basic stuff like zoom in and zoom out are bound differently to literally any other app on any platform. This catches me out every single time I try to use it, and I'll never learn the GIMP way.
Spoiler for anyone unfamiliar: it's not Ctrl+/Ctrl-.
Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :)
And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance.
iMessage for mac used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.
The Mac never used WebKit for NSTextField rendering. When iOS was first written, WebKit was used as the text renderer everywhere initially, including in UIKit controls (the “sweet solution”). This proved to be too heavyweight / cumbersome and the coretext/appkit text rendering approach was brought over.
On what platform? It invoked WebKit always on iOS in the early days, html or not. On Mac, AppKit could import html to attributed strings before WebKit existed.
...although the logic in the article is slightly odd:
1. Discover complex native text rendering is hard
2. Render text in a low-level way, complain about having to (re)implement native interactions
3. Try WebKit and it works great!
4. Throw WebKit away??
5. Have to re-implement native interactions??
It baffles me a bit that people are working so hard to replace themselves with AI. It's such a high bar for the AI to hit, and takes the creativity away from the human.
I have a pet theory that perhaps the optimal way to use AI will be more like an "exoskeleton" that turns you into a super-human programmer. Something that plugs the deficiencies of the human programmer, rather than replacing you entirely.
It was really interesting, like a third way of doing things that wasn't "windows" and wasn't "mac".
The OS being on ROM made booting insanely fast. Like 2-3 seconds from cold start to the desktop.
Programs were actually folders, like modern macOS, so you could poke around at how they work. BASIC was still a thing, and I remember being able to edit the BASIC source code of some programs. Felt like "view source" did for the web.
Plus nothing has ever come close to the blue mouse cursor :)
Programs being folders was useful for mischief. Most people never noticed the ! in the filename, so I’d amuse myself by turning classmates’ document folders into applications that would run a script when clicked. I’d fire scary error messages, load full-screen images or mess with the system settings.
"Everything you set up to customize the system, like desktop icons, window positions, desktop resolution, and other settings is reset every boot unless you manually tell the system to save the current state as the "boot file.""
OS in ROM so of course no state could be saved except as a file on a floppy disk. ROM based systems have certain advantages when working with classes of investigative and curious teenagers.
Hard drives came a bit later; there was a retrofit of a Rodime 20 Mb drive that fitted into one of the podules on the back of the A310, and had its drivers in an updated system ROM. Good times.
Most of the hardware had rom with its drivers in it. Meant just about everything was a plug and play experience.
And it is true that bit was fast, but once you'd customised the font and replaced all the system icons and set strongedit as your default editor in your!boot, it could take quite a long time to start up.
Archimedes computers had CMOS RAM for persistent settings, so I imagine the author's emulator was not set up correctly, as many settings including almost all the ones they describe do persist on a real computer.
From Dropbox's perspective, this sounds great. Accounts become more useful and valuable. The addressable market of a Dropbox account grows! Plus, everyone has a Dropbox account already, right?
Unfortunately, it turns out that business customers generally don't deploy Dropbox wall-to-wall. It's expensive. Not all employees need file sync.
A Dropbox account ends up being an obstacle to adoption.
And a distraction: a common account creates an irresistible urge to spend a lot of time finding ways to tie this new product into the old one.
reply