| Summary: | fade between opacity changes> fade from zero after window move | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Mircea Bardac <contact> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Mircea Bardac
2005-02-19 17:42:28 UTC
can't reproduce there was some error on the opacity change fades in kompmgr, but that should be fixed. do you resolve this bug with the latest kompmgr cvs? Err.. haven't tested the CVS. I use the binary comming in my distro's repos. Might take some time building kcompmgr, mostly because I don't know where to get it. Managed to get it (just kdebase/kwin/kompmgr), but.. it doesn't compile separately... too bad... CVS commit by luebking:
BUGS:99800
fixes problem with missing fade deques on unshadowed windows
M +17 -13 kompmgr.c 1.21
--- kdebase/kwin/kompmgr/kompmgr.c #1.20:1.21
@@ -418,8 +418,8 @@ run_fades (Display *dpy)
w->shadow = None;
w->extents = win_extents(dpy, w);
+ }
/* Must do this last as it might destroy f->w in callbacks */
if (need_dequeue)
dequeue_fade (dpy, f);
- }
determine_mode (dpy, w);
}
@@ -2535,5 +2535,5 @@ main (int argc, char **argv)
}
- fprintf(stderr, "Started");
+ fprintf(stderr, "Started\n");
/* get atoms */
shadowAtom = XInternAtom (dpy, SHADOW_PROP, False);
@@ -2741,8 +2741,8 @@ main (int argc, char **argv)
/* reset mode and redraw window */
win * w = find_win(dpy, ev.xproperty.window);
- unsigned int oldShadowSize = w->shadowSize;
- unsigned int tmp;
if (w)
{
+ unsigned int tmp;
+ unsigned int oldShadowSize = w->shadowSize;
if (ev.xproperty.atom == opacityAtom)
{
@@ -2752,6 +2752,5 @@ main (int argc, char **argv)
if (fadeTrans)
{
- set_fade (dpy, w, w->opacity*1.0/OPAQUE, (tmp*1.0)/OPAQUE,
- fade_out_step, 0, False, True, True, False);
+ set_fade (dpy, w, w->opacity*1.0/OPAQUE, (tmp*1.0)/OPAQUE, fade_out_step, 0, False, False, True, False);
break;
}
@@ -2765,4 +2764,6 @@ main (int argc, char **argv)
break; /*skip if shadow does not change*/
w->shadowSize = tmp;
+/* if (w->isInFade)
+ break;*/
}
if (w->shadow)
@@ -2786,5 +2787,8 @@ main (int argc, char **argv)
default:
if (ev.type == damage_event + XDamageNotify)
+ {
+ /* printf("damaging win: %u\n",ev.xany.window);*/
damage_win (dpy, (XDamageNotifyEvent *) &ev);
+ }
else if (ev.type == shapeEvent)
{
After using the last conditions presented in bug http://bugs.kde.org/show_bug.cgi?id=99841 , I've noticed that fading in (after a window was moved) is not done from 0%, but from inactive% - but I guess the patch above covered this also. Just wanted to add this too, to correct the initial bug description. |