> Writing GUIs for the Linux desktop is also a terrible experience.
I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want.
Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free.
I've never tried Qt. The applications that use it always seem off to me.
As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.
OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades.
Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.
[0] Petition to rename ActiveX to WebOLE
[1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.
9front can mount old DOC/XLS documents as OLE 'filesystems' first and then extract the tables/text from them.
As for sandboxing, 9front/plan9 uses namespaces, but shared directories exist, of course. That's the point on computing, the user will want to bridge data in one way or another. Be with pipes, with filesystems/clipboard (or a directory acting as a clipboard with objects, which would be the same in the end).
> As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.
Oops, you are right about COM. I got them mixed up because I was thinking of the integration in WordPad.
> Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.
Mac apps are Mac native because the APIs are amazing and the ROI can be really really good. It takes so much effort to do the same from scratch, especially cross-platform, that, you're right, I can smell anything written in Qt (because the hitboxes and layout are off) or GTK (because the widget rendering is off).
With that said though, wxWidgets seems to translate EXTREMELY well to macOS, though last I used it, it didn't have good support for Mojave's dark mode. Maybe support is better nowadays. For example, Audacity appears to me as just a crammed Mac-native app rather than blatant use of a cross-platform toolkit, and wxPython used well can be completely mistaken for fully native.
wxWidgets calls the underlying native controls directly; Qt uses it to inform how to render but still does its own thing, at least according to a discussion I had with a Qt engineer some years back.
(I am open to being corrected)
wxWidgets has properly supported dark mode for a bit now.
What's doubly-insulting about Liquid Glass is that Windows Vista did the glass thing better. Aero rivaled mid-2000s Aqua in design chops, and in some ways did a better job of showing off what GPU compositing could do. But most importantly Microsoft actually understood that text on glass needs loads of background protection, damn it.
That's a quote from Steve Jobs about how basically all of their competition (except Google) had made the mistake of trying to ship desktop software on phones. The problem with the stylus is that it's a hardware workaround for a software problem: the sort of cost-reduced engineering you get when a company wants to "have a mobile strategy" without actually putting in the time and effort to make something good.
The Magic Mouse is the exact same kind of "we couldn't care less" cost-reduction. The charging port is on the bottom because that's the only place you can put a charging port with the existing all-glass design. Because they re-used an existing design intended for removable batteries. This is such an uncharacteristically un-Apple move, and one so obviously detrimental to the design of the device, that people (including myself) actually psyopped themselves into thinking Apple had deliberately designed the mouse to enforce wireless usage.
And, to be clear, Apple has never done that.
All their other peripherals with rechargeable batteries in them will let you use them fully wired if you plug them in. In fact, if you somehow engineered a way to move the charging port somewhere less stupid, the Magic Mouse probably would work plugged-in, too.
If you see a charging port on the bottom, they blew it.
The California bill basically says any OS with an app store needs to collect an age signal and provide age bucketing to an app store (presumably even third-party ones, but notably NOT extension stores) so it can forward that information onto developers in that store.
There's no further elaboration on what age signals are preferred, so my assumption is that a DoB field in the user profile and a system service to request the age bucket is good enough. It's absolutely silly, but DB48X could implement that.
There's a related question of who is actually liable under this law - it seems written to target just Apple, Google, and Microsoft; and it only makes sense in the context of consumer electronics. Like, how does this work with enterprise systems? Servers? Is IBM going to have to rush out a patch for z/VM to ask the system administrator what their date of birth is?
A client side option to force https might still be useful though. But I can imagine at least some enterprise webapp that would die horribly if you tried this.
Half the process of jailbreaking electronics involves reverse-engineering. There's some promising work in that direction, but reverse-engineering is still not AI's strong suit.
Also, you'll actually need to hook up Claude to all the debug interfaces and pins present on the chip you're trying to break.
Also also, if this worked at all the feds would put a gun to Anthropic's head to make Claude refuse to do anything that might break DMCA 1201.
Alternatively: the companies at the top paid the necessary bribes (e.g. $100k H-1B sponsorships) and got to continue on with business as usual. The people at the bottom are the ones who can't pay the bribe and are thus hurting.
I would love to know what kind of ascetic mental training you have to do to get your Facebook feed to just send you actual people you know and not... well, the slop trough.
As an American I also have not gone to any of those restaurants.
The thing is, America is the China of food[0]: we make shittons of unsafe, dangerous product and foist it onto the market by burying the market's pricing mechanism under a mountain of garbage until nobody else can compete and we dictate the price.
People will note that China makes plenty of safe, normal products too. The same applies to American agriculture, but that doesn't matter. The problem is mainly that the industry has absolutely no standards. If they can go a few cents cheaper, they will.
[0] And, prior to this century, we were also China in general - a lot of our manufacturing was stolen from Britain and ran for far cheaper.
Kids are singing mandatory pledges of allegiance in school, but the government itself doesn’t want to give anything to gain their trust. They’re even rebooting unhealthy coal plants. They don’t care about any of you.
What I find most interesting about the USA is the variety; yes, there are low-cost (often unhealthy) options, but there are also a wide variety of wonderful restaurants which are not pinching pennies on their costs, even amongst national chains.
I've found the DX for GTK to be at least tolerable. Not fantastic, but I can at least look at a particular API, guess how the C-based GObject code gets translated by my language bindings of choice, and be correct more often than not. The documentation ranges from serviceable to incomplete, but I can at least find enough discussion online about it to get it to do what I want.
Also, GTK apparently ships with a built-in inspector tool now. Ctrl-Shift-I in basically any GTK app opens it. That alone is extremely useful, and you basically have to do nothing to get it. It's free.
I've never tried Qt. The applications that use it always seem off to me.
As for OLE, you're actually thinking of COM, not OLE. They were co-developed together: COM is a cross-language object system (like GObject), while OLE is a set of COM interfaces for embedding documents in other arbitrary documents. Like, if you want to put a spreadsheet into a Word document, OLE is the way you have to do that. Microsoft even built much of IE[0] on top of OLE to serve as its extension mechanism.
OLE is dead because its use case died. Compound documents as a concept don't really work in the modern era where everything is same-origin or container sandboxed. But COM is still alive and well. It's the glue that holds Windows together - even the Windows desktop shell. All the extension interfaces are just COM. The only difference is that now they started packaging COM objects and interfaces inside of .NET assemblies and calling it "WinRT". But it's the same underlying classes. If you use, say, the Rust windows crate, you're installing a bunch of language bindings built from WinRT metadata that, among other things, call into COM classes that have been there for decades.
Mac apps are Mac native because Apple gives enough of a shit about being visually consistent that anyone using a cross-platform widget toolkit is going to look out of place. Windows abandoned the concept of a unified visual identity when Windows 8 decided to introduce an entirely new visual design built around an entirely new[1] widget toolkit, with no consideration of how you'd apply any of that to apps using USER.dll/Common Controls. As it stands today, Windows does not have a good answer to "what widget toolkit do I use to write my app", and even Microsoft's own software teams either write their own toolkits or just use Electron.
[0] Petition to rename ActiveX to WebOLE
[1] OK, yes, XAML existed in the Vista era, but that was .NET only, and XAML apps didn't look meaningfully different from ones building their own USER.dll window classes like it's 1993.
reply