Modern XMPP project discussion - 2026-07-14

cursed

> Every user interface is a composition of widgets and thereby somewhat a custom widget. Themes that change e.g. border styles or padding sizes potentially interfere with how the widget composition works and may break things. There used to be a standard facility to control widget context colors, such that themes could exist in harmony with application programmers. Some ancient outmoded technology from the 80's to some time around 2020. ↺

https://cdn2.nuegia.net/4f3f9c88-36f4-4fe4-bcca-52e97967c7cd/zb2rhjm4ewCznBXqobpuHYd6aS57C8VZHnigdWCr7SEnvvsZK.png

Is it really that crazy to ask of application developers that they follow a user interface standard, when it is the users who are slapped for not preserving the developer's UI? Why do users have to be upstream programmers to control what color shows up on their monitor?

I think that's quite absurd, and for the majority of computer history we had themes, and they were good.

I think going away from that is a critical regression. It robs the user of trivial comforts and enforces the notion that the user is some sort of plebian who can't be trusted with a color slider.

Web browsers do not have such issues because web developers and users are still considered to be the same exact people - injecting a stylesheet isn't a faux pas.

distaza: you're completely ignoring the arguments brought up during the discussion.

Hold on, I'll scroll up. This is just my gut reaction.

Hm. The main argument I see here is 'people complain to dev about a broken application when in reality it is a broken theme'. ✏

cal0pteryx: Is there another argument you would like to mention specifically?

Themes always break, but developers have to give support for broken themes, that's the problem.

I disagree. Employ a bug report checklist. Many applications have checklists such as 'only run on the bleeding edge build of Ubuntu' or 'run with a stock Debian build first'. The bug report checklist is a battle tested standard you can find in many open source projects. Someone ports your program to a distro? Good, they're a downstream now. They can handle their bugs. A similar process can be employed for themes by simply adding the following checkbox: [ ] I reverted my theme settings to Adwaita and the bug still exists. If you still catch strays, be stricter: [ ] I ran this program on a fresh <distro> install and the bug still exists.

Thoughts?

It is an inevitability with any public computer system that a user can, will, and should break the system. It is not a requirement to micromanage the user. Direct them to find the bugs in a fresh operating system. Impose a standard on bug submissions only. And since this is a social issue, you will get retarded bug reports anyway, but then you have a much more solid reason to dismiss them. I do not believe advocating for, or wrestling the theme controls away from a user is a substitute for a solution like the one above, because I personally started my journey into open source to freely customize any part of my computer. I have no intention of giving that control back - I just won't file bug reports unless I know it's not my own fault. :B ✏

Color schemes are perhaps the most trivial and demeaning thing to remove from a user. I can accept the consequences of turning my programs dark green. I have the mental faculty to test breakage by restoring the default theme or testing on a fresh computer. If the rest of society has an issue following those steps, *my* control of *my* computer should not be on the chopping block. I would rather not receive program updates at all. This may seem trivial, but it has an undertone. We're talking about one of the four freedoms here. Trying to shift the expectation such that users can no longer be trusted to change how programs *look* will only make it that much harder to justify users changing how programs *act*.

And if users can't be trusted to change how programs act, they don't need or deserve the right to modify their programs, which is one of the four freedoms of open source.

That's been discussed quite broadly. In my experience as a maintainer, it creates unnecessary work and those bugs are often hard to identify, and that wastes everyone's time. I'm out.

I respect your freedom to choose that, I just disagree.

If you find the programs you maintain useful in whatever state they're in, and you have the ability to maintain them, I'm just a third wheel unless you're actively soliciting my opinion.

I'll maintain my programs to my standards as well.