-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add subtitles in preferences #560
Conversation
model: StringList{ | ||
strings [_("Center at maximum Y value"), _("Center at middle coordinate")] | ||
strings [_("Center at maximum Y value"), _("Center at middle X value")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing this we also need to update the key in the gschema as well as add logic in migration.py to handle the changed name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main reason for this is that "Center at middle coordinate" is just long enough that it cuts off the last part of the sentence, usign "X value" instead is consistent with the other option and is a bit shorter. But I think you are correct that this logic should applied in the gschema and migration.py
as well. Should be a bit careful of adding too much overhead to the migration.py
and not change strings when not needed, so I'm open to keeping this string as-is for now and re-evaluate all strings later in a seperate PR before next release.
In this specific case, I just checked, and it seems to work fine without any new logic in migration.py
. When I set it to "center at max Y" in Graphs 1.6, it is still at "center at max Y" in this commit. And when I set it to "center at middle X" in graphs 1.6, it is still at "center at middle X" in this latest commit.
This could be because "enum 0" (center at max Y) is unchanged in string, so that setting will be nicely copied over. And "enum 1" (center at middle X) is the default. So when reverting to this default value with this changing key, it still ends up correctly. I maybe need to think about it to be sure, but I think in this specific case new migration logic would not be necessary.
The problem is that in migrate.py we don't differentiate between string and enum. Simply adding a check of |
Yeah I tend to agree with you about overhead not being the biggest issue probably. In this particular case however, the thing is that the keyfile is only relevant for non-default settings. Values that are not set there, or are wrong, just revert to the default. This means that whenever this key is equal to "Center at middle coordinate", the settings is not copied over due to the surpression of KeyError in this logic:
The The same holds in general. If wrong values are set in the There's a bit of code in |
Adds subtitles to the first two options in the preferences, basically due to comments from @bertob that the options were a bit unclear. https://gitlab.gnome.org/Teams/Circle/-/issues/185
Perhaps the last two also need some slight explanation. They seemed somewhat clear to me (at least "Hide unselected items" seemed OK to me personally), but to a new user they may be a bit unclear at first glance. So I'm open to suggestions to clarify these options somewhat.