"Friday 08:00 at my location" is not necessarily the same as "Friday 08:00 London time" is not necessarily the same as "Friday 08:00 UTC+1", but it's very difficult to ask the user which of these they mean in a way they'll understand.
I (very occasionally) work on some software that schedules web content to appear at a certain future time. We had a bug once where during summer, an editor had scheduled an item to appear a few weeks in the future, at 09:00. We displayed this time back to them in our current local timezone (but presumably stored it as UTC), and it looked correct. When that scheduled date came, our timezone had reverted to winter time, and the content appeared an hour late.
We should have displayed the scheduled time in "what the local timezone would be at the scheduled time", or stored the time with a timezone expressed as a location rather than a UTC offset.
> Many games will allow users to do something advantageous by watching an ad.
That's… horrifying.
Why would you want to play a game that treats you like that? I mean, is it fun? I suppose some people must enjoy window-shopping, and I guess this is like that, but… I just can't imagine hoping to see an advert — it feels really manipulative and sinister.
> Does GTK4 provide any viable model of development if one doesn't want to target GNOME or elementary?
It's possible to make apps using GTK3 without libhandy, so I don't see why you couldn't make apps using GTK4 without libadwaita.
Technically, libadwaita is just a bunch of widgets. Apparently it's a very useful bunch of widgets.
> Even LibreOffice has now decided to use libadwaita. Does that mean LibreOffice's GTK version is only intended for GNOME?
I guess so. Either that, or they're intending to use libadwaita in an “off-label” way.
> If yes, GTK4 is basically a toolkit for GNOME masquerading as a general purpose toolkit.
The whole reason libadwaita's widgets are not just part of GTK is so that GTK doesn't have to cater to GNOME, and can be a more general-purpose toolkit. Libadwaita 1.0 was just released last month, so presumably it will take some time for that to come to fruition.
Who's “product management” in this context? Most of these apps are just made by one person.
Again, this letter isn't about users making their desktop nice or ugly; it's about distros applying stylesheets to apps without checking whether the app remains usable, and leading users to expect that this is the app developer's responsibility.
> Why is is so freaking hard to install an app on Linux (Ubuntu)? There's nothing in the software center
If I may also be opinionated… :)
IMO Ubuntu is not very good at curating their repo and presenting it in their Software centre.
GNOME Software is designed to only show graphical desktop apps that include enough metadata. Ubuntu modifies their version of Software to also show non-graphical apps, (including anything packaged as a Snap).
Fedora doesn't make this modification and as a result, Software has less stuff, but a greater wheat to chaff ratio.
Fedora's repos are almost as full of stuff as Ubuntu's, and that's still available through the command line for those who want it; but the more-prominent user experience is less frustrating.
Ubuntu is catering for IoT developers who want to use technical Snaps easily, which is fair enough, but not my use-case. Fedora is catering for a more general-purpose workstation OS, which is my use-case.
> I want a file I can double-click and end up with a launchable icon representing that app in my dock later. I would also like to be able to update that app easily in the future.
A .flatpakref file and GNOME Software does that. This works on pretty much every distro except Ubuntu :) because Ubuntu's modified version of Software doesn't include flatpak support.
In Fedora, I can open a .flatpakref file, which opens Software showing the app's details; I click Install; I have a launcher in the app grid. Software updates the app automatically in the background (unless I switch that off in its preferences).
I'm not saying that Ubuntu is bad here! I'm saying it's coffee; Fedora is tea; I prefer tea, and maybe you would too :)
> libadwaita is in a "functional" release state, but still lacks support for custom stylesheets,
Libadwaita is an implementation of GNOME's design, analogous to libgranite in elementary OS. This includes the visual design. GNOME only has one style, Adwaita (which means “the only one”!).
If you don't want to use GNOME's design, you don't want to use libadwaita.
> basic desktop integration on non-GNOME desktops
Libadwaita is the library you use when you're targetting GNOME.
If you want to target something other than GNOME, you don't want to use libadwaita.
Libadwaita isn't trying to be a general-purpose library for making apps that feel integrated on any platform. I don't think it's reasonable to criticise it for not being something it's not trying to be. It's like objecting that a dog doesn't meow :)
> and has it's own litany of bugs that accompany it.
That's pretty much my use-case too. I want my laptop, but smaller :)
Primarily, I want software I can trust, because I trust that the developers' motives are aligned with my own: a useful tool that I'm in control of.
In my experience, most Free software fits that bill; whereas most proprietary software seems more interested in persuading me to buy something or sign up for something that I don't want. (Most, not all; I can think of counterexamples.)
Bluntly, Free software is usually much less full of skeevy bullshit.
I (very occasionally) work on some software that schedules web content to appear at a certain future time. We had a bug once where during summer, an editor had scheduled an item to appear a few weeks in the future, at 09:00. We displayed this time back to them in our current local timezone (but presumably stored it as UTC), and it looked correct. When that scheduled date came, our timezone had reverted to winter time, and the content appeared an hour late.
We should have displayed the scheduled time in "what the local timezone would be at the scheduled time", or stored the time with a timezone expressed as a location rather than a UTC offset.