The UI code needs to be structured with animation in mind, with hooks in the right places. And to do that, you need to know what is likely to be animated together.

But what ends up happening is you encapsulated a few of the moving pieces in abstractions (e.g. "toolbar", "sidebar"), but you want to animate stuff within. You end up copy+pasting animation logic inside each (now leaky) abstraction and duct taping it all together. UI abstractions are hard!

(Yes, on apple platforms there are transition blocks which will capture changes to the entire view hierarchy, but then the battle becomes preventing animations on stuff that shouldn't change!)

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.

And UI code quality tends to be technically pretty crummy/low-discipline. Your UI code doesn't need much consideration around data races, for example.

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-.

  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??

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.

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.

Horizontal dragging with a mouse is actually really hard. Nobody's going to use it like that.

Your arm can easily move your hand and cursor up/down by pivoting your shoulder, but there's no mechanism for left/right movement. It's always an arc.

Or put another way: selection will be a lot slower and more tedious than the demo.

For some reason that always means WebKitGTK, which is crummy.

Someone, anyone, please get CEF working with GTK4.

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 :)

But then again, their technical model has always been "fat client, dumb server" from the start.

Personally, I'm highly allergic to fractional scaling. It's 200% or I'm not buying it!

Looking forward to a Golang declarative framework.

My advice to the author: invest in rich multi-window support early on. It's easy not to, but you always need it in the end, and it's painful to retrofit.

I feel like there's a great cross-platform UI story to be told with Go, since cross compiling is so easy.

Two stroke engines are pretty terrible in terms of unburned hydrocarbons and are disgusting for local air quality, which is why I'm glad they're being phased out in many areas.

I'd expect these tractors with I6 diesel engines to run pretty efficiently. I'd bet that the CO2 emissions from tractors are tiny in comparison from the emissions from trucks, fertiliser, and transporting the food.

I would have expected policy to be pragmatic here, with (relatively) relaxed emissions requirements, since an affordable and reliable food supply is in the national interest? Sounds like that's not the case

I do UI design, so I find it important to see things in full fidelity (no pixel smudging).

I'm clinging on to my older Thinkpad X1 because the 4K display is so good.