4 ms·

Would you consider revising this opinion if I showed you it was based on incorrect information? >Nothing is less attractive to a user than opening an app to fi

Would you consider revising this opinion if I showed you it was based on incorrect information? >Nothing is less attractive to a user than opening an app to find the ugly Adwaita interface instead of their distro's choice This is by design and is not fixable in any distro with any packaging system and highlights an underlying problem with any theming. Avoiding flatpak sadly will not fix it :( The only choices really are to disable themes, or patch/remove the package when it breaks with some theme. The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme, the second it seems is what distributions usually do. >Does your app use MPRIS? Good luck getting it working! This should be really easy to fix, all you have to do is white list the d-bus path for it. You should consider reporting that as a bug to the flatpak packager also. >You want configuration files in sane locations? How about we make it a pain in the ass to access your own files instead. Huh? The config files are just stored in ~/.var/app/. It's not a pain in the ass to access them at all.

smoldesu 5y ago
> Would you consider revising this opinion if I showed you it was based on incorrect information? Maybe! Let's see how much of it I agree with, first: > Avoiding flatpak sadly will not fix it Werks on my machine. All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution. > The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme They don't need to do this to prevent breakage. GTK has always had fallback stylesheets for this exact purpose, Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws. > This should be really easy to fix, all you have to do is white list the d-bus path for it. That's more work than I have to do on every other version of every package I use > You should consider reporting that as a bug to the flatpak packager also. Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? That alone is enough to disqualify Flatpak, because it's really just "another competing standard" a-la XKCD. > Huh? The config files are just stored in ~/.var/app/. Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!
- BrightGlow 5y ago
  I don't really want to argue with you but I think you're still basing this on false information or on misconceptions, I'll try to clear things up. Of course you are free to use or not use whatever packaging solution you want for whatever reason. >All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution. That's great for you, unfortunately this cannot be guaranteed for all combinations of themes and apps. There are "tricks" you can do to get your themes to work in a flatpak such as mounting the theme directory into the container but this would probably be considered an unsupported hack, I wouldn't recommend it. The only way this could ever be supported is if somebody tested your theme with every version of every flatpak app and then filed/fixed bugs everywhere, which is really not a reasonable thing to ask of theme developers so it probably won't ever be supported. >GTK has always had fallback stylesheets for this exact purpose This is not about the fallback style sheet, this problem is specifically about the style sheet used by the app and how it can conflict with the theme. I'm not sure if you're familiar with CSS, but the way it works is that anything from the theme can override things from the fallback style sheet and that could mess things up if the app expects something different to be there. >Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws. Have you read the "stop theming my app" page all the way to the bottom? Please re-read it if you can, it shows examples of how theming is unreliable and can break apps. That's what would be stopping them. Also this wouldn't really be up to "flatpak devs" to handle either, this would be up to the maintainers of the GNOME SDK and app developers. >That's more work than I have to do on every other version of every package I use How? It's a bug, it's not different from any other bug that you would report. Once it's fixed you don't have to worry about it. >Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? No, I've noticed often the flatpak maintainer and your distro maintainer are different people. There isn't any "true binary copy", unless you consider the binaries that are provided by the developer, which you should check which ones those are. They could be flatpak or they could be something else. And actually the sandboxed version should be less likely to break since the dependencies are pinned and there are less moving parts there. >it's really just "another competing standard" a-la XKCD Yes, that's sort of true, you could also use Snaps or AppImage or a similar thing. However these are not the same as distro packages so in that regard they're not "another competing standard". This is a package that you can install on any distro and have a reasonable guarantee that you'll get the exact same version that runs in the exact same environment. >Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff! I don't understand what you mean here. If you're being sarcastic, please don't do that, it doesn't add anything of value to the conversation. These apps are sandboxed, so you probably want them in a separate directory so they don't clobber your home directory. There is no UNIX config directory for sandboxed apps so they had to come up with something new. What exactly is the problem here?

smoldesu 5y ago

> Would you consider revising this opinion if I showed you it was based on incorrect information? Maybe! Let's see how much of it I agree with, first: > Avoiding flatpak sadly will not fix it Werks on my machine. All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution. > The first is what flatpak apps will do because they want to work on any distro regardless if the user has a broken theme They don't need to do this to prevent breakage. GTK has always had fallback stylesheets for this exact purpose, Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws. > This should be really easy to fix, all you have to do is white list the d-bus path for it. That's more work than I have to do on every other version of every package I use > You should consider reporting that as a bug to the flatpak packager also. Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? That alone is enough to disqualify Flatpak, because it's really just "another competing standard" a-la XKCD. > Huh? The config files are just stored in ~/.var/app/. Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff!

BrightGlow 5y ago
I don't really want to argue with you but I think you're still basing this on false information or on misconceptions, I'll try to clear things up. Of course you are free to use or not use whatever packaging solution you want for whatever reason. >All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution. That's great for you, unfortunately this cannot be guaranteed for all combinations of themes and apps. There are "tricks" you can do to get your themes to work in a flatpak such as mounting the theme directory into the container but this would probably be considered an unsupported hack, I wouldn't recommend it. The only way this could ever be supported is if somebody tested your theme with every version of every flatpak app and then filed/fixed bugs everywhere, which is really not a reasonable thing to ask of theme developers so it probably won't ever be supported. >GTK has always had fallback stylesheets for this exact purpose This is not about the fallback style sheet, this problem is specifically about the style sheet used by the app and how it can conflict with the theme. I'm not sure if you're familiar with CSS, but the way it works is that anything from the theme can override things from the fallback style sheet and that could mess things up if the app expects something different to be there. >Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws. Have you read the "stop theming my app" page all the way to the bottom? Please re-read it if you can, it shows examples of how theming is unreliable and can break apps. That's what would be stopping them. Also this wouldn't really be up to "flatpak devs" to handle either, this would be up to the maintainers of the GNOME SDK and app developers. >That's more work than I have to do on every other version of every package I use How? It's a bug, it's not different from any other bug that you would report. Once it's fixed you don't have to worry about it. >Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? No, I've noticed often the flatpak maintainer and your distro maintainer are different people. There isn't any "true binary copy", unless you consider the binaries that are provided by the developer, which you should check which ones those are. They could be flatpak or they could be something else. And actually the sandboxed version should be less likely to break since the dependencies are pinned and there are less moving parts there. >it's really just "another competing standard" a-la XKCD Yes, that's sort of true, you could also use Snaps or AppImage or a similar thing. However these are not the same as distro packages so in that regard they're not "another competing standard". This is a package that you can install on any distro and have a reasonable guarantee that you'll get the exact same version that runs in the exact same environment. >Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff! I don't understand what you mean here. If you're being sarcastic, please don't do that, it doesn't add anything of value to the conversation. These apps are sandboxed, so you probably want them in a separate directory so they don't clobber your home directory. There is no UNIX config directory for sandboxed apps so they had to come up with something new. What exactly is the problem here?