Version: unspecified OS: Linux Using yakuake with KWin's scale-in animation plugin looks ugly. Yakuake doesn't appear from the top of desktop but from center of desktop with both scale-in animation and yakuake's drop-down animation. Reproducible: Always Steps to Reproduce: Enable KWin's scale in plugin Actual Results: Both animations mixed and look ugly. Expected Results: Yakuake should appear only with yakuake's drop-down animation.
Reassigning to kwin as I don't think there's anything I can do about that.
reassigning back ;-P add a property to the window to make it slide like plasma notifcations... (have a look at the slidingpopups effect) Atom atom = XInternAtom( display(), "_KDE_SLIDE", False ); unsigned char dummy = 0; XChangeProperty( display(), rootWindow(), atom, atom, 8, PropModeReplace, &dummy, 1 );
This isn't about using the slide effect - Yakuake already uses the slide effect, but only when built against 4.6 since only that version of the effect takes the required animation duration parameter -, it's about avoiding the scale-in effect when the slide effect isn't being used. Since use of the slide effect is optional in any case (since it performs worse than Yakuake's own animation in some setups), that's not a solution in the medium term. Reassigning back.
It will be difficult to do anything about it till we have a compositing specification. KWin cannot know that Yakuake should not be animated and there is no existing solution for that. Using a proprietary new hint would not help anything as there is still Compiz which would burn down Yakuake. So to me this is a WONTFIX till there is a generic standard and then it's back in Yakuake's hands to add the new flags.
Perhaps you should open a meta-bug in kwin for things related to the compositing spec and add bugs like this as dependency to it, so you'll be able to give advise here once the spec materializes, rather than the bug being forgotten.
The 4.6 solution works fine and ensures that Yakuake is only animated by the slide animation. More cannot be done at the moment
If it's "more cannot be done *at the moment*", RESOLVED LATER would make more sense than RESOLVED WORKSFORME, perhaps? :)