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.
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++.
I'm putting my full comment here to add to the Linux votes since I'm on Linux 80% of my time. Although, I will be given the macOS trial a shot soon as I have an iOS project in the pipeline.
Congrats on launching and sharing! The idea of an integrated all-in-one solution is intriguing to me. So intriguing that over the last 10 years I've started various projects in a similar direction. Mostly focused on integrating calendars (multiple external calendars), tasks and notes within the same app. Lesser focus on web app integration or focus modes.
Combining calendar, tasks en notes within the same app is something that I have not found a good solution for. Most apps focus on only 1 aspect and lack in the others typically leading to having to use a separate app for each aspect, and then losing time and focus by context switching between apps.
A few years ago I wrote about my experiences in this space[1].
I'm curious to see how you have tackled this problem and how the integration between tasks/calendars (and notes?) works.
also: The "Learn more" link near the bottom does not go anywhere.
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.
Since you mentioned Kotlin, you might be interested in the recent gtk-kn effort which provides OOP bindings to GTK in Kotlin Native. (Early preview, not production ready at all)
This example shows off the builder style, but since gtk-rs is built on top of GTK, .ui XML files are also supported. You can edit .ui files using the legacy Glade editor (with a conversion script), the newer (but incomplete) Cambalache project, or by hand (it's not that hard and this seems to be the preferred way nowadays)
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.
As explained in a sibling comment, the toolkit cannot make assumptions about restoring an apps window state to its previous size. Sure it might work for simple hello world apps that always open the main window, but that's not always the case. Sometimes applications have to open a different window or multiple windows on app startup. The only thing the toolkit can reliably do is translate the requested window size when an application opens a window to the DE so that the DE/WM can place it on the screen.
Because of the dynamic nature of opening windows, app developers should have control over storing/restoring the window size. Simple apps might always store the last window size and restore that exact size on startup. Other apps might have to run some logic first before they know how large the window should be, and then request the toolkit to create a window of that size.
It has some logic to it though: An application developer is going to use the toolkit to open one or more windows on startup and the DE/WM has to place those somewhere. The first window opened by the app is not guaranteed to be the main window and it's not guaranteed to always be the same window (sometimes it can immediately open the main app window but other times it might have to show a smaller login window first, or immediately open multiple windows, etc).
- It is the responsibility of the application developer to determine for each window what size it should be depending on the content in the window which can be dynamic. It's also not a fixed thing, but more a hint to the DE. The relevant GTK method is called gtk_widget_set_size_request(width, height) with the focus on "request" (defined in widget but window inherits it). Saving/restoring window state is left to the developer because of the dynamic nature of windows as explained above.
- It is the responsibility of the toolkit to make sure the window gets created and then communicate the requested size to the DE so it can be placed on the screen.
- It is the responsibility of the DE/WM to place this window where the user expects it and depending on the type of DE/WM it might have different behavior. For example a tiling window manager might be configured to always open new windows in the bottom right, or top left, or have config overrides for specific applications to always open floating or maximized.
So yes, the size is the apps problem (because it knows what content is on a specific window and might know about the previous window size from last time), and the position is the DE's responsibility because that can depend on user configuration and the specific DE/WM used. The app cannot make any assumptions about that. It can only request windows with a specific size.
The window state is not the GTK devs problem but an app developer problem. One of the very first topics in the GNOME developer guide is how to use settings to save/restore window state on close/startup.
From what I've seen the .ui format for Gtk3 and Gtk4 are different and Glade does not support Gtk4 Widgets or its additional libraries like libadwaita.
Cambalache is a successor for Glade but it also has issues. It uses its own storage format and you have to export to a .ui file for use in your Gtk4 project, and if you make changes to the UI file it's very difficult or even impossible to use those changes in Cambalache again.
The general consensus on a few of the GNOME-related Matrix channels seems to be writing .ui files by hand.
The discussion is mostly about what a distribution should contain. I don't think a distribution has to contain all the possible software applications in existence.
Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy.
But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications.
However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately.
This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.
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.