hein added a comment.
Second review pass (now based on updated ivan/new-favourites-per-activity branch rather than this code): [03:04] <Sho_> ivan|home: compiler warnings on gcc btw @ fav branch [03:19] <Sho_> ivan|home: I'm still seeing lots of bugs on the branch, e.g. something like this: Switch to my second activity, right-click a Kicker fav and set it from all activities to current activity, switch to first activity - the modified launcher has disappeard, but a launcher that was previously specific to the second activity is now on the first one too (but i can't open its context menu, nothing happens). then when i remove a different launcher and switch to the [03:19] <Sho_> second activity, the borked launcher (the one that shouldn't be on the first activity but now is) shows up twice there [03:19] <Sho_> ivan|home: i'm wondering if it would make the code easier if you used a stacking approach like i do in libtaskmanager - have all favorites in a first source model, then a filter model on top of it to filter out by activity [03:20] <Sho_> in my experience a good way to make models less hairy is to separate concerns by layering them, because then the individual 'passes' are simpler to reason about and individually testable [03:21] <Sho_> the onion layer approach has worked out really well in libtm (aside from some side-effects layer-punching bugs i introduced dumbly that had to be shaken out) REVISION DETAIL https://phabricator.kde.org/D3805 To: ivan, mart, hein Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
