Comment 173 for bug 933776

@Doug:

> what's the downside to applying the 0.9.7 commit in precise & also adjusting scale.xml.in to get desired results.

changing default action will only apply for new user since the actions are written in the user's config on first start ... e.g your xml.in change will not apply to existing users and their super-W will start doing the wrong thing

@Matthias:

> I know it's only one issue per bug report. But the underlying problem is a single commit and many bugs are connected to fixing this bug correctly (which has been done for 12.10). This bug produces issues for people who don't even use "scale all". Most corporte users don't use scale all but they do see the flying windows.

Right, and I don't see an issue fixing "the flying windows bug" in a SRU, it seems like we could fix that while keeping the buggy action mapping to not change the super-W behaviour. It's likely that this bug would already have been fixed if there was a ticket tracking the "flying" issue rather than having it discussed in the middle for the 170 comments on the scale behaviour bug...

> The way I see it this bug is unfixable with the only acceptable solution apparently being the introduction of a second hack that will (I think) introduce even more problems for the next dist-upgrade.

we need to have a look on how the bug got fixed in 12.10 and if there is a side effect of making super-W do the wrong thing for upgrades or if that got dealt with in some way (note that this version migrated to gsettings so it gave an opportunity to migrate settings, we can't backport that though)

one other way would be to add some "migration code" to compiz itself, e.g have a one time migration, conditional to a flag that will be written somewhere, which could do something like "if scale for all workspace = super-W; then reset it and reset the "scale for one workspace"" so the new default are picked for users who didn't change the action.