gitk: restore wm state to normal before saving geometry information
PATCH 1/1 gitk: restore wm state to normal before saving geometry information
gitk now includes patches for saving and restoring wm state, however because it saves wm geometry when window can still be maximized the maximize/restore button becomes useless after restarting gitk (you will get a huge displaced window if you try to restore it). This patch fixes this issue by storing window geometry in normal state.
---
My previous email didn't come out rights, I hope this one will Don't forget to cc me if you have any comments/questions
gitk | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
gitk +4 -1
@@ -2555,8 +2555,11 @@ proc savestuff {w} { puts $f [list set extdifftool $extdifftool] puts $f [list set perfile_attrs $perfile_attrs] - puts $f "set geometry(main) [wm geometry .]" puts $f "set geometry(state) [wm state .]" + if {[wm state .] eq {zoomed}} { + wm state . normal + } + puts $f "set geometry(main) [wm geometry .]" puts $f "set geometry(topwidth) [winfo width .tf]" puts $f "set geometry(topheight) [winfo height .tf]" puts $f "set geometry(pwsash0) \"[.tf.histframe.pwclist sash coord 0]\""
Signature · 1 line
1.6.4.2
PATCH 1/2 Work around leftover temporary save file.
If a file exists and is hidden on Windows the Tcl open command will fail as the attributes provided in the CREAT call fail to match those of the existing file. Forcing removal of the temporary file before we begin solves any problems caused by previous failures to save the application settings. An alternative would be to remove the hidden attribute before calling 'open'.
--- gitk | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
gitk +1 -0
@@ -2526,6 +2526,7 @@ proc savestuff {w} { if {$stuffsaved} return if {![winfo viewable .]} return catch { + if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new} set f [open "~/.gitk-new" w] if {$::tcl_platform(platform) eq {windows}} { file attributes "~/.gitk-new" -hidden true
Signature · 1 line
1.6.4.msysgit.0
Re: [PATCH 1/2] Work around leftover temporary save file.
Quoted 18 lines · Pat Thoyts
If a file exists and is hidden on Windows the Tcl open command will fail as the attributes provided in the CREAT call fail to match those of the existing file. Forcing removal of the temporary file before we begin solves any problems caused by previous failures to save the application settings. An alternative would be to remove the hidden attribute before calling 'open'.
Signed-off-by Pat Thoyts <[email protected]>---
gitk | 1 +1 files changed, 1 insertions(+), 0 deletions(-)gitk +0
-0@@ -2526,6 +2526,7 @@ proc savestuff {w} {
Quoted 4 lines
if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
+ if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
maybe another gitk instance is writing it at exactly same moment in time? Writing is known to take a few moments. Especially on Windows.
Re: [PATCH 1/2] Work around leftover temporary save file.
Quoted 15 lines · Alex Riesen
Quoted 13 lines · Pat Thoyts
If a file exists and is hidden on Windows the Tcl open command will fail as the attributes provided in the CREAT call fail to match those of the existing file. Forcing removal of the temporary file before we begin solves any problems caused by previous failures to save the application settings. An alternative would be to remove the hidden attribute before calling 'open'.
Signed-off-by Pat Thoyts <[email protected]>---
gitk | 1 +1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 12 lines
Quoted 9 lines
gitk +0
-0@@ -2526,6 +2526,7 @@ proc savestuff {w} {if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
+ if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}maybe another gitk instance is writing it at exactly same moment in time? Writing is known to take a few moments. Especially on Windows.
no - 'open $file w' is translated into O_WRONLY|O_CREAT|O_TRUNC internally and passed to the win32 layer to get converted to a call to CreateFile with GENERIC_WRITE, CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL. The file has
got FILE_ATTRIBUTE_HIDDEN though and as it exists and our attributes
do not match we get failed.
'open $file {O_WRONLY O_TRUNC}' would open it but we'd have to check
for non-existence and redo with O_CREAT if it was not already present.
See tclWinChan.c:TclpOpenFileChannel.
Signature · 2 lines
Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Re: [PATCH 1/2] Work around leftover temporary save file.
In reply to Alex RiesenQuoted 15 lines · Alex Riesen
Quoted 13 lines · Pat Thoyts
If a file exists and is hidden on Windows the Tcl open command will fail as the attributes provided in the CREAT call fail to match those of the existing file. Forcing removal of the temporary file before we begin solves any problems caused by previous failures to save the application settings. An alternative would be to remove the hidden attribute before calling 'open'.
Signed-off-by Pat Thoyts <[email protected]>---
gitk | 1 +1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 12 lines
Quoted 9 lines
gitk +0
-0@@ -2526,6 +2526,7 @@ proc savestuff {w} {if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
+ if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}maybe another gitk instance is writing it at exactly same moment in time? Writing is known to take a few moments. Especially on Windows.
Then deleting would fail, because on Windows opened files cannot be deleted (unless they are opened in a special way that permits it).
Re: [PATCH 1/2] Work around leftover temporary save file.
Quoted 4 lines · Alexey Borzenkov
Then deleting would fail, because on Windows opened files cannot be deleted (unless they are opened in a special way that permits it).
The delete occurs before we attempt to open the file which is why it succeeds when such file is present.
Signature · 2 lines
Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
PATCH 2/2 Fix the geometry when restoring from zoomed state.
In reply to Alexey BorzenkovThe patch to handle the geometry of a restored gitk by Alexy Borzenkov causes the position of the columns to creep each time the application is restarted. This patch addresses this by remembering the application geometry for the normal state and saving that regardless of the actual state when the application is closed.
--- gitk | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-)
gitk +8 -1
@@ -2251,6 +2251,8 @@ proc makewindow {} { } wm geometry . "${w}x$h" } + } else { + set geometry(main) [wm geometry .] } if {[info exists geometry(state)] && $geometry(state) eq "zoomed"} {
@@ -2265,6 +2267,11 @@ proc makewindow {} { set ::BM "2" } + bind . <Configure> { + if {[winfo toplevel %W] eq "%W" && [wm state %W] eq "normal"} { + set ::geometry(main) %wx%h+%x+%y + } + } bind .pwbottom <Configure> {resizecdetpanes %W %w} pack .ctop -fill both -expand 1 bindall <1> {selcanvline %W %x %y}
@@ -2556,7 +2563,7 @@ proc savestuff {w} { puts $f [list set extdifftool $extdifftool] puts $f [list set perfile_attrs $perfile_attrs] - puts $f "set geometry(main) [wm geometry .]" + puts $f "set geometry(main) $::geometry(main)" puts $f "set geometry(state) [wm state .]" puts $f "set geometry(topwidth) [winfo width .tf]" puts $f "set geometry(topheight) [winfo height .tf]"
Signature · 1 line
1.6.4.msysgit.0
Re: [PATCH 2/2] Fix the geometry when restoring from zoomed state.
Quoted 5 lines · Pat Thoyts
The patch to handle the geometry of a restored gitk by Alexy Borzenkov causes the position of the columns to creep each time the application is restarted. This patch addresses this by remembering the application geometry for the normal state and saving that regardless of the actual state when the application is closed.
I can confirm it works even when the difference between normal and maximized window are big.
Re: [PATCH 2/2] gitk: Fix the geometry when restoring from zoomed state
In reply to Pat ThoytsQuoted 5 lines · Pat Thoyts
The patch to handle the geometry of a restored gitk by Alexy Borzenkov causes the position of the columns to creep each time the application is restarted. This patch addresses this by remembering the application geometry for the normal state and saving that regardless of the actual state when the application is closed.
So this patch replaces Alexey's patch, then? The context in your patch doesn't match the changes made in Alexey's patch AFAICS.
Paul.
Re: [PATCH 2/2] gitk: Fix the geometry when restoring from zoomed state
Quoted 10 lines · Paul Mackerras
Quoted 5 lines · Pat Thoyts
The patch to handle the geometry of a restored gitk by Alexy Borzenkov causes the position of the columns to creep each time the application is restarted. This patch addresses this by remembering the application geometry for the normal state and saving that regardless of the actual state when the application is closed.
So this patch replaces Alexey's patch, then? The context in your patch doesn't match the changes made in Alexey's patch AFAICS.
Correct. I posted a response to Alexy's patch saying I'd post an alternative as I had trouble with the columns resizing and creeping due to the assertion of 'wm state normal' during the settings save each time.
See
http://thread.gmane.org/gmane.comp.version-control.git/128026/focus=128652
The context of mine should be the gitk repository master (was c21398be).
Signature · 2 lines
Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Re: [PATCH 2/2] gitk: Fix the geometry when restoring from zoomed state
In reply to Paul MackerrasQuoted 8 lines · Paul Mackerras
Quoted 5 lines
The patch to handle the geometry of a restored gitk by Alexy Borzenkov causes the position of the columns to creep each time the application is restarted. This patch addresses this by remembering the application geometry for the normal state and saving that regardless of the actual state when the application is closed.
So this patch replaces Alexey's patch, then? The context in your patch doesn't match the changes made in Alexey's patch AFAICS.
Yes. Pat's patch replaces my patch.
Quoted 6 lines · Alexey Borzenkov
gitk now includes patches for saving and restoring wm state, however because it saves wm geometry when window can still be maximized the maximize/restore button becomes useless after restarting gitk (you will get a huge displaced window if you try to restore it). This patch fixes this issue by storing window geometry in normal state.
I tried this patch on windows and I find that it causes the columns in the top view to creep each time you restart the application. This is I think due to the way this patch sets the state to normal before recording all the settings.
I will post an alternative patch that records the normal geometry whenever it changes instead which seems to work better for me.
Signature · 2 lines
Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Quoted 9 lines · Pat Thoyts
Quoted 5 lines
gitk now includes patches for saving and restoring wm state, however because it saves wm geometry when window can still be maximized the maximize/restore button becomes useless after restarting gitk (you will get a huge displaced window if you try to restore it). This patch fixes this issue by storing window geometry in normal state.
I tried this patch on windows and I find that it causes the columns in the top view to creep each time you restart the application. This is I think due to the way this patch sets the state to normal before recording all the settings.
This is strange, as I certainly don't see this behaviour now (I'm using gitk in version 1.6.4.3). Actually, I did see that behaviour once, but I believe this was when I ran an unpatched gitk which seemed to record wrong geometry. As soon as I cleared ~/.gitk of those wrong coordinates I haven't seen this behaviour anymore.
On the other hand, when I resize columns and then maximize/restore the window repeatedly I see that their sizes change in a strange way (and the smaller restored window they stranger are results) until hitting some sort of equilibrium, then maximize/restore doesn't have effect on their sizes anymore. So maybe there's a bug not in a way my patch restores the window, but in a way window resizes are handled.
Quoted 2 lines
I will post an alternative patch that records the normal geometry whenever it changes instead which seems to work better for me.
By all means.
Quoted 6 lines · Alexey Borzenkov
On the other hand, when I resize columns and then maximize/restore the window repeatedly I see that their sizes change in a strange way (and the smaller restored window they stranger are results) until hitting some sort of equilibrium, then maximize/restore doesn't have effect on their sizes anymore. So maybe there's a bug not in a way my patch restores the window, but in a way window resizes are handled.
It seems that I found what's the problem. When the window is very small, and we maximize it, sash coords would initially be small. Then we calculate their new positions and set it with $win sash place, but unfortunately, tk limits them to the OLD pane size for some reason. Initially I though that maybe Configure is fired too early (before window is resized), but [winfo width $win] shows $win has the new size. Here's some output that I got during debugging:
resizing 422 -> 1261 (winfo shows 1261)
s0: 138 1
s1: 288 1
sash0: 412 -> 412 1
sash1: 860 -> 417 1I'm at a loss why this happens and how to lift this restriction.
Quoted 5 lines · Alexey Borzenkov
gitk now includes patches for saving and restoring wm state, however because it saves wm geometry when window can still be maximized the maximize/restore button becomes useless after restarting gitk (you will get a huge displaced window if you try to restore it). This patch fixes this issue by storing window geometry in normal state.
Hmmm, shouldn't we be also saving the window state (zoomed/normal) and restoring that as well?
Paul.
Quoted 6 lines · Paul Mackerras
Quoted 1 line
patch fixes this issue by storing window geometry in normal state.
Hmmm, shouldn't we be also saving the window state (zoomed/normal) and restoring that as well?
Paul.
We do. That got added in c876dbad
Signature · 2 lines
Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD