#76 Toolbar icons not shown in absence of .tkdiffrc
Hi,
when a user starts tkdiff without having a .tkdiffrc file, the toolbar icons are not shown. Instead, text labels are shown, despite the fact the "Show icons instead of labels in the toolbar" option is checked by default in the preferences.
A simple workaround, is to save the preferences once (without altering anything), and to restart tkdiff.
This bug was introduced in version 5.1 (5.0 still shows icons when .tkdiffrc is missing).
I traced the problem back these lines of code:
8991 # Evaluate any custom code the user MAY have provided
8992 if { "$opts(customCode)" != {}} {
8993 Dbg "Custom code IS in use...beware"
8994 if {[catch [list uplevel #0 $opts(customCode)] error]} {
8995 set startupError "Error in custom code: \n\n$error"
8996 }
8997 cfg-toolbar ;# which MAY have tried to set w(selcolor)
8998 }
The toolbar is only (re?)configured if there is a customCode section in the user's .tkdiffrc.
When I put the cfg-toolbar statement after the condition, the toolbar uses the icons, as expected.
I'm not sure that this the proper way to fix it, as I am not familiar with the code (nor tcl). Perhaps there is a better way.
Strange...
You are correct it shouldn't work like that - but your solution is not correct, despite the fact that it appears fixed afterward. Actually, I found that simply pressing "Apply" when reviewing the User preferences (to verify that "Icons" was indeed set), ALSO "fixed" the display issue. The only REASON all these different courses of action appear to work is because the internal functioning of the "cfg-toolbar" procedure is designed to force alignment of the toolbar buttons - period! You simply moved the invocation you found into a flow that executes it an extra time, where my choice was to just trigger an additional execution (neither of which should have been necessary)!
Nevertheless, it is a valid concern and will be looked at regarding why it failed to get it right the first time it ran (and why a missing tkdiffrc file even matters). Good catch!
Found it.
As suspected, it really had little to do with the existence (or not) of the tkdiffrc preferences file. Instead, it fell prey to a (perhaps) over-zealous attempt to avoid excess work, which was one of the goals in V5.1. It simply neglected to realize that conditions at tool startup are NOT quite the same as when the display is up and running, and made an incorrect choice regarding which toolbutton set would be considered as "onscreen" at that moment. We have made the appropriate change, and it will become part of whatever the next release is; but as V5.2 only just went out, and a simple workaround (just re-Apply the current preference settings) exists, we'd like to wait and see if other issues show up before issuing a point release fix. Thanks again for taking the time to report your observations - it's what makes Open-Source-Software work!
Thanks for your swift response and fix!
I agree that there's no need to rush out an update.