I'm increasingly seeing this crap, and I'm hereby officially adding it to my list of things that piss me off.

This window is not resizable:

WHY?!

The text that I removed from it is several lines of information, any one of which extends far beyond the width of the text area.

If this were an isolated incident then I'd chalk it up to someone being a moron and move on, but it's happening more and more and more often and it's really starting to rile me up.

PSA: PLEASE LEARN TO USE WINDOW STYLES APPROPRIATELY

I know the rest of you must have pet peeves like this. Let's air the laundry while we're here. What design failures get your goat?

What design failures get your goat?

I get really annoyed with programs where the order of yes|no buttons on dialog boxes is inconsistent.

Why? Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself. Not to mention the little hoops you need to jump through to avoid flickering.

Despite that, sizing an options dialog so that it's contents fit without scrolling has been a solved problem for so long that the example in the OP is really inexcusable.

What annoys me most is programs that use their own custom widgets instead of the built-in OS ones. Particularly where there are enough subtle differences in behaviour to make it a usability hell.

Most of my windows are resizable - using Qt's layouts to auto-resize the sub-widgets - but some of my widgets* need to be fixed sizes, or it majorly messes up the appearance.

Anything with a major box of content with scrollbars (like your example) can obviously resize fine though, so those windows in my project can definitely resize.

*custom ones with just enough behavior differences to annoy mhagain

I get really annoyed with programs where the order of yes|no buttons on dialog boxes is inconsistent.

I did that once by mistake. I forgot what order the standard Windows button layout was, and accidentally used the reverse, and for the next week I kept instinctively hitting "cancel" instead of "OK" until I realized my mistake.

Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself.

[window setStyleMask: [window styleMask] | NSResizableWindowMask]

Making windows that properly resize in the win32 API (and I assume whatever OSX and Linux use for their base API) is non-trivial as you have to do all the math yourself.

Unlike the wacky world of Microsoft Windows, making a window properly resizeable on a Mac is the result of flipping a single bit:

[window setStyleMask: [window styleMask] | NSResizableWindowMask]

Proper UI frameworks are very nice to you. Not sure why people continue to muck around with legacy APIs like Win32, when newer (and better) alternatives are widely available...

Since recently switching to high DPI monitors I'm not fond of apps that don't layout properly (including some of my own :)).

The worst offender of all is Skype, which actually properly detects the DPI setting, then proceeds to automatically lower its default font-size from 10pt to 4pt to compensate and make the text use the same number of pixels as on a low DPI. Luckily it can be set back to 10 and make chat readable again, though the list of contacts is always super small.

Will that actually make all the contents nicely reflow though? It's not hard to make a window resizable in Windows either, but none of your controls will adjust to match.

No.

But the Cocoa API also has better mechanisms for dealing with control reflow on resize than Win32, where you are *basically* doing it all yourself (abstractions like Windows Forms and WPF have them though).

But the Cocoa API also has better mechanisms for dealing with control reflow on resize than Win32, where you are *basically* doing it all yourself (abstractions like Windows Forms and WPF have them though).

This. Mac UI development is effectively equivalent to how it would be on Windows if the Win32 API didn't exist, and WPF was your baseline API.

And note that's roughly how it evolved on the Mac side as well. The Win32-style C++ APIs existed in the form of Carbon up until about 4 years ago, when they were finally fully deprecated in preparation for the move to 64-bit.