3 ms·

The article isn't saying what you think it is saying. Despite the clickbaity opening, this isn't calling for users to stop adjusting the appearance of apps. Th

by shkkmo 3y ago

The article isn't saying what you think it is saying. Despite the clickbaity opening, this isn't calling for users to stop adjusting the appearance of apps. This is about distributors applying system wide default theming to apps without doing any QA and then users being confused when the app doesn't work and doesn't match support documentation. Then these users file bug reports with the app developer rather than with the theme creator. The letter is asking for specific changes so that the app developers don't need to take away user's ability to theme apps by hard coding a stylesheet (since that is the only way to disable automatic distro themes.) > If you like to tinker with your own system, that’s fine with us. However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer. > If you are a distribution who changes the system stylesheet and icons, please reconsider this decision. Changing third-party apps without any QA is reckless, and would be unacceptable on any other platform. Your actions are hurting us app developers a great deal, and are damaging to the entire ecosystem beyond your distribution.

barnabee 3y ago
That's a fair point, but in terms of the right to use and modify free software there's no difference between an end user and a distro creator. What if a user themes their apps a bit and publishes their configs? What if that turns into a distro or a "spin" on another distro with a website? What about things like Regolith [1]? It's a scale not a yes/no question IMO, and these devs are showing hostility to some users, which comes across as an attitude of arrogance and hostility to all users. [1] https://regolith-linux.org/ https://regolith-linux.org/
- imtringued 3y ago
  I don't know anything about regolith but if you are a distro that does theming, then you should do the QA yourself. Yes, that means you have to check every single package every single time it gets updated. When I think about the scale of the problem I get the impression that only a commercial company that earns money would have the resources to do this. There is no way in hell you can get enough volunteers to do this in a reliable way.
- shkkmo 3y ago
  > terms of the right to use and modify free software there's no difference between an end user and a distro creator. Yes, but completely irrelevant as this is not asking for the right to be taken away. > What if a user themes their apps a bit and publishes their configs? Totally fine. Publishing those configs allows users to have a choice and opt in to a config that they know was not QA'd by the developer. > What if that turns into a distro or a "spin" on another distro with a website? If the distro takes on the role of providing QA, documentation and support then there is no issue. The distro could also clearly communicate about the theming so users know why stuff might break. The issue arises when they do none of these things and make the resulting breakage someone else's problem. > It's a scale not a yes/no question IMO, and these devs are showing hostility to some users, which comes across as an attitude of arrogance and hostility to all users. I don't see any hostility. I see a very politely worded request that explains the negative impacts certain behaviors have in certain context.
chriswarbo 3y ago
> This is about distributors applying system wide default theming to apps without doing any QA and then users being confused when the app doesn't work and doesn't match support documentation. Then these users file bug reports with the app developer rather than with the theme creator. If the support documentation only applies for certain themes, then that sure sounds like a bug in the application (or at least its docs)! Likewise, if such requests are a consistent drain on resources (e.g. white text on white background for some custom widget, or whatever) then that also sounds like a noteworthy bug: either in the application (what's it doing wrong compared to unaffected applications that the theme developer tested against?); or the toolkit (why is GTK3+ so fragile in the first place?). Looking at the list of signatories, it seems many of them are applications which embed a giant WebKit frame and cross their fingers (e.g. I use Geary on my Pinephone, which spawns a WebKit process with 100GB virtual RAM; even though I've set the plaintext-only preference!). That could also be the cause of such issues. Or indeed the fault might rest with GTK, for not providing the required functionality, which drove those devs to embed a browser engine instead.

by shkkmo 3y ago

barnabee 3y ago

That's a fair point, but in terms of the right to use and modify free software there's no difference between an end user and a distro creator. What if a user themes their apps a bit and publishes their configs? What if that turns into a distro or a "spin" on another distro with a website? What about things like Regolith [1]? It's a scale not a yes/no question IMO, and these devs are showing hostility to some users, which comes across as an attitude of arrogance and hostility to all users. [1] https://regolith-linux.org/ https://regolith-linux.org/

imtringued 3y ago
I don't know anything about regolith but if you are a distro that does theming, then you should do the QA yourself. Yes, that means you have to check every single package every single time it gets updated. When I think about the scale of the problem I get the impression that only a commercial company that earns money would have the resources to do this. There is no way in hell you can get enough volunteers to do this in a reliable way.
shkkmo 3y ago
> terms of the right to use and modify free software there's no difference between an end user and a distro creator. Yes, but completely irrelevant as this is not asking for the right to be taken away. > What if a user themes their apps a bit and publishes their configs? Totally fine. Publishing those configs allows users to have a choice and opt in to a config that they know was not QA'd by the developer. > What if that turns into a distro or a "spin" on another distro with a website? If the distro takes on the role of providing QA, documentation and support then there is no issue. The distro could also clearly communicate about the theming so users know why stuff might break. The issue arises when they do none of these things and make the resulting breakage someone else's problem. > It's a scale not a yes/no question IMO, and these devs are showing hostility to some users, which comes across as an attitude of arrogance and hostility to all users. I don't see any hostility. I see a very politely worded request that explains the negative impacts certain behaviors have in certain context.

chriswarbo 3y ago

> This is about distributors applying system wide default theming to apps without doing any QA and then users being confused when the app doesn't work and doesn't match support documentation. Then these users file bug reports with the app developer rather than with the theme creator. If the support documentation only applies for certain themes, then that sure sounds like a bug in the application (or at least its docs)! Likewise, if such requests are a consistent drain on resources (e.g. white text on white background for some custom widget, or whatever) then that also sounds like a noteworthy bug: either in the application (what's it doing wrong compared to unaffected applications that the theme developer tested against?); or the toolkit (why is GTK3+ so fragile in the first place?). Looking at the list of signatories, it seems many of them are applications which embed a giant WebKit frame and cross their fingers (e.g. I use Geary on my Pinephone, which spawns a WebKit process with 100GB virtual RAM; even though I've set the plaintext-only preference!). That could also be the cause of such issues. Or indeed the fault might rest with GTK, for not providing the required functionality, which drove those devs to embed a browser engine instead.