Re: Patch: Prevent windows from drifting on restart
On Sun, 16 Dec 2012 at 13:22:23 -0800, Iain Patterson wrote: > Quoth Carlos R. Mafra, > > >Strangely enough, after your patches I see a xterm drift upwards by > >30 pixels (I guess it's the titleborder height). My test case is very > >simple: > > The best answer may be to remove all the hacks about borders and > bars and instead let the window's co-ordinates be its actual > co-ordinates with the other stuff positioned in relation to the > window rather than vice versa. Ok, I'll have to revert some of your patches about this since I've noticed that it was ok previously; at least for this huge drifting. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
Quoth Carlos R. Mafra, Strangely enough, after your patches I see a xterm drift upwards by 30 pixels (I guess it's the titleborder height). My test case is very simple: The best answer may be to remove all the hacks about borders and bars and instead let the window's co-ordinates be its actual co-ordinates with the other stuff positioned in relation to the window rather than vice versa. Another entry for my list of things I don't have time to do until next year. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On Fri, 16 Nov 2012 at 17:06:45 -0800, Iain Patterson wrote: > With these two extra patches there should be no more drifting. > > Exit Window Maker? No drifting. Strangely enough, after your patches I see a xterm drift upwards by 30 pixels (I guess it's the titleborder height). My test case is very simple: 1. Open a xterm and check its position (say (400,800)) 2. Save session 3. Exit wmaker 4. Start wmaker; xterm is at (400,770) I checked that before Iain's patches about borders drifting, the above scenario does not happen. But many people reported that these patches were OK, so I'd like to ask those people to try the above and report back. Perhaps it's something odd here. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
Quoth BALATON Zoltan, The window of Deadbeef (with the gtk3 UI plugin in case it matters) is now drifting upwards by about the size of its window decoration whenever it's mapped (when it is first opened or after being closed and reopened by clicking on the tray icon). I can reproduce that. The app seems to save its window positions (gtk_window_get_position, gtk_window_get_size) and tries to restore them before showing the window via gtk_window_move and gtk_window_resize (or gtk_window_maximize if it was maximised). Good observation. Let me look into it. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
Hello Iain, yes indeed, it works now! :) I just came around to checkout, compile, and install the latest wmaker-crm, and can now confirm that the reported issue is resolved. Thanks a lot! Regards, Paul On 11/17/2012 02:06 AM, Iain Patterson wrote: > With these two extra patches there should be no more drifting. > > Exit Window Maker? No drifting. > > Restart Window Maker? No drifting. > > Start Window Maker on an unmanaged display? No drifting. > > Toggle a window's border on or off in the inspector? No drifting. > > Managing and unmanaging windows which already had borders? No drifting. > > Managing a previously maximised window? No drifting. > > Also no overlapping titlebars on new windows. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On Sun, 18 Nov 2012, BALATON Zoltan wrote: The app is available at deadbeef.sf.net some of its window properties are: Some more info which may be helpful. The app seems to save its window positions (gtk_window_get_position, gtk_window_get_size) and tries to restore them before showing the window via gtk_window_move and gtk_window_resize (or gtk_window_maximize if it was maximised). This seems to make it drift. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On Fri, 16 Nov 2012, Iain Patterson wrote: With these two extra patches there should be no more drifting. Unfortunately I've found an app which now exhibits drifting with current #next while it had no problem before. The window of Deadbeef (with the gtk3 UI plugin in case it matters) is now drifting upwards by about the size of its window decoration whenever it's mapped (when it is first opened or after being closed and reopened by clicking on the tray icon). Any ideas? The app is available at deadbeef.sf.net some of its window properties are: _NET_WM_STATE(ATOM) = _NET_WM_DESKTOP(CARDINAL) = 0 _NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 25, 9 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 288 by 138 program specified base size: 0 by 0 window gravity: NorthWest xwininfo: Window id: 0x186 "DeaDBeeF-0.5.6" Absolute upper-left X: 302 Absolute upper-left Y: 456 Relative upper-left X: 0 Relative upper-left Y: 24 Width: 907 Height: 555 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +302+456 -71+456 -71-13 +302-13 -geometry 907x555-70-4 after closing the window and reopening via the tray icon: xwininfo: Window id: 0x186 "DeaDBeeF-0.5.6" Absolute upper-left X: 301 Absolute upper-left Y: 431 Relative upper-left X: 0 Relative upper-left Y: 24 Width: 907 Height: 555 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +301+431 -72+431 -72-38 +301-38 -geometry 907x555-71-29 Let me know if you need more info or help in debugging. Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On Sat, 17 Nov 2012, BALATON Zoltan escribió: > On Fri, 16 Nov 2012, Iain Patterson wrote: > > With these two extra patches there should be no more drifting. > > This is great! Yesterday I've seen a one pixel drift with some > applications but with this it's now working right again. Thanks a > lot for fixing this! > > Regards, > BALATON Zoltan These patches are so good. Congrats. kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On Fri, 16 Nov 2012, Iain Patterson wrote: With these two extra patches there should be no more drifting. This is great! Yesterday I've seen a one pixel drift with some applications but with this it's now working right again. Thanks a lot for fixing this! Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
On 11/16/12, Iain Patterson wrote: >With these two extra patches there should be no more drifting. > >Exit Window Maker? No drifting. > >Restart Window Maker? No drifting. > >Start Window Maker on an unmanaged display? No drifting. > >Toggle a window's border on or off in the inspector? No drifting. > >Managing and unmanaging windows which already had borders? No > drifting. > >Managing a previously maximised window? No drifting. > >Also no overlapping titlebars on new windows. > There has always been a case of drifting whenever an X window resized itself manually. For example, create a Java Swing application that uses its own theme (i.e. not the WM theme but the spiffy looking blue boxes, etc.). If you resize said window that is created, the window slowly drifts down right. It also happens in OpenOffice/LibreOffice too whenever a menubar is opened. Does it no longer occur in these cases? -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Prevent windows from drifting on restart
With these two extra patches there should be no more drifting.
Exit Window Maker? No drifting.
Restart Window Maker? No drifting.
Start Window Maker on an unmanaged display? No drifting.
Toggle a window's border on or off in the inspector? No drifting.
Managing and unmanaging windows which already had borders? No
drifting.
Managing a previously maximised window? No drifting.
Also no overlapping titlebars on new windows.
From 0010a2395a68f7632c26f9ca46df7f48af33ba90 Mon Sep 17 00:00:00 2001
From: Iain Patterson
Date: Fri, 16 Nov 2012 14:43:52 -0800
Subject: [PATCH 2/3] Fixed regression when placing windows.
The initial fix for the bug reported by Paul Seelig whereby windows
would drift on restart introduced two regressions.
New windows would place higher on the screen than intended, possibly
obscuring the bottoms of other windows with their titlebars, and all
windows would jump vertically at shutdown because we weren't restoring
them to where they were before they had a titlebar and border.
---
src/client.c| 7 +++
src/placement.c | 10 ++
src/window.c| 5 +++--
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/src/client.c b/src/client.c
index 3287306..10f2571 100644
--- a/src/client.c
+++ b/src/client.c
@@ -81,6 +81,13 @@ void wClientRestore(WWindow * wwin)
if (gy > 0)
wwin->frame_y += (wwin->frame->top_width +
wwin->frame->bottom_width);
#endif
+ /* account for titlebar and border */
+ wwin->frame_y += wwin->frame->top_width;
+ if (HAS_BORDER(wwin)) {
+ wwin->frame_x += FRAME_BORDER_WIDTH;
+ wwin->frame_y += FRAME_BORDER_WIDTH;
+ }
+
XSetWindowBorderWidth(dpy, wwin->client_win, wwin->old_border_width);
XReparentWindow(dpy, wwin->client_win, wwin->screen_ptr->root_win,
wwin->frame_x, wwin->frame_y);
diff --git a/src/placement.c b/src/placement.c
index b30e0af..3d219d6 100644
--- a/src/placement.c
+++ b/src/placement.c
@@ -523,6 +523,7 @@ void PlaceWindow(WWindow *wwin, int *x_ret, int *y_ret,
unsigned width, unsigned
WScreen *scr = wwin->screen_ptr;
int h = WMFontHeight(scr->title_font)
+ (wPreferences.window_title_clearance + TITLEBAR_EXTEND_SPACE)
* 2;
+ int border_width;
if (h > wPreferences.window_title_max_height)
h = wPreferences.window_title_max_height;
@@ -577,13 +578,14 @@ void PlaceWindow(WWindow *wwin, int *x_ret, int *y_ret,
unsigned width, unsigned
* this will also take dock/clip etc.. into account
* aswell as being xinerama friendly
*/
- if (*x_ret + width > usableArea.x2)
- *x_ret = usableArea.x2 - width;
+ border_width = (HAS_BORDER(wwin)) ? 2 * FRAME_BORDER_WIDTH : 0;
+ if (*x_ret + border_width + width > usableArea.x2)
+ *x_ret = usableArea.x2 - border_width - width;
if (*x_ret < usableArea.x1)
*x_ret = usableArea.x1;
- if (*y_ret + height > usableArea.y2)
- *y_ret = usableArea.y2 - height;
+ if (*y_ret + border_width + height > usableArea.y2)
+ *y_ret = usableArea.y2 - border_width - height;
if (*y_ret < usableArea.y1)
*y_ret = usableArea.y1;
}
diff --git a/src/window.c b/src/window.c
index b07d9d4..7f0a1fe 100644
--- a/src/window.c
+++ b/src/window.c
@@ -591,6 +591,7 @@ WWindow *wManageWindow(WScreen *scr, Window window)
char *title;
Bool withdraw = False;
Bool raise = False;
+ Bool frame_adjustment = True;
/* mutex. */
XGrabServer(dpy);
@@ -994,6 +995,7 @@ WWindow *wManageWindow(WScreen *scr, Window window)
} else {
PlaceWindow(wwin, &x, &y, width, height);
+ frame_adjustment = False;
}
if (wPreferences.window_placement == WPM_MANUAL) {
dontBring = True;
@@ -1144,7 +1146,7 @@ WWindow *wManageWindow(WScreen *scr, Window window)
y -= wwin->frame->top_width + wwin->frame->bottom_width;
}
- {
+ if (frame_adjustment) {
WMRect rect;
WArea usableArea;
int head;
@@ -1161,7 +1163,6 @@ WWindow *wManageWindow(WScreen *scr, Window window)
* when placing so the window would be shifted without
* the adjustment below
*/
-
if (y >= usableArea.y1 + wwin->frame->top_width)
y -= wwin->frame->top_width;
--
1.7.11.4
From ec5dc11759b505893b98651fe9384bcae83e71d3 Mon Sep 17 00:00:00 2001
From: Iain Patterson
Date: Fri, 16 Nov 2012 16:00:07 -0800
Subject: [PATCH 3/3] Prevent border drifting.
Windows were drifting by FRAME_BORDER_WIDTH pixels when their
borders were toggled on or off.
Windows which had a border befor
Re: Patch: Prevent windows from drifting on restart
Quoth Paul Seelig, Now, when restarting wmaker, any window jumps vertically by a whole lot of pixels (same amount defined by the title bar?), and slowly moves horizontally to the left by one(?) pixel, as was the case before applying this patch. I'm testing a new patch which fixes both those complaints. The problem is that when we unmanage the window we don't account for the title bar and border, ie the same problem fixed by the previous patch but in reverse. In testing I am seeing the windows stay perfectly still when wmaker is restarted, exited cleanly or killed. I haven't sent the patch yet because when testing what happened with and without borders I saw that toggling borders on and off causes a window to shift by one pixel (not a regression; it always did so). I don't want to introduce any regression related to that. Even worse, now when opening a new terminal window, its title bar overlaps an already open window at its very bottom. I don't think this is what the patch inventor had in mind... ;) I hadn't previously seen that when testing but I can now reproduce it. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Patch: Prevent windows from drifting on restart
Fix for the bug reported by Paul Seelig whereby windows drift when
Window Maker is restarted. This patch builds on
b657f15344f193d70747689f96cefddc8baa2181 which is already in next.
From 614fe5887bc2d38f8d115b791dbaca09e6e4cf5e Mon Sep 17 00:00:00 2001
From: Iain Patterson
Date: Thu, 15 Nov 2012 16:55:52 -0800
Subject: [PATCH] Prevent windows from drifting on restart.
Bug report from Paul Seelig:
"Yet another rather strange glitch:
- open three terminal windows
- repeatedly restart wmaker
- all windows slowly drift to the left and up by just a few pixels
If i remember correctly, this is also a longstanding issue and nothing
new. It is no showstopper either, as one rarely restarts wmaker."
The slight drifting left and up seems to have been due to
wWindowConfigure() accounting for the window border when placing, which
was fixed in an earlier commit.
Windows could still shuffle down, however, because wWindowConfigure()
was moving the window down to make room for its window frame.
We now move it up by the titlebar height to cancel out that movement.
---
src/window.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/src/window.c b/src/window.c
index 9970c1a..b07d9d4 100644
--- a/src/window.c
+++ b/src/window.c
@@ -1144,11 +1144,7 @@ WWindow *wManageWindow(WScreen *scr, Window window)
y -= wwin->frame->top_width + wwin->frame->bottom_width;
}
- /* wWindowConfigure() will account for the window border
-* when placing so the window would be shifted without
-* the adjustment below
-*/
- if (HAS_BORDER(wwin)) {
+ {
WMRect rect;
WArea usableArea;
int head;
@@ -1161,10 +1157,24 @@ WWindow *wManageWindow(WScreen *scr, Window window)
head = wGetHeadForRect(scr, rect);
usableArea = wGetUsableAreaForHead(scr, head, NULL, True);
- if (x >= usableArea.x1 + 2 * FRAME_BORDER_WIDTH)
- x -= 2 * FRAME_BORDER_WIDTH;
- if (y >= usableArea.y1 + 2 * FRAME_BORDER_WIDTH)
- y -= 2 * FRAME_BORDER_WIDTH;
+ /* wWindowConfigure() will account for the frame
+* when placing so the window would be shifted without
+* the adjustment below
+*/
+
+ if (y >= usableArea.y1 + wwin->frame->top_width)
+ y -= wwin->frame->top_width;
+
+ /* wWindowConfigure() will account for the window border
+* when placing so the window would be shifted without
+* the adjustment below
+*/
+ if (HAS_BORDER(wwin)) {
+ if (x >= usableArea.x1 + FRAME_BORDER_WIDTH)
+ x -= FRAME_BORDER_WIDTH;
+ if (y >= usableArea.y1 + FRAME_BORDER_WIDTH)
+ y -= FRAME_BORDER_WIDTH;
+ }
}
/*
--
1.7.11.4
