Inside Configure Icons and Toolbars popup menu, change some value in combobox, hit apply, then defaults, values inside combobx should be restored
Diff Detail
Diff Detail
- Repository
- R119 Plasma Desktop
- Lint
Lint Skipped - Unit
Unit Tests Skipped - Build Status
Buildable 18171 Build 18189: arc lint + arc unit
| kcms/style/package/contents/ui/EffectSettingsPopup.qml | ||
|---|---|---|
| 77 | To de-duplicate a bit, because now that's 4 times (almost) the same piece of code. What about having a function resetIndex() declared in that combo and another one in the other combobox which would do the currentIndex + findIndex dance. This way in both the code would become in both cases: currentIndex: resetIndex()
...
onFooStyleChanged: fooStyleCombo.resetIndex() | |
Comment Actions
Hm I think qqc2-desktop-style breaks the binding on currentIndex, otherwise this would not be neccessary...
Comment Actions
AFAICT it won't be pretty though. :-)
I think it's pretty straightforward
1.) the delegate must not explicitly set a currentIndex because Qt does it for us, see D18299
2.) the wheel handler must be changed to call decrementCurrentIndex() and incrementCurrentIndex() (hopefully they wrap...) instead of changing the index manually, so it doesn't break the binding.
Comment Actions
Ah somehow I thought we had a third more "clever" case of currentIndex moving. Then indeed if that's just those two we should be fine.
Comment Actions
Ah somehow I thought we had a third more "clever" case of currentIndex moving.
Heh, yea, there's also some more elaborate "change index while moving the mouse" going on :(
So best hack would be to have a c++ thing that sets the property without going through QML's binding system :D
Comment Actions
Style wise, functions come before children objects. Other than that looks good to me.
Through Kai comments, the question also becomes, wouldn't it be better to fix the root cause? It's likely we'll encounter that ComboBox breakage at other places.