Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are two solutions to this:

1) use offset colours, like specifying to move 10% in Hue off the theme colour.

2) specify all foreground + background colours and admit that this is special and won't conform to any user or distro theming



Number two is the enforced theme I was tslking about. Offset colors can be problematic for a number of reasons. The main one is that you don't know if the color that is generated that way has the right amount of contrast to each of the other colors it appears with and that the end result is something that is visually pleasing.


As an application developer I want for my users a consistent experience, irrelevant of OS or distribution. I understand that.

But, as a user I want for my experience consistent on my os, irrelevant of that different apps are written by different people on different setups. I want consistent icons, I want menus that follow same convention, I want to change text colours and sizes.

The biggest issue is that developers don't want to follow gnome checklist. Instead of that, they hardcode colours and behaviour. They go heavy into 'it works for me'. And then have audacity to complain that world doesn't bend to their will.

Here is a gnome checklist. I wish the open letter stated how their application follows the checklist and was broken by a distribution so that the checklist now includes fails.

https://developer.gnome.org/accessibility-devel-guide/stable...


The way I see it, there are two options here: either require themes to specify colors for many more semantic use cases or give up on themes.

Icon consistency is also just not possible. Any halfway decent application with a properly designed UI will have a set of prominently displayed custon icons for the main commands that make the software what it is. There is no way that these icons can be consistent with whatever random theme you chose to use today.


I have a strong feeling that if custom themes are breaking apps, then those apps are almost certainly in violation of one or more of tables 2-4, 2-5, or 2-6.


Maybe, maybe not. Some apps have no obligation to meet these checklists because they are for tasks that can only be performed by people with no significant visual impairment. I am not claiming that this a common case. But how would e.g. someone with poor eyesight use gimp successfully? Dumb line of business apps that have a simple UI made mostly out of standard widgets have fewer excuses.


As strange as it may seem, blind people can be quite good at resizing images.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: