Skip to content

Fix color profiles being assigned to screens by indexes

Agata Cacko requested to merge tymond/krita:tiar/fix_bug412943_assign_profiles_to_displays into master

Before this commit, Krita assigned color profiles to screens based on screen indexes, which apparently can change (see the bug report). This commit introduces "screen string identifier" which is a concatenation of multiple screen properties like manufacturer, serial number, resolution etc. (Note that especially on Windows, any of those properties might be empty strings).

BUG:407498 CCBUG:412608 CCBUG:412943

From the user perspective:

Every screen is assigned a string that contains this info: manufacturer, model, serial number, resolution, dpi (physical, then logical) and scale. Note that any screen might have any of the three first pieces of information missing. If all three are missing, the screen string identifier is empty (because I thought it would be scary to assign profiles only on resolution, dpi and scale). Configuration tries to find the profile for a screen identifier, if there is none in the configuration file, then it tries to find the profile for the screen index (the old behaviour).

So, it should cause any issues for existing users, and it should remember from then on always the same profile for the same screen (note that at least on my system the serial number is missing for my screen, so the identifier is only based on manufacturer and model...).

I considered adding a "position" to it too but then a case of someone plugging in and unplugging a display would destroy whole structure, so, I dunno...

Test Plan

It would be best if someone with multiple screens that can reproduce the problem could test it...

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Edited by Agata Cacko

Merge request reports