Subj. If you turn off and turn on again this effect all starts to work as it should be. Reproducible: Always
sorry, but I do not understand what you mean. Could you please elaborate a little bit more.
Ok, i try explain: in kde 4.11 this - http://storage5.static.itmages.ru/i/13/0816/h_1376645420_5106321_6e4dedd497.png effects affect not only on window, but on kickoff, plasma-calendar, yakuake too. If before they had smoothly appeared, and now they have the animation of 'scaling in'. In pictures - http://storage8.static.itmages.ru/i/13/0816/h_1376646442_1664289_da66fdff72.png - this bug on yakuake. And... i go to systemsettings toggle "scale in" animation to off, and to on again. Result - http://storage4.static.itmages.ru/i/13/0816/h_1376646570_6385145_77a5a970e8.png 'scale in' animation no longer affects on yakuake and plasma's kickoff and calendar as should be...until the next restart kwin. My english is bad ,but I hope that I have explained understandable.
Sounds like a race in the clients, checking for the availability of the feature. They start up and test the property, kwin's compositor is not yet ready, the effects not started, so it's not there. Then kwin compositing is done and the effect sets the property. Then the clients install a hook on the property change - what does no more occure, as it happened before. When you then change effects, the property is withdrawn and set and the clients notice both, thus start using it. It makes sense, because kwin, plasma and yakuake usually start up all together, but it would actually be weird to find the same race in yakuake and plasma (cnp bug?) and also hit it. @dreamsoul14 - Does toggling compositing -Shift+Alt+F12 twice - also "fix" it? - Does this happen on every restart and always for plasma panels AND yakuake, or somtimes only one or the other?
> - Does toggling compositing -Shift+Alt+F12 twice - also "fix" it? No > - Does this happen on every restart and always for plasma panels AND yakuake, or somtimes only one or the other? yes, always when kwin restarting (reboot, restarting X, or just killall kwin && kwin), and yes, for plasma panels and yakuake together always.
At least current yakuake checks the property on every toggle - what makes this one rather weird. When this does NOT work, please run: xprop -root | grep _KDE_SLIDE and xprop | grep _KDE_SLIDE (the cursor will turn into a cross for the second: click the yakuake window) and post the output (if any) Does sliding not happen at all or does it happen alongside fading/scaling? Please also attach the output of "qdbus org.kde.kwin /KWin supportInformation"
> When this does NOT work, please run: > xprop -root | grep _KDE_SLIDE >and > xprop | grep _KDE_SLIDE http://paste.kde.org/p90879423/ > Does sliding not happen at all or does it happen alongside fading/scaling? Sliding effect works for "hiding" yakuake by F12 and for plasma panels too - if press on kickoff menu again for close it - sliding effect works. > Please also attach the output of "qdbus org.kde.kwin /KWin supportInformation" http://paste.kde.org/p6b711e6f/
May fall into categories of bug #321897 where the issue here might be simply the effect order - if the (now scripted) ScaleIn effect would for some reason be loaded before the sliding popup one, the SlidingPopup effect could not occupy the WindowAddedGrabRole before the ScaleIn effect sees it and happily operate on the window.
*** This bug has been marked as a duplicate of bug 336866 ***