zorr

It probably is. Since they already have a working web app, why would they throw all that away and start a new project from scratch targeting 3 platforms (MacOS, Linux and Windows) and triple the maintenance burden?

I'm assuming they have reworked their current web app into an electron (or similar) desktop application and going forward they can make changes and immediately push out to both web and desktop.

Leading to features like "Karmic Dice" in the recent Baldur's Gate 3

That seems like missing the point of the article. What I understand the author to mean with Dart plan vs Typescript plan is the way these languages approached evolution of the base language (JavaScript).

Dart aimed to replace JavaScript completely and isn’t very compatible with it, leading to issues like not being able to leverage the existing library ecosystem. While the Typescript approach enhances the base language instead of replacing it and is still compatible with existing libraries.

When looking at language adoption, the Typescript approach seems to have worked a lot better than the Dart approach. If it wasn’t for Flutter, Dart would probably be irrelevant by now and Typescript is now pretty much everywhere where JavaScript is.

Another successful-ish example of the Typescript plan is Kotlin, which was originally designed as an improved Java, fully compatible with the existing ecosystem.

So I can see where the author comes from when trying to do the same thing for C++.

When you don’t care about the discussions being in the public record the comments don’t necessarily need to be integrated in the blog.

I have my email on my personal site and when an article reaches the frontpage on HN I usually get some emails related to the post.

How does N relate to the number of parameters that is frequently mentioned?

Imagine your keyboard lagging a few extra ms before the character you typed is visible on the screen.

I have a feeling desktop development is going to slowly revert back to classic OOP paradigms just like the web world detoured from MPA -> SPA -> SPA+SSR -> back to something that looks a lot like MPA again.

Classic toolkits like GTK, Qt, UIKit/AppKit, Swing and JavaFX use OOP to solve some of the problems this article talks about.

However, this OOP model seems to be somewhat incompatible with Rust's strict memory safety rules. At least I think it is because I haven't seen any big efforts for a Rust OOP toolkit like this. Most of the existing Rust toolkits are immediate mode or ECS or something "reactive" that looks like React.

While I understand the idea of moving away from "unsafe" languages like C/C++ to something like Rust, I wonder if Rust is the right language for building UI applications? Maybe a better architecture is to use Rust for the core logic as a library to be consumed by a higher level language that meshes well with these OOP widget tree and event handling paradigms.

Using the Spotify Rest API it is already possible to build nice feature rich Spotify clients for remote players. I don't think there is a supported native playback library? I'm not sure how local playback is implemented in this project.

The main problem I have with the Spotify API is that its remote playback management API is limited/incompatible with some players (Sonos).

One of the things I'm thinking about recently is putting a Mac mini on my desk for occasional iOS development on multiplatform projects (main laptop is Linux) and keep it always running as a CI runner for those projects.

More like an ADHD-sufferer that barely gets anything done

No notifications aside from Signal, some Matrix channels of my OSS project and my work Teams.

All the rest including WhatsApp has notifications disabled. Phone is on DnD most of the time.

I occasionally check HN Frontpage,a local news website and a few selected subreddits and that's about it.

I explained in other siblings already why the toolkit cannot make assumptions about storing and restoring the window size. The app knows about the content and requests one or more windows with a requested size depending on its contents, and it's the OS/DE/WM that has to place it somewhere.

> - Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!

The link I provided documents this exact process in 4 languages including C and JavaScript and all the saving/loading/parsing and even binding the managed settings to the properties of a window is handled for you by the toolkit. It is 1 function call to initialize the settings and 1 function call per setting to bind it to the window property you want to manage. Oh, and these settings can be configured externally with various tools or GUI's as well if you want to.

> - Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.

AFAIK this is not something the app developer has to do and is handled by the DE with maybe a little help from the toolkit.

> - Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!

Nope, an app can only request windows with some requested size, and it's up to the DE/WM to place it. Take tiling window managers for example which might be configured to always open new application bottom right, or top left, or floating or whatever. Sure, an app might dig down into the lower levels to finetune behavior but then the app developer chooses to open this can of worms to make sure it still works with all flavors of DE's/WM's/X11/wayland/etc

> You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.

GTK already has these dependencies and abstracts them for you in higher level API's while still providing access to lower level API's if you choose to use them. (Gdk for displays, Gio for IO and parsing/saving/loading and binding to settings is in Gio as well). Client side decorations is a matter of choosing what base window type you use, so you can have default decorations or start with a blank slate.

I honestly don't know what you expect GTK to do more than it already does.