HN user
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.
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.
[1] https://stevenvanbael.com/open-calendar-task-space-is-a-mess
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.
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)
https://gtk-rs.org/gtk4-rs/stable/latest/book/composite_temp...
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.
https://developer.gnome.org/documentation/tutorials/save-sta...
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.
What is the problem with libadwaita?
GTK has bindings to modern languages. The gtk-rs project is actively working on Rust bindings. I'm personally working with some others on Kotlin Native bindings and I know a new JVM effort is in progress using the new JVM FFI capabilities.
Check out the gtk-rs project which provides the Rust bindings.
For base packages like desktop environments, tools, libraries, popular applications, etc, yes. But I don't think they should be responsible for every end-user third party application. It's a massive waste of time for everyone involved.
They solve the problem of being able to run software against a known set of dependencies instead of depending on the versions that come with the distro. Older packages can still run even when the dependency version the distro provides has changed in a breaking way (as parent suggests), but also the other way, new packages can ship features using newer dependency versions that the distro might not have yet.
That's kinda what the distros ARE
For the base system and libraries, yes. But why should the distro maintainers be burdened with additional work for every possible enduser application out there? If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository.
Maybe a far-fetched analogy, but imagine if browser maintainers have to perform additional work every time a new website launches before it is available to its users.
Also, in this system, the application developer has a lot of extra work for making the application run and build against older versions of its dependencies. If I want to make my app available for Ubuntu 22.04 LTS which has libadwaita 1.1, I cannot use any of the new widgets in libadwaita 1.2 (released 6 months ago) or 1.3 (released earlier this month). I can use those widgets but I'll have to write ifdefs and provide fallback behavior/widgets when building/running against these older versions. I will also have to manually track the various distro versions to detect when I can remove the fallbacks from my codebase.
This is what Flatpak is for. Using Flatpak I can target a specific GNOME SDK version and make use of all the new code immediately, without having to write fallbacks. The downside is that when a user downloads my application through Flathub or another Flatpak repository, it might have to download the additional libraries as well, but they will be the correct versions and they won't be downloaded if that SDK is already available due to other Flatpak applications already installed.
Essentially, something like Flatpak is a middle-ground solution that trades of some disk space for the benefit of less work for distro maintainers (so they can focus on core packages) and less work for application developers (that can use more recent dependency versions and don't have to worry about the versions in other distro's)
The problem with that model is that it puts the burden on the distro maintainers to package every possible application for their distro. And application developers have to essentially wait for each distro to repackage their app before it becomes available on that distro. Or start messing with alternate repositories for each distro they want to support.
The old model works for established software, but breaks down a little now that it becomes easier to write software applications.
Personally I use my distro packages for foundational stuff (DE, systemd, tools and utilities) but I use an alternative package manager (flatpak) for most other applications.
What Flatpak, Snap and AppImage try to achieve is to limit the packaging burden for both distro maintainers and application developers, so that end-user applications can become immediately available on a wide variety of distros.
How would that work for deprecations and new API introductions? GNOME is built on top of glib/gobject/gtk and a host of other libraries which all have to be ABI-compatible in some way. And GNOME itself is used as a base platform for applications.
Having a predictable versioning scheme helps limit the number of releases for downstream application maintenance work. You can't expect applications to have the full git tree available at build or runtime to make some features conditionally available.
I am currently working on kotlin native bindings for the whole gtk/gobject/glib stack and with a small DSL/fluent api layer on top, building UI's by composing Widgets without XML is not that complicated anymore.
What do you mean with KVM? A Kotlin-specific VM? I don't see the need for that as Kotlin the language is rapidly evolving into a higher level language that runs on top of JVM, Android, web and native platforms (iOS, MacOS, windows, Linux)