jwells89

For personal use, the only issue I take with Obj-C is how it's considerably less "batteries included" relative to Swift.

For collaborative projects on the other hand, it can become a handful to maintain if everybody contributing isn't staying on top of hygiene with null checks, type checks, etc. Swift helps to keep all of that under control.

Be careful with these though, a lot of USB switches (most readily available ones, even) aren't wired correctly and can result in current flowing from one computer to the other.

A fork wouldn't be explicitly required, but generally in established FOSS projects, when attempting to make changes that are either large or widely peppered throughout the project you're going to be fighting against headwinds from people who are happy with project as it is, which is understandable. You're likely going to find yourself spending more time on negotiating and politicking to get changes committed than actually making changes.

Audio/video has more to do the distribution being used than it does one's desktop environment, though the DEs can do things to smartly design configuration UI and surface the most commonly used A/V settings in the right places.

If I sat down to compose the list, it'd be full of lots of small things. Think how under KDE, the file copy progress UI is a semi-persistent notification banner instead of a normal dialog like it's always been on Windows. While each of these differences on their own aren't likely to pose issues, in aggregate they can give an impression of the DE being more unfamiliar/alien (and thus, daunting) than it actually is.

I would probably also overhaul the settings app. For example, the whole Appearance & Style group and its two drill-down sections could be pretty easily reworked into a single panel that directly surfaces the most pertinent settings while tucking away the rest under an "Advanced…" button that opens a modal — with themes for example the average user will at most be interested in changing the global theme. Only advanced users even know the difference between window decorations, application styles, etc much less want to be able to change any of those individually.

Themes are great, but they're surface level and don't change the numerous little behavioral/UX differences between KDE and whichever version of Windows. They also require the user to have gotten as far as to discover that KDE supports themes and downloading, installing, and enabling the theme.

That's why I think a fork that implements the requisite changes would be of value.

The sheer lack of useful software in a stock Windows install has always been a bit baffling to me. Linux is better in this regard (depending on distribution), but nothing beats macOS for time from fresh install to usability. Not only does it come with most of the basics covered, apps like Mail don’t favor Apple’s services, unlike on Windows where MS can’t pass up the chance to upsell an MS service.

KDE is solid but I think is just different enough to throw off less technically oriented would-be switchers. I think a fork of KDE that changes it to be more of a 1:1 match to Windows would be highly beneficial here, especially if this fork has a dropdown menu that can switch which version of Windows it mimics (lots of people miss 7 and XP and would find a zero effort way to get that experience back tempting).

It depends a lot on what hardware one has and what software one uses, in my experience. A laptop that’s a generation or two behind built without discrete graphics, Intel networking, and a display that’s usable at 1x UI scaling? Smooth sailing. A bleeding edge tower with off-brand integrated networking and an Nvidia card hooked up to a monitor that requires fractional scaling on the other hand might be more trouble.

> That means throwing out a lot of code too. It's the cost to pay.

And likely, upsetting power users who want to run with all the safeties off.

As far as I’m aware, Windows doesn’t have anything quite like services on macOS and probably can’t because Windows apps, even those that are first-party, are built with a menagerie of different UI toolkits which means there are no universal hooks for something like services to use.

The reason macOS can do this is because a large majority of apps are either native AppKit or otherwise hook into the system text facilities (which is why text services work in text fields in Chrome and Firefox for example).

Simply put, this chunk of the electorate doesn’t have any kind of grasp on the workings of government. As you say, their motivations for voting are simplistic and difficult for campaigns to reason about because they’re so particular to each individual.

Part of the reason why political media has seen such a decline in quality is because of that fundamental lack of understanding by the people. Neutral nuanced analysis doesn’t resonate because that’s some combination of too incomprehensible and not entertaining enough, which has led to the media landscape we have now where it’s turned to the televised version of junk food: hyper-processed with lots of salt and sugar and practically zero nutritional value.

That said, to some degree I don’t place fault on the people for this. A lot of it comes down to inadequacies in the education system when it comes to civics, wherein young people are not well equipped to become highly functional, fully conscious voting adults.

Works for images in Preview and even in Safari too. Super handy.

Coda’s successor Nova[0] continues the tradition.

[0]: https://nova.app/

Figma to me feels geared toward collaborative prototyping specifically. It’s kinda clunky and awkward for creation of graphical assets, which is where I find Sketch a lot nicer.

I dunno, I'd be more inclined to subscribe to a version of Photoshop CS1/CS2 that runs on modern operating systems where all development effort goes into fixing bugs and improving performance instead of something like current Photoshop CC, where the focus is on gee-whiz gimmicky features. Plugins can fill in for the gee-whiz stuff without turning the core app into a cosmically bloated mess.

The no-subscription aspect is a huge differentiator IMO, and depending on situation is even worth trading off features. Losing access to your work because you stopped your Adobe subscription sucks, as does the eventual premium over single-purchase.

It would be nice. Similarly have a 5950X/3080Ti tower and it’s a great machine, but if it were an option for it to be as small and low-noise as the new Mini (or even the previous mini or Studio), I’d happily take it.

I'm just speaking from personal experience. That example was real, Firefox did not work with hardware accelerated video decode out of the box for me under Fedora, which was pretty high impact with that machine being used for studying. I got it working and it's kept working since, but like I said, it took some tinkering.

macOS has its own oddities of course, but they don't impede such basic usage as video playback.

Even on the machines most well-supported by Linux, which are Intel x86 PCs with only integrated graphics and Intel wifi/bluetooth, there are still issues that need to be tinkered away like getting hardware-accelerated video decoding working in Firefox (important for keeping heat and power consumption down on laptops).

I keep around a Linux laptop and it's improved immensely in the past several years, but the experience still has rough edges to smooth out.

Looks like the button is probably accessible without picking the machine up thanks to the outer edges being raised enough to fit a finger underneath. If that's the case, I don't really see an issue, and if anything it's preferable since the old position was easy to accidentally press when plugging things in.

Most people probably leave their macs running all the time anyway, making the button infrequently used.

System Profiler labels those in my CalDigit TS4 as hubs, but it's entirely possible that's not accurate.

This is something I have a difficult time agreeing on. I expect a certain level of information density and configurability in desktop UIs, which shoehorned mobile-style UIs don't do well to provide. Deep modality is also a peeve; on desktop there's often no benefit to burying things in mulitple layers of modals — within reason, the most important things should never be more than one click away and great consideration should be put into putting upwards of 2 clicks between the user and their destination.

That said, I do think it's fine to have a simplified mobile-ish UI as an option, but it shouldn't come at the cost of more classical desktop style layouts for those who can leverage them well.

As a sidenote, this is part of why apps like the mac version of Apple Mail and Thunderbird have a considerable number of hardcore adherents, particularly among power users.

Same. This utility is also multiplied by having a separate set of virtual desktops on each display, which lets one create sets of windows/apps that can be mix-matched between screens, reducing the amount of window-shuffling to almost nothing after initial setup.

This is only possible under macOS and Linux, unfortunately. On Windows virtual desktops are still kind of a weird hack that spans one desktop across all monitors.

Depends on what's being developed, I guess. No tables/trees is probably ok for a lot of lighter end-user sorts of apps but doing without them for many desktop-first apps and utilities would be rough. Desktop file managers, media library apps, and email apps for example would be quite a lot less useful without multi-column tables at the minimum.

Sadly it's been common for USB hubs to be dodgy ever since the advent of USB 3. I rarely had trouble out of 1.x and 2.x hubs, but 3.x+ hubs are consistently trouble. The only ones that haven't been problematic are those integrated into Thunderbolt docks, probably because those undergo more stringent certifications.

It’s not that I limit myself to standard widgets, it’s more that the toolkits I use have a full enough complement of standard widgets that any custom needs are easily met by tweaking one of those.

In UIKit for instance I typically build custom buttons by subclassing UIControl, which gives a nice “blank slate” control that has all the basics of interaction covered without the specifics of UIButton. It’s easy to build a custom button that’s as well-behaved as a standard UIButton that way.

Depending on widgets external to the toolkit is a no-go for me. It unnecessarily bloats dependencies and there’s a high risk of the widget eventually being abandoned.

Thankfully, I’ve not run into that issue, at least not with any frequency. Might’ve happened once in a year and change, and I can’t remember clearly if even that actually happened.

For React Native it’s common for navigation to be weird compared to UIKit/SwiftUI apps. Also common for things like padding/margins to be off since standard layout facilities aren’t being used, and devs of RN apps will often visually customize controls (web style) that native devs don’t.

For Flutter, the most visually obvious thing (aside from usually using Material Design) is that its animation curves are all totally different from those of UIKit/SwiftUI and interact with gestures differently. The Cupertino theme is a poor facsimile of UIKit and lands squarely in the uncanny valley, which is arguably worse than Material Design. Flutter on iOS also tends to hitch where UIKit/SwiftUI don’t.

I can’t imagine using Flutter for desktop development if only because like most newer UI frameworks, it’s mobile focused and doesn’t come with important desktop widgets like tableviews/datagrids and treeviews.