Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DataItems of type DTypes.MULTIPLE_CHOICE and DTypes.CHOICE cannot handle duplicate values approprietly #21

Open
3 tasks
vld-codra opened this issue Mar 27, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@vld-codra
Copy link
Collaborator

The DataItem.choices attribute contains a list of tuple containing key value pairs (list[tuple[str, str]] in most cases). When we need a value, we parse this list to find the corresponding key. However, there are some instances where we parse the list and check the values to get the corresponding keys. This is a problem when several keys point to duplicate values (e.g. two projects of the same name) as we never check for duplicate value. This behavior also prevents the addition of new color that would have the same first letter.

The root of the issue is located in the DataItem.from_text, DataItem.to_text and DataItem.from_display.

Proposed improvements/solutions could be:

  • Replace the list of tuples by a dictionnary which would improve readability, ergonomy and (maybe) speed
  • Decoralate the displayed values from the actual values, by example by removing/modifying DataItem.from_display
  • Decorelate the displayed values from the xml values. For example, for a MULTIPLE_CHOICE data item, the method DataItem.to_text is called both to set the display value and the value to write in the XML. This method returns the choices values instead of the keys which forces us to match the values to get back the keys when reopening the XML file.
@dylms
Copy link

dylms commented Dec 9, 2024

Fix : change type to dict, that are more suitable for CHOICE/MULTIPLE_CHOICE structure and allows duplicates values.
Choices made by user stays as unique key lists, as communication with Qt controls via existing properties and cast functions.

PierreRaybaut pushed a commit that referenced this issue Jan 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants