Add more visuals (colors)

I would like to add more visuals apart from ['muted', 'success', 'warning', 'danger'].
Does anybody knows how to do it?
I think it’s not possible for now, but I would like to push forward so this can be customized. Is faceable? Is at least this feature interesting for anyone else?

This is not doable on purpose. Colors only are not good way to provide information (especially for blind people). So they must come with an extra meaning. So we choose the one available on Bootstrap as base because they represent most common need in general.

I think it would be nice to allow more customization, you could even enable it so that instead of ‘success’ for example you could pass the color code #RRGGBB.

How does it work for accessibility?

From my point of view, it would be a change to allow customization, everyone decides if they want to respect accessibility or not.

Yes, that would be my preference, I don’t want to be attached to some keywords.

Following the same point of view, the best is to don’t have any color available.
The information to decide whether it’s a color or another can be visible, you need fields to compute the pyson so those fields can be shown, for example, with optional columns.
Being realistic, a company can decide if blindness is an important matter for them. If it’s important for the company, I can set for the user preference a selection like vision_defect, which changes the colors used depending on which defect type have that user.

These comments are very disrespectful against a group of people. I cannot support that.

  • Tryton core modules are only using the standard colors mentioned, so modules are done respecting your criteria. But the Tryton as framework from my POV should allow color customization.
  • When I say that a company can decide what to respect or not is real. When you are providing customization, your mission is not to argue against the ethical of the company logic. We know a lot of companies which develop protocols/logics that are not ethical. You can say your opinion to the client about accessibility, but doing a strong no against a customer which have a little company with only 2 employees since 2 decades and no visual impairments is strange. Also, customer can reply:

For now is not a problem color accessibility, but if some day I have someone with visual impairments we will ajust colors for their needs.

  • What is this disrespectful toward a group of people? Let me be populist with: Is someone thinking about buying his own house with full features for a person with mobility reduced? No, you have the framework of the house with the doors heights to allow a chair to go through. But since you don’t have a mobility problem, the stairs to the second floor will be there, and you will not install an elevator, as the ROI is not doable.

  • People with visual impairments are often using other tools such as screen reader, magnifiers and adjustable font sizes, which can provide verbal descriptions of color and other visual elements in a software application. Maybe we could also improve font size selection for them.

  • Software with colors can also provide benefits to people with visual impairments by creating a more intuitive and user-friendly interface. For example, colors can be used to highlight important information, provide visual cues, or indicate the state of an action. This can make the software easier to navigate and use, even for individuals who are blind or have low vision.

Color blindness can be very diverse:

  1. Red-green color blindness is the most common form of color blindness, and affects the ability to distinguish between red and green hues.
  2. Blue-yellow color blindness affects the ability to distinguish between blue and yellow hues.
  3. Total color blindness, also known as achromatopsia, is a rare condition in which individuals are unable to see any colors at all and see only shades of gray.
  • It’s important to note that not all people with color blindness see colors as shades of gray. Some individuals with color blindness are still able to see colors, but may have difficulty distinguishing between certain hues, particularly red and green or blue and yellow.

Let me note that 2 of the actual colors on Tryton for visual are the first common problem (red-danger, green-success) for color blindness. So maybe the important part regarding accessibility should be to allow to customize which colors we want for every user in Tryton, as the problem can be diverse.
Maybe we can change those 4 color keys to 10 selectable colors in the user preferences. Same way as most code editors have default themes with customizable colors.


I do not think it will be any issue to return from server side two pairs of values:

  1. The accessibility key
  2. The color used for such key

We can just have a table to store them like we have for icons with the current defaults registered.

This will allow anyone to register new keys (and colors) and customize the current ones.

Coming back to this after a discussion we had with @ced this Friday we came up with an idea to fix the need of the customization expressed here.

In fact visual is defined as being part of a set of keywords and the client only use those.

If we change a bit the code in order to return css classes in visual instead of one of some strings then people that want to provide some additional customization in their code could just return it in visual and ensure that some CSS is available for the classes they’re using.

I think that if we decide that it’s a good idea then the definition of the tree view should be expanded to add visual on the tree tag (in fact after checking of the rnc it’s already there but I haven’t found where it’s used in the client) because it would allow to define a CSS for a whole line of the tree views.

(And one might wonder if such a use of visual shouldn’t be available also in the form related tags but it could make really really ugly views :smiley:).

And by the way it’s easier in GTK4 than in GTK3 to support this.

1 Like

I’m wondering if it won’t be better to just define a table of visuals like we have for icons.
This will allow to define the classes but also the html colors because IIRC the desktop client has a configurable mapping between visuals and colors.

Default classes may be loaded with an XML file and the system administrator will be able to customize the values if needed by deactivating the records.