The word "candy" doesn't fit our usecase because it means "confections
made with sugar".
"Eye candy" will fit our usecase better because it means "something that
is visually attractive or pleasing".
No Linters Available |
No Unit Test Coverage |
Buildable 1644 | |
Build 1662: arc lint + arc unit |
Wouldn't that break third party effects that have "Candy" in their manifest? Perhaps only change the user-visible string?
Oh, yeah, you're right, it will "break" 3rd-party effects. :(
Perhaps only change the user-visible string?
I'm afraid that by doing that we'll just add more mess to the code. E.g. desktopChanged(uint, uint) has been deprecated for many years and we still have it. So, there's a big chance that '// TODO: Rename to Eye Candy.' comments will be present for many years.
Let's wait for KWin 6 and maybe then rename it.
kcmkwin/kwincompositing/model.cpp | ||
---|---|---|
73–74 | can't we just change this one line without changing the other? |
kcmkwin/kwincompositing/model.cpp | ||
---|---|---|
73–74 | IMHO, if translatedCategories has "Eye Candy", then knownCategories should also have "Eye Candy". |
. E.g. desktopChanged(uint, uint) has been deprecated for many years and we still have it.
Let's wait for KWin 6
FWIW we don't explicitliy offer any guaruntees.
The ABI has jumped 11 times during Plasma 5. We definitely have /some/ API breaks; though that doesn't mean we should remove deprecated things if they don't cause an issue.
kcmkwin/kwincompositing/model.cpp | ||
---|---|---|
73–74 | then do both: first list have: next list have: |
effects/effect_builtins.cpp | ||
---|---|---|
239 | Still not a fan of actually changing the internal settings category. Changing the i18n'd user-visible labels is fine |
effects/effect_builtins.cpp | ||
---|---|---|
239 | I don't like that because we'll be inconsistent if we go that way. |
effects/effect_builtins.cpp | ||
---|---|---|
239 | Just to expand: if the "Candy" category keyword doesn't match the user visible string, then other keywords should be changed, e.g. Appearance -> appearance etc., so there is clear split between keywords and visible user strings. |
Can't we work out some agreement here? "Eye Candy" in an unambiguously better user-visible string than "Candy", and it would be a shame to not change it because of a disagreement that I'm sure we can resolve.