|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Mar 08 2004 - 11:23:12 EST
Dear Calin,
> I just upgraded magic to the latest 7.2 version -- 7.2.62. It fixes
> an old bug which made my x server crash when trying to display the
> toolbar.
From which version did you upgrade? I don't recall making any changes
in recent revisions which would affect the toolbar. A while back,
though, I changed the behavior so that the toolbar doesn't come up
immediately, but has to be brought up from the "Options" menu.
If it comes up at the same time as the window, some window managers
don't give the correct answer for the window size, which the toolbar
needs to know to adjust its size accordingly.
> This release 7.2.62 has the following features:
> - on the upper right corner is a "(number1 number2) lambda" text
> displayed. If i move the mouse so that the number1 becomes negative
> the window becomes wider. If i move it again so that the number1
> becomes >=0 the windows shrinks
It is entirely possible that the "feature" is in Tcl/Tk, not magic.
Tk is responsible for the title bar in the Tcl-based version of magic.
Tk resizes its message windows in response to a change in the text.
Maybe what's going on is that the name of the edit cell is so long
that Tk runs out of space for all the text, and consequently resizes
the whole window to get the space it needs. If this is really
annoying, there are ways to force Tk to avoid resizing the title bar.
I haven't noticed this behavior before, but then I am usually working
in a layout window of 1400 pixels across. Does this behavior change
depending on whether the toolbar is present or not?
> - if i draw something in magic and want to quit using only the
> keyboard:
> ;quit
> The dialog box apperars asking me if i want to looose the magic cell
> which has been modified. The no button is the default however i press
> <TAB> the yes button becames default and then i press <ENTER>. The
> dialog dissapears but the magic doesn't quits but it displays the
> following in it's tkcon window:
> ;quit
> 0
> %
I ran magic under the debugger and set a breakpoint after the tk_dialog
function returns. I was surprised to see that the dialog had returned
the response "no" even though the "tab" key had clearly changed what
I assume to be the default setting to "yes". The function returned 0
("no") which is what shows up in the console. I have concluded that
the Tk "tk_dialog" function, while apparently responding to the "tab"
key, is not changing its behavior except to move the little black box
around. This "feature" belongs to Tk, not to magic. It probably
depends heavily on the window manager. I notice that my WM (twm)
doesn't respond to Tk's request for keyboard focus on a widget unless
the Tk option "focus -force" is used. You can work around this problem
by altering the script for tk_dialog, which can be found in (depending on
the installation and Tk version) /usr/local/lib/tk8.3/dialog.tcl.
Change the script at around line 124 to:
# 4. Create a binding for <Return> on the dialog if there is a
# default button.
set tkPriv(default) $default
if {$default >= 0} {
bind $w <Return> [subst {
\[list $w.button\$tkPriv(default)\] configure -state active -relief sunken
update idletasks
after 100
set tkPriv(button) \$tkPriv(default)
}]
bind $w <Tab> [subst {
\[list $w.button\$tkPriv(default)\] configure -default normal
incr tkPriv(default)
if {\$tkPriv(default) == [llength [grid slaves $w.bot]]} {set tkPriv(default) 0}
\[list $w.button\$tkPriv(default)\] configure -default active
focus -force $w.button\$tkPriv(default)
update idletasks
}]
}
You may also want to change item 7 at line 165 so that "focus" becomes
"focus -force":
# 7. Set a grab and claim the focus too.
set oldFocus [focus]
set oldGrab [grab current $w]
if {[string compare $oldGrab ""]} {
set grabStatus [grab status $oldGrab]
}
grab $w
if {$default >= 0} {
focus -force $w.button$default
} else {
focus -force $w
}
These changes should not otherwise affect the operation of tk_dialog.
Regards,
Tim
|
|
|
|