Re: [compiz] Focus problem for shaded windows
Hi, > > > > 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? > > > > > > I applied the FocusChange change just before I realized that it > > > shouldn't be needed as we'll select for focus change events when the > > > window gets added using the addWindow function and this change shouldn't > > > make a difference. > > > > It does make a difference. We're currently selecting for FocusChange > > events of the _window_, not the _frame_. > > The problem is that although we correctly set the input focus to the > > frame window if the window is shaded (window.c:2870), we never get a > > FocusIn event in response and thus never will set the shaded window > > active (where findTopLevelWindowAtDisplay will retrieve the main window > > for the focussed frame). That's why we IMO need to select for > > FocusChange events also for the frame window. > > We do select for FocusChange events on the frame window at > window.c:1974. The frame window will be added to the window list just as > all other windows and we'll then select for FocusChange events, which is > why we don't have to do this when creating the window. Oh, yes, you are right ... I overlooked that addWindow is called for frame windows as well. Sorry. > > > lastFoundWindow is just an optimization to avoid walking the list of > > > windows when a window is looked up multiple times. > > > > > > The way lastFoundWindow is updated right now is more correct than what > > > your patch will do. > > > > I disagree. lastFoundWindow is used for both findWindowAtDisplay/Screen > > and findTopLevelWindowAtDisplay/Screen. This has the side effect that > > the behaviour of findTopLevelWindow depends on which window was > > processed by findWindow before: > > - Assumption: findWindowAtScreen is called for a frame window (which is > > a valid scenario) > > sure. > > > - findWindowAtScreen returns the frame window CompWindow struct and sets > > lastFoundWindow to that > > yes. > > > - if findTopLevelWindowAtScreen is called after that for the window the > > frame window belongs to, the frame window is returned > > No, how can that happen? lastFoundWindow->id will not match the id > passed to findTopLevelWindowAtScreen so it will walk the window list > until it finds the appropriate window with a matching id and return it. My point is valid - my explanation is not (dunno what I thought when I wrote that :-/ ). What I wanted to say: - findWindowAtDisplay (some_frame_window) will return some_frame_window - findTopLevelWindowAtDisplay (some_frame_window) will return some_frame_window after that although it should return the main window belonging to it. But it doesn't matter, as ... > I think I just found the bug that is causing the problem. > findWindowAtScreen and findTopLevelWindowAtScreen are fine. However, > findTopLevelWindowAtDisplay is broken. It shouldn't check > lastFoundWindow. I pushed out changes that will fix this problem and > clean up findTopLevelWindowAtScreen so it will be a bit easier to > understand how lastFoundWindow is used. > > Let me know if this fixed your problem. ... this change fixes the problem as findTopLevelWindowAtDisplay no longer immediately returns lastFoundWindow. Thanks. Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] KDE Window decorator offset on maximized windows.
David Reveman wrote: > On Fri, 2007-08-03 at 16:43 +0100, Colin Guthrie wrote: >> Diogo Ferreira wrote: >>> On Thu, 2007-08-02 at 10:34 +0100, Colin Guthrie wrote: Hi, Any reason why this would happen that you can think of? http://qa.mandriva.com/show_bug.cgi?id=32215 >>> I have no idea why it happens but I think it depends on the theme, >>> kde-window-decorator must be bugged somewhere, sometimes decorations >>> won't even appear like in this screenshot: >>> http://public.underdev.org/upload/files/no_decoration.png >>> >>> I've mentioned this before in the kwd-crash thread, hope this time it >>> gets some more attention from the people who understand kwd. >> It seems that "polyester" doesn't have this problem but "plastik" does. >> Perhaps that will help to debug? > > no, I used plastik when testing. :( Another one bites the dust :p Ahh well will keep trying to isolate. Col ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.2
David Reveman wrote: > On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote: >> >> On 8/3/07, David Reveman <[EMAIL PROTECTED]> wrote: >> A new compiz release 0.5.2 is now available >> >> any chance for a 0.6.0 release before 2007/08/28 ? >> (fedora 8 feature freeze) > > I wont have time but we could create a 0.6 branch for this if a some > people are interested in working on it. The Mandriva release cycle seems to be harmonious to Fedora's dates. So this is just another +1 on the 0.6 release plan :) Col ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.2
On Tue, 2007-08-07 at 20:57 +0200, Dennis Kasprzyk wrote: > Am Dienstag 07 August 2007 20:44:12 schrieb David Reveman: > > On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote: > > > On 8/3/07, David Reveman <[EMAIL PROTECTED]> wrote: > > > A new compiz release 0.5.2 is now available > > > > > > any chance for a 0.6.0 release before 2007/08/28 ? > > > (fedora 8 feature freeze) > > > > I wont have time but we could create a 0.6 branch for this if a some > > people are interested in working on it. > > > > -David > > > > ___ > > compiz mailing list > > compiz@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/compiz > > > Create a 0.6 branch out of the 0.5.2 (without xcb) version please. Yes, I don't think we want the xcb dependency if we're doing a 0.6 branch today. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
On Tue, 2007-08-07 at 20:44 +0200, Danny Baumann wrote: > Hi, > > > > >> 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? > > > > I applied the FocusChange change just before I realized that it > > shouldn't be needed as we'll select for focus change events when the > > window gets added using the addWindow function and this change shouldn't > > make a difference. > > It does make a difference. We're currently selecting for FocusChange > events of the _window_, not the _frame_. > The problem is that although we correctly set the input focus to the > frame window if the window is shaded (window.c:2870), we never get a > FocusIn event in response and thus never will set the shaded window > active (where findTopLevelWindowAtDisplay will retrieve the main window > for the focussed frame). That's why we IMO need to select for > FocusChange events also for the frame window. We do select for FocusChange events on the frame window at window.c:1974. The frame window will be added to the window list just as all other windows and we'll then select for FocusChange events, which is why we don't have to do this when creating the window. > > > lastFoundWindow is just an optimization to avoid walking the list of > > windows when a window is looked up multiple times. > > > > The way lastFoundWindow is updated right now is more correct than what > > your patch will do. > > I disagree. lastFoundWindow is used for both findWindowAtDisplay/Screen > and findTopLevelWindowAtDisplay/Screen. This has the side effect that > the behaviour of findTopLevelWindow depends on which window was > processed by findWindow before: > - Assumption: findWindowAtScreen is called for a frame window (which is > a valid scenario) sure. > - findWindowAtScreen returns the frame window CompWindow struct and sets > lastFoundWindow to that yes. > - if findTopLevelWindowAtScreen is called after that for the window the > frame window belongs to, the frame window is returned No, how can that happen? lastFoundWindow->id will not match the id passed to findTopLevelWindowAtScreen so it will walk the window list until it finds the appropriate window with a matching id and return it. > - if lastFoundWindow would have been unset, the window itself would have > been returned by findTopLevelWindowAtScreen. lastFoundWindow being unset doesn't change anything. lastFoundWindow is only a cache of the last found window. That's all. lastFoundWindow is only used when lastFoundWindow->id match the id we're searching for. > > That's a behaviour change which shouldn't be caused by an optimization. > Maybe a better fix for that would be to track the last found top level > window and last found window separately (that's what the attached > patch does). We could keep a separate cache for top-level windows but they are not searched for as often so I don't think it will make much of a difference. I think I just found the bug that is causing the problem. findWindowAtScreen and findTopLevelWindowAtScreen are fine. However, findTopLevelWindowAtDisplay is broken. It shouldn't check lastFoundWindow. I pushed out changes that will fix this problem and clean up findTopLevelWindowAt
Re: [compiz] [ANNOUNCE] compiz-0.5.2
On 8/7/07, Dennis Kasprzyk <[EMAIL PROTECTED]> wrote: > > Am Dienstag 07 August 2007 20:44:12 schrieb David Reveman: > > On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote: > > > On 8/3/07, David Reveman <[EMAIL PROTECTED]> wrote: > > > A new compiz release 0.5.2 is now available > > > > > > any chance for a 0.6.0 release before 2007/08/28 ? > > > (fedora 8 feature freeze) > > > > I wont have time but we could create a 0.6 branch for this if a some > > people are interested in working on it. > > > > -David > > > > ___ > > compiz mailing list > > compiz@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/compiz > > > Create a 0.6 branch out of the 0.5.2 (without xcb) version please. this sounds like a good idea. release a stable version without the xcb changes so that it can be used on older distros without xcb too and move the development branch to xcb. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.2
Am Dienstag 07 August 2007 20:44:12 schrieb David Reveman: > On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote: > > On 8/3/07, David Reveman <[EMAIL PROTECTED]> wrote: > > A new compiz release 0.5.2 is now available > > > > any chance for a 0.6.0 release before 2007/08/28 ? > > (fedora 8 feature freeze) > > I wont have time but we could create a 0.6 branch for this if a some > people are interested in working on it. > > -David > > ___ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz Create a 0.6 branch out of the 0.5.2 (without xcb) version please. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] KDE Window decorator offset on maximized windows.
On Fri, 2007-08-03 at 16:43 +0100, Colin Guthrie wrote: > Diogo Ferreira wrote: > > On Thu, 2007-08-02 at 10:34 +0100, Colin Guthrie wrote: > >> Hi, > >> > >> Any reason why this would happen that you can think of? > >> http://qa.mandriva.com/show_bug.cgi?id=32215 > > I have no idea why it happens but I think it depends on the theme, > > kde-window-decorator must be bugged somewhere, sometimes decorations > > won't even appear like in this screenshot: > > http://public.underdev.org/upload/files/no_decoration.png > > > > I've mentioned this before in the kwd-crash thread, hope this time it > > gets some more attention from the people who understand kwd. > > It seems that "polyester" doesn't have this problem but "plastik" does. > Perhaps that will help to debug? no, I used plastik when testing. :( -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.2
On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote: > > > On 8/3/07, David Reveman <[EMAIL PROTECTED]> wrote: > A new compiz release 0.5.2 is now available > > any chance for a 0.6.0 release before 2007/08/28 ? > (fedora 8 feature freeze) I wont have time but we could create a 0.6 branch for this if a some people are interested in working on it. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
Hi,
> > >> 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?
>
> I applied the FocusChange change just before I realized that it
> shouldn't be needed as we'll select for focus change events when the
> window gets added using the addWindow function and this change shouldn't
> make a difference.
It does make a difference. We're currently selecting for FocusChange
events of the _window_, not the _frame_.
The problem is that although we correctly set the input focus to the
frame window if the window is shaded (window.c:2870), we never get a
FocusIn event in response and thus never will set the shaded window
active (where findTopLevelWindowAtDisplay will retrieve the main window
for the focussed frame). That's why we IMO need to select for
FocusChange events also for the frame window.
> lastFoundWindow is just an optimization to avoid walking the list of
> windows when a window is looked up multiple times.
>
> The way lastFoundWindow is updated right now is more correct than what
> your patch will do.
I disagree. lastFoundWindow is used for both findWindowAtDisplay/Screen
and findTopLevelWindowAtDisplay/Screen. This has the side effect that
the behaviour of findTopLevelWindow depends on which window was
processed by findWindow before:
- Assumption: findWindowAtScreen is called for a frame window (which is
a valid scenario)
- findWindowAtScreen returns the frame window CompWindow struct and sets
lastFoundWindow to that
- if findTopLevelWindowAtScreen is called after that for the window the
frame window belongs to, the frame window is returned
- if lastFoundWindow would have been unset, the window itself would have
been returned by findTopLevelWindowAtScreen.
That's a behaviour change which shouldn't be caused by an optimization. Maybe a
better fix for that would be to track the last found top level window and last
found window separately (that's what the attached patch does).
Regards,
Danny
diff --git a/include/compiz.h b/include/compiz.h
index e870662..451d5e1 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -214,6 +214,7 @@ extern Window currentRoot;
extern Bool shutDown;
extern Bool restartSignal;
extern CompWindow *lastFoundWindow;
+extern CompWindow *lastFoundTopLevelWindow;
extern CompWindow *lastDamagedWindow;
extern Bool replaceCurrentWm;
extern Bool indirectRendering;
diff --git a/src/display.c b/src/display.c
index ac9ba1e..7cd75fa 100644
--- a/src/display.c
+++ b/src/display.c
@@ -2690,9 +2690,9 @@ CompWindow *
findTopLevelWindowAtDisplay (CompDisplay *d,
Window id)
{
-if (lastFoundWindow && lastFoundWindow->id == id)
+if (lastFoundTopLevelWindow && lastFoundTopLevelWindow->id == id)
{
- return lastFoundWindow;
+ return lastFoundTopLevelWindow;
}
else
{
diff --git a/src/main.c b/src/main.c
index a85c484..d1a8b66 100644
--- a/src/main.c
+++ b/src/main.c
@@ -54,6 +54,7 @@ Bool shutDown = FALSE;
Bool restartSignal = FALSE;
CompWindow *lastFoundWindow = 0;
+CompWindow *lastFoundTopLevelWindow = 0;
CompWindow *lastDamagedWindow = 0;
Bool replaceCurrentWm = FALSE;
diff --git a/src/screen.c b/src/screen.c
index 15458f7..eab372c 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -2210,9 +2210,9 @@ findTopLe
Re: [compiz] [ANNOUNCE] compiz-0.5.2
On 8/3/07, David Reveman <[EMAIL PROTECTED]> wrote: > > A new compiz release 0.5.2 is now available any chance for a 0.6.0 release before 2007/08/28 ? (fedora 8 feature freeze) ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Focus problem for shaded windows
On Mon, 2007-08-06 at 10:15 +0200, Danny Baumann wrote: > >> 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? I applied the FocusChange change just before I realized that it shouldn't be needed as we'll select for focus change events when the window gets added using the addWindow function and this change shouldn't make a difference. lastFoundWindow is just an optimization to avoid walking the list of windows when a window is looked up multiple times. The way lastFoundWindow is updated right now is more correct than what your patch will do. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Unbound modifiers and CompNoMask
On Sun, 2007-08-05 at 05:21 -0400, Andy Hefner wrote: > This patch fixes an undesirable behavior in the comparison of modifier > bits necessary to initiate an action - if the modifier is not configured > on the user's X server (thus having CompNoMask in its position in > d->modMask), the comparison always behaves as though the modifier were > pressed, due to CompNoMask falling outside the REAL_MOD_MASK & > ~d->ignoredModMask bitmask. This causes actions to be invoked > inappropriately (for instance, if the user has no keysyms assigned for > the Super modifier, the zoom plugin can be triggered on unmodified > scroll wheel events, interfering with normal scrolling). Good catch. I added CompNoMask to the REAL_MOD_MASK define, which should take care of the problem. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Dual-screen compiz mostly working
> Most of these problems are all the same problem, from the look of it. > Your screen resolution is higher than your video card's maximum texture > size. This is simply a hardware limitation. You were absolutely right after all. The strange limitations i was seeing was because i was changing between screen resolutions w/ xrandr while compiz was running. If i use xrandr to set the total resolution of both screens to 1400x1818 and *then* start compiz it works beautifully. Some of the other oddities were fixed by xorg.conf tweaking. thank you everyone for the valuable help. ~mck -- "Buddhism has the characteristics of what would be expected in a cosmic religion for the future: It transcends a personal God, avoids dogmas and theology; it covers both the natural and the spiritual, and it is based on a religious sense aspiring from the experience of all things, natural and spiritual, as a meaningful unity." Albert Einstein Homepage - www.wever.org | Sesam Search Engine - www.sesam.no ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
