Respect label colours

[keunes]

• I confirm that I have searched the issue tracker

Describe the feature

When setting 'Color labels in lists' is enabled, use the label colours as they've been set on the website (with some processing to ensure minimum contrast with the label text).

Additional context

Label colours carry meaning; they indicate their type or importance. The label 'critical' got a cool blue in the app, while on the site it's fire brigade red 🚒

Declaration

• I have carefully read and agree to follow the contribution guidelines.

[mmarif4u]

Thanks.

If you have noticed in the settings you will see "Color labels in lists (uses generated colors)", note the 'uses generated colors'. This is by design and the lack of GitLab API providing colors with the labels.

Technically possible but extremely expensive to do this. Imagine you have opened issues on different projects, take the example of GitLab, they have more than 500 labels. If you call the paginated labels API for this you will need 10 rounds just to get the colors for each label. Now think, is this really worth it? To me no.
Some screens show issues/mr from everywhere. For one issue/mr labels to do this is overkill.

So if you don't like the colors and it does not match, you can switch it off, it will show you just the labels after that. If still not a thing for you, completely switch it off with the other switch. That is the reason these options are provided in case users dont like it they can switch it off.

Moving forward, I will think if this should be disabled by default to avoid confusions.

[keunes]

Thanks for the quick reply :-)

If you have noticed in the settings you will see "Color labels in lists (uses generated colors)", note the 'uses generated colors'.
...
So if you don't like the colors and it does not match, you can switch it off, it will show you just the labels after that.

Sorry this wasn't clear from my request. I did notice, and I did use these settings 😉

What made me write was the following: exploring the app I saw that it is possible to get the label colours (comparing the app and gitlab directly, the colours match):

I get that this app screenshot is from a particular screen, with a particular API call (dedicated to getting label information), though.

take the example of GitLab, they have more than 500 labels. If you call the paginated labels API for this you will need 10 rounds just to get the colors for each label. Now think, is this really worth it? To me no.
Some screens show issues/mr from everywhere. For one issue/mr labels to do this is overkill.

To start: the Gitlab project has a rediculous number of labels. I see it even has 5k of them.

However, whether it's worth it, I think depends a bit on the app's main audience:

• People who report bugs and make feature requests to a large number of projects. They are more likely to see a wide range of labels only few times. In this case it's indeed probably not worth it.
• People who make recurring contributions to a couple of projects. They are more likely to see the same set of labels multiple times. In this case, it might actually be worth it.

Based on the value your app provides (and how I've used the GitHub app for quite some time now as core contributor to a project), I would assume it's mainly the latter).

A key aspect here I think is also caching: I suppose that's already happening for some data. It helps make the relatively expensive roundtrips paletable. This can happen in the background, and could be limited to the groups and projects you are member or and have liked (keeping the occasional one-off label without background).

the lack of GitLab API providing colors with the labels

If we were to make this request upstream, would it have to be here? https://gitlab.com/gitlab-org/api/client-go/-/work_items

That is the reason these options are provided in case users dont like it they can switch it off.

A bit of a 'PS' - not really key to the discussion - but I think that having no colour coding is better than having random colours. Disabling this by default is probably a good idea. Activating it IMHO introduces inconsistency while not providing much value. Considering also this great piece, I doubt that it's even worth a setting, and I would just remove it :-).

[mmarif4u]

I get that this app screenshot is from a particular screen, with a particular API call (dedicated to getting label information), though.

Exactly, app shows the labels list itself and in issue/mr screens the correct colors as they are provided by the API. But when it comes to other endpoints, example issues, it only provides labels and no other information.

Normal response:

{
  "id": 9,
  "name": "Feature Idea",
  "color": "#FFA500",
  "text_color" : "#FFFFFF",
  "description": "Describes new ideas",
  "description_html": "Describes new ideas",
  "open_issues_count": 0,
  "closed_issues_count": 0,
  "open_merge_requests_count": 0,
  "subscribed": false,
  "archived": false
}

Issues response objects:

"labels" : ["foo", "bar"],

If we were to make this request upstream, would it have to be here? https://gitlab.com/gitlab-org/api/client-go/-/work_items

I am not sure, as GitLab is a mess.

Activating it IMHO introduces inconsistency while not providing much value. Considering also this great piece, I doubt that it's even worth a setting, and I would just remove it :-).

Not remove it, but it will be disabled for the colors by default.