From: Brett Schwarz <brett_schwarz@yahoo.com>
To: Mark Levedahl <mdl123@verizon.net>,
"Shawn O. Pearce" <spearce@spearce.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH] Make gitk save and restore the user set window position.
Date: Wed, 7 Feb 2007 21:43:31 -0800 (PST) [thread overview]
Message-ID: <491753.81112.qm@web38915.mail.mud.yahoo.com> (raw)
>----- Original Message ----
>From: Mark Levedahl <mdl123@verizon.net>
>To: Shawn O. Pearce <spearce@spearce.org>
>Cc: Junio C Hamano <junkio@cox.net>; git@vger.kernel.org
>Sent: Wednesday, February 7, 2007 4:30:38 PM
>Subject: Re: [PATCH] Make gitk save and restore the user set window position.
>
>Shawn O. Pearce wrote:
>> Junio C Hamano <junkio@cox.net> wrote:
>>
>>> After seeing what this patch has to do, I feel dirty, but
>>> that is not Mark's fault -- rather it is Tk's.
>>>
>>> I am tempted to suggest adding an explicit "Save window
>>> configuration" action on the menubar and forget about
>>> resurrecting the window configuration immediately before the
>>> end of the last session.
>>>
>>
>> Maybe take a look at what git-gui does here, because its slightly
>> saner and still saves the geometry on exit:
>>
>> set is_quitting 0
>> proc do_quit {} {
>> global is_quitting
>> if {$is_quitting} return
>> set is_quitting 1
>> # save wm geometry
>> }
>> bind . <Destroy> do_quit
>>
>> OK, its not that much saner. But it does bypass needing to setup
>> some ugly bindings on every object in the UI. Though I recently
>> took a slightly different approach in a dialog:
>>
>> proc do_quit {} {
>> bind . <Destroy> {}
>> # do cleanup
>> }
>> bind . <Destroy> do_quit
>>
>> Yes the binding is firing in both cases for some arbitrary child
>> widget in the window, but it doesn't matter. In the latter version
>> setting the binding to the empty string removes the do_quit binding,
>> allowing the other widgets to destroy without reinvoking do_quit
>> and whacking whatever geometry data you may have saved before the
>> widgets started to get deleted.
>>
>>
>> The only problem I seem to have in git-gui is the window position
>> opens about 10 pixels lower and 2 pixels to the right than the last
>> time it opened. I think there's a bug in Tk on Windows where the
>> window position on the desktop doesn't include the titlebar when I
>> get it, but expects to include it when I attempt to set it on the
>> next start.
>>
>> I should note I also see the same behavior with my day-time-job's
>> Java apps on Windows however, so I don't think its a specific Tk
>> or git-gui issue.
>>
>>
> What you suggest is essentially what gitk does before my patch. In
> git-gui, routine do_quit is invoked when Tk is ready to destroy the top
> level window: this is _after_ Tk has destroyed everything in the window,
> and thus the problem. I still haven't isolated which object(s) being
> destroyed from gitk cause the geometry reported from wm info to change,
> clearly my patch is binding widgets that do not need to be bound, but I
> haven't found which specific one needs to be bound.
>
> With my patch, the correct position is saved and restored on both Linux
> and Cygwin. I think that should be the goal. A more elegant solution
> accomplishing that end is of course desirable, but there remains the
> issue of finding it. I think the objections to my patch are more
> theoretical than practical: I seriously doubt you can find any
> practically observable side effect of binding all the widgets other than
> that the window geometry _is_ correctly saved and restored.
>
> As to being specific to Tk, I have many windows applications that
> successfully save and restore window state, this geometry issue is not
> endemic to Windows and I have never encountered it except with Tk.
>
> Mark
>
I've only been half following this thread, so I apologize if this was already talked about.
Have you tried [wm protocol] command. You would use it like this:
wm protocol . WM_DELETE_WINDOW do_quit
This basically traps the signal from the windowmanager, and [do_quit] gets executed *before* the gui is torn down. The only bad thing about this, is if you explicitly destroy a widget inside your code (i.e. [destroy .]), then this will *not* get invoked. You also need to make sure you catch any possible errors in do_quit, otherwise the gui will hang.
HTH,
--brett
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
next reply other threads:[~2007-02-08 5:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 5:43 Brett Schwarz [this message]
2007-02-08 16:55 ` [PATCH] Make gitk save and restore the user set window position Mark Levedahl
-- strict thread matches above, loose matches on Subject: below --
2007-02-11 14:27 Mark Levedahl
2007-02-11 14:27 ` Mark Levedahl
2007-02-11 21:49 ` Junio C Hamano
2007-02-07 3:21 Junio C Hamano
2007-02-07 5:40 ` Shawn O. Pearce
2007-02-08 0:30 ` Mark Levedahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=491753.81112.qm@web38915.mail.mud.yahoo.com \
--to=brett_schwarz@yahoo.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=mdl123@verizon.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).