Re: [compiz] Dual-screen compiz mostly working
On Mon, 06 Aug 2007 08:53:13 +0200, Michel Dänzer wrote: >> Option "BackingStore" "true" > This is generally a bad idea, does disabling it make any difference? > >> Option "ExaNoOffscreenPixmaps" "true" > No such option, though Option "FBTexPercent" "100" should have more or > less the same effect as "XaaNoOffscreenPixmaps". I've made these changes with success. Thanks! ~mck -- "All stable processes we shall predict. All unstable processes we shall control." John von Neumann Homepage - www.wever.org | Sesam Search Engine - www.sesam.no ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
>> today, I noticed a problem in focus handling for shaded windows which is
>> pretty easy to reproduce:
>>
>> - Disable "Click to focus"
>> - Shade a window
>> - Hover another window
>> - Hover back to the window frame of the shaded window
>> - Press Ctrl+Alt+S
>>
>> Expected behaviour would be that the shaded window is unshaded. What
>> happens is that the last active window is shaded.
>>
>> I investigated this a bit and found the cause for this behaviour, but
>> wasn't able to work out a proper fix for that:
>> - The function shade() uses d->activeWindow to determine the window to
>> (un)shade via the "window" option.
>> - d->activeWindow is set from the FocusIn event handler, but only if
>> w->managed is set for the window which is hovered or whose frame is
>> hovered
>> - As w->managed is unset in the UnmapNotify handler (and so after a
>> window is shaded), hovering a shaded window frame does not set
>> d->activeWindow to that window.
>>
>> Any idea regarding that one?
> w->managed should not be unset when getting an UnmapNotify event cause
> by shading. The window is still managed by compiz while being shaded.
> w->pendingUnmaps should be greater than 1 when a window is shaded but I
> guess that's broken somehow...
You are right. This also works as intended. I walked a false path there, sorry.
The real problem is that we don't select for FocusChange events for frame
windows and thus never get FocusIn events for them.
Correcting this revealed another problem: The lastFoundWindow variable was (IMO
incorrectly) sometimes also set to frame windows.
The attached patch seems to do the trick - any comments?
Regards,
Danny
diff --git a/src/screen.c b/src/screen.c
index 15458f7..f8bd082 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -2198,7 +2198,12 @@ findWindowAtScreen (CompScreen *s,
for (w = s->windows; w; w = w->next)
if (w->id == id)
- return (lastFoundWindow = w);
+ {
+ /* FIXME: not sure if this is correct */
+ if (w->managed)
+ lastFoundWindow = w;
+ return w;
+ }
}
return 0;
@@ -,7 +2227,7 @@ findTopLevelWindowAtScreen (CompScreen *s,
{
if (w->id == id)
{
- found = (lastFoundWindow = w);
+ found = w;
break;
}
}
@@ -2240,12 +2245,16 @@ findTopLevelWindowAtScreen (CompScreen *s,
for (w = s->windows; w; w = w->next)
if (w->frame == id)
+ {
+ lastFoundWindow = w;
return w;
+ }
}
return NULL;
}
+lastFoundWindow = found;
return found;
}
diff --git a/src/window.c b/src/window.c
index ddfc123..f961b2c 100644
--- a/src/window.c
+++ b/src/window.c
@@ -1083,7 +1083,7 @@ updateFrameWindow (CompWindow *w)
XSetWindowAttributes attr;
XWindowChanges xwc;
- attr.event_mask = 0;
+ attr.event_mask = FocusChangeMask;
attr.override_redirect = TRUE;
w->frame = XCreateWindow (w->screen->display->display,
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Dual-screen compiz mostly working
On Mon, 06 Aug 2007 07:44:20 +, Mick Semb Wever wrote: > I've made these changes with success. Success meaning not breaking anything :-/ no improvement on the dual-screen compiz though... ~mck -- "Work like you don't need the money. Love like you've never been hurt. Dance like nobody's watching." Satchmo Paige Homepage - www.wever.org | Sesam Search Engine - www.sesam.no ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Question about changing default metadata values (--with-default-plugins replacement)
Colin Guthrie <[EMAIL PROTECTED]> writes: > Hi, > > Now that --with-default-plugins has gone in compiz 0.5.1 (git), I was > looking for an alternative. > > Although I've personally been using ccp and am quite happy with the GUI > tools now (so it will probably become default in my packages), I was > still looking for a way to define the default plugins uses if a gconf > backend was used. > > So I patched core.xml.in as follows: > --- a/metadata/core.xml.in > +++ b/metadata/core.xml.in > @@ -7,6 +7,23 @@ > <_short>Active Plugins > <_long>List of currently active plugins > string > + > + decoration [...] > + dbus > + > > > <_short>Texture Filter > > This kinda worked but not quite! > > All the plugins bar the first two are loaded fine (on a fresh user > account). So what happened to the first two? When running "compiz gconf", compiz first initializes the command line plugins in display.c:updatePlugins() (display options have been initialized from core metadata options which contains command line options). This function loads successively the plugins, and updates an internal plugins list each time a plugin is loaded. When the gconf plugin is initially loaded, it runs an intialization function which loads all settings from the gconf registry, including the "active_plugins" key. This routine also runs d->setDisplayOption, from gconf.c:gconfGetOptionValue(). So, after the gconf plugin init, d->opt[COMP_DISPLAY_OPTION_ACTIVE_PLUGINS] will look like: [decoration,png,wobbly,...] Back to the initial function, after a plugin is loaded, the internal plugins list d->plugin.list gets updated: [gconf] But then, the for loop continues, since d->opt[COMP_DISPLAY_OPTION_ACTIVE_PLUGINS] contains more values (that were loaded from gconf). At the end of the loop, d->plugin.list will look like: [gconf,png,wobbly,...] And finally, at the end of display.c:updatePlugins(), d->plugin gets copied back to d->opt[COMP_DISPLAY_OPTION_ACTIVE_PLUGINS] I tried to workaround this by stopping the loading loop as soon as a plugin makes the pluginlist dirty, and by not overwriting again the pluginslist if it is marked as dirty (see attached patch). Then, the plugin list will get reloaded, since it is marked as dirty. --- compiz-0.5.2-orig/src/display.c 2007-08-06 23:40:00.0 +0200 +++ compiz-0.5.2/src/display.c 2007-08-06 23:47:54.0 +0200 @@ -961,6 +967,8 @@ p = 0; } } + if (d->dirtyPluginList) + break; } if (p) @@ -993,7 +1002,8 @@ if (nPop) free (pop); -(*d->setDisplayOption) (d, o->name, &d->plugin); +if (!d->dirtyPluginList) + (*d->setDisplayOption) (d, o->name, &d->plugin); } static void This solves the issue at start, but also adds an unfortunate drawback: the gconf plugin is not listed anymore in the plugins list, and does not get uninitialized at stop (provoking a segfault here). Another solution could be to make the gconf plugin add itself in the plugin list, but this is a lot more hackish. Any other suggestions welcome. -- Olivier Blin - Mandriva ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
