iamcalledrob

Very happy to see a 4K display. Framework take note!

In UK highway terminology, you're "driving" in the bike lane if your vehicle enters it.

I'll be watching this project.

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.

I'd imagine it depends what kind of emissions you're measuring? Are we talking air quality or climate change?

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.

Perhaps this is naive, but I would imagine that farm equipment is a rounding error in terms of global emissions. Compare the number of tractors to the number of trucks...

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

Glad it works for you. It runs fine, but details become blurry as they get spread across pixels,

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

It just, just not enough real estate!

I really wish this had a 4K display option. As someone who dislikes fractional scaling.

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

I wonder if the US is the only place where this applies?

The UK, I believe, can compel you to provide passwords that you would be reasonably expected to know.

The docs are great too.

Of course absolutely ancient, but once you learn how to read them, they're very comprehensive.

And the 3rd party content written about win32 is pretty evergreen. I regularly find articles written in the '90s that are helpful today. The beauty of an incredibly stable API, and documentation written before everyone had the internet.

Just like the frontend dev ecosystem. Wait...

> But there is an issue with Win32 API programming. And the truth is that custom windows mean doing everything yourself, controlling every Windows message, and that is fragile

This isn't actually true though. You can delegate to the default window proc, and only customise what you want.

Sure, if your window is now a triangle, you need to think about how resizing is going to work. But you don't need to re-implement everything from scratch -- only the defaults that aren't compatible with your new design.

Personally, I find that any Windows application that is remotely polished will have its own win32 WindowProc anyway, even if written in higher-level tech.

For example, if you want custom window controls, you need to use a WindowProc + WM_NCHITTEST to tell windows where the buttons are, so the OS can do things like display the window snapping controls when you hover over the "Maximize" button.

Sidenote: as a designer, its disappointing how many Windows apps are subtly broken in a bunch of these ways. Its not that hard. "Modern" UI frameworks generally don't do this work for you either, there's a real lack of attention to detail.

Don't have to grep my go errors :)

You could argue that what you built isn't novel or complex in any way -- (politely) it's basically a clone of hundreds of other SAAS homepages. i.e. its a perfect use-case for AI.

Perhaps the results would be different if you had a specific novel design or interaction in mind, and you wanted the AI to implement that exactly as you wanted.

edit: My point proven by the other examples from this thread. Same format, same "feature cards" etc. https://bridge.ritza.co/ https://poolometer.com/

Similarly, the native Android photo picker strips the original filename. This causes daily customer support issues, where people keep asking the app developer why they're renaming their files.

https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).

Different strokes for different folks.

The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

People give Go's error handing a lot of flak, but I personally love the errors that come out of a quality codebase.

Just like your example: single line, to the point and loggable. e.g.

  writing foo.zip: performing http request (bar.com): tls: handshake: expired certificate (1970-01-01)

Exceptions with stack traces are so much more work for the reader. The effort of distilling what's going on is pushed to me at "runtime". Whereas in Go, this effort happens at compile time. The programmer curates the relevant context.

> But every company I worked at in the past 10 years or so eventually coalesced around a singular "design system" managed by one person or a small core team.

As a designer, the issue I see is that desktop design requires knowledge and experience of the native toolkits.

This makes desktop the hardest platform to design (well) for.

For example, on macOS you need to know about where the customisation points are in NSMenu, you need to know a little about the responder chain etc.

Most designers only have web or mobile experience, and the nuances of the desktop get lost, even at th design stage. You end up with a custom and shallow system that is weird in the context of the OS.

You also end up with stuff like no context menus, weird hover states (hand cursors anyone?), weird font and UI sizing (why are Spotify's UI elements literally twice the size of native controls? The saving grace of it being an Electron app is that I can zoom out 3 steps to make the UI size sane). I digress...

Perhaps the situation has changed since I last tried.

It used to be, in AppKit, that a normal NSButton could have its size class changed (small, regular etc.) but you couldn't set the height without subclassing and doing the background drawing yourself!

As the author identifies, the idioms come from the use of system frameworks that steer you towards idiomatic implementations.

The system UI frameworks are tremendously detailed and handle so many corner cases you'd never think of. They allow you to graduate into being a power user over time.

Windows has Win32, and it was easier to use its controls than rolling your own custom ones. (Shame they left the UI side of win32 to rot)

macOS has AppKit, which enforces a ton. You can't change the height of a native button, for example.

iOS has UIKit, similar deal.

The web has nothing. You gotta roll your own, and it'll be half-baked at best. And since building for modern desktop platforms is horrible, the framework-less web is being used there too.

iOS decided square checkboxes were ugly, and design patterns are flowing from mobile->desktop these days.

Plus, Apple exempt their own apps from a bunch of these permissions (because it would be an unacceptable user experience for their customers)

The actual best open source Dropbox replacement already exists: SeaFile. Too bad their website is terrible.

https://www.seafile.com/en/home/

It's pretty magical. It nails the "online" vs "cloud only" paradigm via the SeaDrive client. I have it running on my file server, and now all my machines have access to terabytes of storage with local performance, since it can cache a subset of your content locally.

And since I can run the server on my LAN, the throughput is way better than Dropbox would be too.

My GNOME desktop is more coherent than my Mac one at this point

If we're talking a simple "hello world" window then sure, you can resize that at 60fps on pretty much any system.

But most nontrivial apps can't re-layout at 60fps (or 30fps even).

They either solve it by (A) allowing the window to resize faster than the content, leaving coloured bars when enlarging [electron], or (B) stuttering or dropping frames when resizing.

A pleasant exception to this I've noticed is GTK4/Adwaita on GNOME. Nautilus, for me at least, resizes at 60fps, even when in a folder of thumbnails.

On the Mac side, AppKit, especially with manual `layoutSubviews` math easily hits 60fps too. Yes it was more complex, but you had to do it and it was FAST.

Qt apps don't feel great on macOS, though it's by far the best for mac-ish UI. Dropbox was Qt for a long time and I'd argue it worked well for them. Its easy to fall into "uncanny valley".

On Linux, Qt apps feel a bit off in GNOME, though you can never satisfy everyone as its the wild west.

I think Qt also suffers from not really being anyone's favourite.

On the one hand, you have web developers who tend to not really appreciate the nuance of the desktop as a platform. They're not going to advocate for Qt, it's not CSS/HTML/JS.

On the other hand, you have native Mac developers who love Apple's toolkits (AppKit, maybe SwiftUI). They're not going to advocate for Qt either.

Lastly, you have native Windows developers who have been burned so many times they don't advocate for anything in life anymore.

Personally, its not so much about customisation as it is consistency, quality, and attention to detail.

Being able to keyboard through menus as standard. Focus being deeply considered and always working as expected.

Compact UI elements -- in the 90s/00s we decided buttons should be about 22px tall. Then suddenly they doubled in size.

We've ended up in a world where power users have been forgotten. Not out of malice, but out of a misguided aim to reduce complexity and achieve consistency with the web.

I would argue that desktop is the platform for power users, and its future depends on them. The keyboard shortcuts, the micro-interactions, the window management -- this stuff is all important when you're using a system for 8+ hours per day.

Yet we risk desktop experiences becoming less useful due to the UI becoming "dumber" as we keep shoehorning websites onto the desktop. Website UI is dumb. It's mouse driven, keyboard is an afterthought. There's no consistency, and you have to re-invent the wheel every time to get the details right (almost never happens).

Desktop, especially Windows, is such a mess.

It's 2026. We're running 8+ cores and 32gb ram as standard. We can run super realistic video games at high frame-rates.

Yet on the same machine, resizing a window with rectangles in it is laggy on every platform except macOS (where there's a chance it's not laggy).

...but then feeling out of place on GNOME / GTK4 / LibAdwaita-land

Linux is a mess, but at least it's unapologetically so.