D3805: Per-activity favorites (Final?)

[Eike Hein]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170308/1660355d/attachment.html>