Sophie

Sophie

distrib > Mageia > 5 > x86_64 > media > core-release > by-pkgid > 6ee2cbae02a5b0119efff7a8602b3ff6 > files > 112

yakuake-2.9.9-5.mga5.x86_64.rpm


   Yakuake KDE 4 FAQ (Last update: March 7th, 2011)
  ==================================================

Q: The open/retract animation is very jerky for me. Why is that?

A: First of, Yakuake currently employs two entirely different animation
   strategies depending on user settings and the environment it is run
   in. By default, when running in a KDE Plasma workspace v4.6 or newer
   that has OpenGL Desktop Effects (i.e., compositing) and specifically
   the "Slide" effect enabled, Yakuake will ask KDE's window manager to
   perform the animation on its behalf. There are currently no known
   performance problems with this animation strategy.

   When Yakuake is run in an older version of the KDE Plasma workspace,
   a KDE Plasma workspace with Desktop Effects or the "Slide" effect dis-
   abled (or set to use XRender instead of OpenGL), or outside a KDE
   Plasma workspace, it will fall back to the older animation strategy of
   progressively adjusting (growing or shrinking) the window's mask and
   moving the title bar along the mask's lower edge to simulate movement.
   It will also fall back to this strategy when the user explicitly dis-
   ables the window manager-assisted animation strategy in the configura-
   tion dialog.

   This older animation strategy appears to have performance problems
   in combination with older versions of the proprietary nVidia graphics
   driver, especially when the terminal is set to use a bitmap font and
   font anti-aliasing is disabled. Oddly, despite anti-aliasing not
   being applicable to bitmap fonts, enabling anti-aliasing seems to
   improve performance (probably because it changes the driver-internal
   code path for glyph blending or memory management), as does switching
   to a scalable font like DejaVu Sans Mono.

  ------------------------------------------------------------------------

Q: The terminal display corrupts in odd ways when I scroll. Anything I can
   do?

A: This is usually caused by using compositing (aka "Desktop Effects") with
   an older version of the proprietary nVidia graphics driver, which has a
   known rendering bug with Qt 4 scrollviews on an ARGB visual. nVidia
   fixed the problem in version 169.07 of the driver.

   If a fixed driver is not available for your hardware or you are having
   this problem despite not using nVidia hardware or their proprietary dri-
   vers, exporting QT_USE_NATIVE_WINDOWS=1 has been known to help some
   users. This comes at the cost of increasing flickering during window re-
   size operations as it disables the use of windowless widgets in Qt.

  ------------------------------------------------------------------------

Q: Translucent areas of my skin look rather different from how they used
   to look in the KDE 3 version. Why is that?

A: While the KDE 4 incarnation of Yakuake tries hard to preserve compati-
   bility with existing skins, the replacement of pseudo-translucency with
   XComposite translucency results in different blending behavior between
   skin elements and their background. Unfortunately this is outside the
   area of influence of the Yakuake code at this time. Translucent areas
   in skins may have to be adjusted accordingly, or the background tinting
   option in the configuration dialog can be used to compensate.

  ------------------------------------------------------------------------

Q: I am using KWin Desktop Effects and have the "Shadows" option enabled,
   but the Yakuake window does not have a shadow. How come?

A: KWin's Shadow effect currently doesn't paint shadows for shaped windows
   (aka windows with a "mask") for performance reasons. This is unlikely
   to change in the near future. To compensate Yakuake may introduce sup-
   port for shadows in skins in the future, similar to what Plasma already
   does today.