So, this happens because the different launchers all share the same launcher model (ie the icon backend), which is where the saturation state exists; but the "overlay enabled" & hover states exists on a per launcher basis.
1) When the use cancels a drag, we reset the saturation status to the intended value.
2) However, we do this in both launchers, one of which "overlay enabled" is false, causing the icons to saturate.
3) Which monitor you have the dash open on will give different results. First will leave the icons saturated, second will flicker them as they briefly turn saturated, then desaturated.
Question: Do we not wan the overlay on all monitors if the dash/hud is open?
Either we need to have the hover/overlay state shared between the model, or we need to have icon states (quirks) per launcher, or there needs to be some hacky-jiggery-pokery for checking which monitor we're operating on.
So, this happens because the different launchers all share the same launcher model (ie the icon backend), which is where the saturation state exists; but the "overlay enabled" & hover states exists on a per launcher basis.
1) When the use cancels a drag, we reset the saturation status to the intended value.
2) However, we do this in both launchers, one of which "overlay enabled" is false, causing the icons to saturate.
3) Which monitor you have the dash open on will give different results. First will leave the icons saturated, second will flicker them as they briefly turn saturated, then desaturated.
Question: Do we not wan the overlay on all monitors if the dash/hud is open?
Either we need to have the hover/overlay state shared between the model, or we need to have icon states (quirks) per launcher, or there needs to be some hacky-jiggery- pokery for checking which monitor we're operating on.