# ticket

tkt_uuid: 2902814fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: wm iconphoto broken in 8.5.8 64 bit linux
comment:
  The wm iconphoto command no longer has any effect with Tk 8.5.8. It works fine with Tk 8.5.7 (both 64-bit builds). It also appears to work with a 8.5.8 32-bit build (at least it does with the 32-bit 8.5.8 ActiveState basekit)

  Tested on OpenSuSE 11.2, kernel 2.6.31.5-0.1-default x86_64 with KDE 4.3.1.


tkt_uuid: 2902826fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Wont Fix
title: 'justify' attribute not set correctly by default on labels
comment:
  Try this :

  ttk::label .l
  pack .l -fill x
  puts [.l configure -justify]    => {} instead of "left" (text is clearly justified to the left).

  Labels should have their "justify" option set correctly by default.


tkt_uuid: 2904114fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Duplicate
title: Aqua menubutton checkbutton indicator not showing properly
comment:
  Using Tcl 8.5.8, the following code works properly, i.e. the indicators for the checkbutttons are shown where the corresponding variable is 1 and the indicator is not shown, where the corresponding variable is 0:

  menubutton .m -text test -menu .m.f
  pack .m -padx 20 -pady 20
  menu .m.f
  .m.f add checkbutton -label entryOn -variable v1 -command {puts $v1}
  set v1 1
  .m.f add checkbutton -label entryOff -variable v2 -command {puts $v2}
  set v2 0

  In the current Tcl 8.6b1.1 (directly from cvs), none of the indicators are shown and can not be switched on by selecting the entry in the menubutton. It works OK in the X11 build for Mac, but not in the Aqua build (embedded build, if that matters). So the problem seems to be in the Aqua code.


tkt_uuid: 2904492fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: CheckButton Errors
comment:
  in library/button.tcl two problems came in with 8.5.8:

  both in ::tk::CheckEnter :

  1.:  according to documentation -selectcolor might be "". This occurs for example in the tablelist-extension.
  while computing the color the empty string leads to an runtime error.
  we used the background-color if selectcolor is not set - this works for us

  2.  "set ::[$w cget -variable]" does not work with itcl-vars which were set to -variable using [scope]
    we replaced ":set :[$w cget -variable]" with "[namespace inscope :: set [$w cget -variable]]" which works for all cases

  the changes in CheckEnter:
  -----------------------
  # Compute what the "selected and active" color should be.

  if {![$w cget -indicatoron]} {
      set selcol [$w cget -selectcolor]
      if { $selcol eq "" } {
  set selcol [$w cget -background]
      }

      set Priv($w,selectcolor) $selcol
      lassign [winfo rgb $w $selcol]      r1 g1 b1
      lassign [winfo rgb $w [$w cget -activebackground]] r2 g2 b2
      set Priv($w,aselectcolor) \
  [format "#%04x%04x%04x" [expr {($r1+$r2)/2}] \
       [expr {($g1+$g2)/2}] [expr {($b1+$b2)/2}]]

      if {[namespace inscope :: set [$w cget -variable]] eq [$w cget -onvalue]} {
  $w configure -selectcolor $Priv($w,aselectcolor)
      }
  }


tkt_uuid: 2904708fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Error from checkbutton bindings when -selectcolor is ""
comment:
  I get the following error when I move the mouse pointer over an indicatorless checkbutton:

  unknown color name ""
      while executing
  "winfo rgb $w [$w cget -selectcolor]"
      (procedure "tk::CheckEnter" line 23)
      invoked from within
  "tk::CheckEnter .c"
      (command bound to event)

  The checkbutton manual page indicates that "" is a valid value for the -selectcolor option: "If specified as an empty string then no special color is used for displaying when the widget is selected". But the new checkbutton bindings introduced in Tk 8.5.8 don't account for this.

  Tested on OpenSuSE 11.2, x86_64, KDE 4.3.1


tkt_uuid: 2907388fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Accepted
title: Entering circumflex '^' into entry crashes TkAqua 8.6b1.1
comment:
  The following script:

  % entry .e
  % pack .e

  will crash TkAqua8.6b1.1 when entering a circumflex (the ^ character) into the entry. This is true for both the i386 and the x86_64 builds. The error message is:

  2009-12-02 11:17:30.936 wish-aqua8.6[6459:903] An uncaught exception was raised
  2009-12-02 11:17:30.939 wish-aqua8.6[6459:903] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
  2009-12-02 11:17:31.023 wish-aqua8.6[6459:903] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
  *** Call stack at first throw:
  (
          0   CoreFoundation                      0x00007fff85879444 __exceptionPreprocess + 180
          1   libobjc.A.dylib                     0x00007fff8496d0f3 objc_exception_throw + 45
          2   CoreFoundation                      0x00007fff85879267 +[NSException raise:format:arguments:] + 103
          3   CoreFoundation                      0x00007fff858791f4 +[NSException raise:format:] + 148
          4   Foundation                          0x00007fff801803d5 -[NSCFString characterAtIndex:] + 97
          5   Tk                                  0x00000001000c52e0 Tk_SetCaretPos + 674
          6   Tk                                  0x00000001000cb9db Tk_MacOSXSetupTkNotifier + 701
          7   Tcl                                 0x00000001001f4486 Tcl_DoOneEvent + 297
          8   Tk                                  0x000000010001d8e0 Tk_MainLoop + 24
          9   Tk                                  0x000000010002b36a Tk_MainEx + 1491
          10  wish-aqua8.6                        0x000000010000548b 0x0 + 4294988939
          11  wish-aqua8.6                        0x00000001000053d0 0x0 + 4294988752
          12  ???                                 0x0000000000000001 0x0 + 1
  )
  terminate called after throwing an instance of 'NSException'
  Abort trap


tkt_uuid: 2907758fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 7 High
foundin: obsolete: 8.5.7
resolution: Fixed
title: crash with CFStringGetCString
comment:
  Hi, some aMSN users started reporting that aMSN crashes for them on their mac, and we don't know what's causing it and can't reproduce.. It seems to be coming from Tk_CreateMainWindow, so i don't think it has anything to do with amsn's source code or extensions. Here are a few stack traces as reported by the users..
  http://www.amsn-project.net/forums/viewtopic.php?t=7392
  http://www.amsn-project.net/forums/viewtopic.php?t=7429
  If you look at the traces, it seems to be happening on 10.5.8 and 10.5.4 with both tcl/tk 8.5.3 (amsn 0.97.2 and 0.98) and 8.5.7 (amsn 0.98.1).

  For completeness sake, here's a paste of one of the crash reports :
   
   
  Exception Type: EXC_BAD_ACCESS (SIGBUS) 
  Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 
  Crashed Thread: 0

  Thread 0 Crashed: 
  0 com.apple.CoreFoundation 0x966ac173 CFStringGetCString + 307 
  1 com.tcltk.tklibrary 0x0b0b8fcf Tk_DrawChars + 654 
  2 com.tcltk.tklibrary 0x0b0b945d Tk_DrawChars + 1820 
  3 ...ple.ApplicationServices.ATS 0x94617ef4 ATSFontFamilyApplyFunction + 138 
  4 com.tcltk.tklibrary 0x0b0b91a1 Tk_DrawChars + 1120 
  5 com.tcltk.tklibrary 0x0b02d907 TkCreateMainWindow + 171 
  6 com.tcltk.tklibrary 0x0b0366a8 Tk_UndefineCursor + 35419 
  7 com.tcltk.tklibrary 0x0b036ad7 TkCreateFrame + 140 
  8 com.tcltk.tklibrary 0x0b02cdc5 Tk_GetNumMainWindows + 2059 
  9 com.tcltk.wish.amsn 0x000111ee 0x1000 + 66030 
  10 com.tcltk.tklibrary 0x0b01ef98 Tk_MainEx + 1563 
  11 com.tcltk.wish.amsn 0x000111cb 0x1000 + 65995 
  12 com.tcltk.wish.amsn 0x00011186 0x1000 + 65926 
  13 com.tcltk.wish.amsn 0x000110ad 0x1000 + 65709


  I hope this can be fixed soon. thanks.


tkt_uuid: 2908052fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Works For Me
title: TkAqua crashes on scrolling event
comment:
  The 8.6b1.1 version of TkAqua crashes when scrolling in a certain way. Holding the mouse button pressed on a scrolling arrow will cause wish to crash with the following message:

  wish8.6-aqua(1797,0xb0103000) malloc: free_garbage: garbage ptr = 0x1418c80, has non-zero refcount = 1
  2009-12-03 11:32:32.995 wish8.6-aqua[1797:10b] *** Assertion failure in +[NSEvent startPeriodicEventsAfterDelay:withPeriod:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSEvent.m:1765
  2009-12-03 11:32:32.995 wish8.6-aqua[1797:10b] An uncaught exception was raised
  2009-12-03 11:32:32.997 wish8.6-aqua[1797:10b] Periodic events are already being generated
  2009-12-03 11:32:32.997 wish8.6-aqua[1797:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Periodic events are already being generated'
  2009-12-03 11:32:32.998 wish8.6-aqua[1797:10b] Stack: (
      2470170603,
      2514165307,
      2470170059,
      2478157508,
      2525052112,
      2526164841,
      2524622328,
      2523486967,
      2523276965,
      2195129,
      2196449,
      3235242,
      1389874,
      2705113,
      2707855,
      3011097,
      2707855,
      2737327,
      2738193,
      2198337,
      2523500175,
      2523499980,
      2524627019,
      2526164928,
      2524622328,
      2523486967,
      2523276965,
      2195129,
      2196449,
      3235242,
      1421705,
      1483183,
      25904,
      25689
  )
  Trace/BPT trap

  The same is true, when scrolling by holding the mouse pressed on the slider trough (tested on MacOS X 10.5 and 10.6).


tkt_uuid: 2908379fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk:* widgets - selection text illegible on Mac OS X
comment:
  peterc reports in #2908368:

  Selected text on Mac needs have the font as a light colour (white?) rather
  than black, otherwise it's unreadable: eg,

  http://pc.autons.net/stuff/ttk_treeview_unreadable_macosx.png

  and reports on the chat that ttk::entry widgets also have the same problem.

  I can't tell which (if any) of the kThemeTextColor* constants in Appearance.h is the right one to use.  das?


tkt_uuid: 2911346fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: Add 'pixels' option to $w yview scroll
comment:
  The text and canvas widgets have commands

  $w xview scroll number what
  $w yview scroll number what

  For the text widget, 'what' is 'units', 'pages' or 'pixels'.  For the canvas, 'what' must be 'units' or 'pages'.  It would be useful to have the 'pixels' option so that the same scrolling code can be re-used for text and canvas.  For example, the text widget has sophisticated cross-platform bindings for mousewheel scrolling, but this code uses the 'pixels' option, and so cannot be directly re-used for a canvas.


tkt_uuid: 2911570fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Color hash problem on x86_64
comment:
  Description of problem:
  A stack-allocated structure is used as a hash key for a color in
  Tk_GetColorByValue(). Compilation on x86_64 inserts some unused gaps in
  structures for alignment: this results in having undefined bits participating
  to the hash code computation, introducing the risk of missing a color that is
  already in the table.

  Version-Release number of selected component (if applicable):
  tk-8.5.7-2.fc12.x86_64

  How reproducible:
  No recipe: very random in nature.
  I discovered this problem inadvertently while using valgrind on "insight" for
  another problem.

  Additional info:
  The attached patch fixes this problem by clearing the structure before
  assigning its fields.  

  ---------------------------------
  diff -Naur tk8.5.7.orig/generic/tkColor.c tk8.5.7.new/generic/tkColor.c
  --- tk8.5.7.orig/generic/tkColor.c2007-12-13 16:24:13.000000000 +0100
  +++ tk8.5.7.new/generic/tkColor.c2009-12-09 12:20:39.000000000 +0100
  @@ -302,6 +302,7 @@
        * First, check to see if there's already a mapping for this color name.
        */
   
  +    memset(&valueKey, 0, sizeof(valueKey));/* Clear interfield gaps. */
       valueKey.red = colorPtr->red;
       valueKey.green = colorPtr->green;
       valueKey.blue = colorPtr->blue;


tkt_uuid: 2912356fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: ttk::sizegrip behaviour is wrong in compiz
comment:
  The default behaviour of ttk::sizegrip on compiz is not right. The window manager seems to reposition the window on every <Configure> event, and the toplevel start jumping to the lower left corner of the screen when the grip is dragged.
  Other toolkits uses the _NET_WM_MOVERESIZE message as specified in http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551196 to get the "right" behaviour.
  As a workaround, the patch in http://paste.tclers.tk/1890 improves things a bit. 


tkt_uuid: 2912473fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: Tk cannot be used on X11 displays whose names contain "::"
comment:
  Detailed problem description AND PATCHES are in forum thread: http://sourceforge.net/mailarchive/forum.php?thread_name=1260173691.4656.89.camel%40tinygod3&forum_name=tcl-core

  Quote:

  "I recently discovered a bug in Tk with X11 display strings. If the
  display string contains "::" then Tk cannot load, because it uses the
  display name as a variable name and this produces an error about the
  parent namespace not being defined. This happened to me when trying to
  use a Tk app (Mentor Graphics ModelSim) over XVnc, where the display
  string was "::1:1.0". At least one other person has reported the same
  problem: http://ubuntu-ky.ubuntuforums.org/showthread.php?p=8255492.
  (That post suggests that this has only recently become a problem,
  probably because until now display names never contained "::".)"


tkt_uuid: 2912603fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Support for complex polygons in canvas
comment:
  [This was originally Tcl FRQ #1266238]
  This is a request for support of complex polygons in canvases. 

  RATIONALE:
  Such grapic items are common in computer graphics.

  SUGGESTED IMPLEMENTATION

  Alternative 1: Extend the current polygon item.

  The current "create polygon" command is extended so the coordinates can be specified as a list of lists of coordinates, each list comprise a part of the polygon, with the outer polygin first. This alternative requieres that the current command determines what kind of list it has as parameter, and takes the appropriate action.

  Aternative 2: New compound item.

  New command "create compond <list> <options>...", with syntax as "create polygon" as above where <list> is a list of list of coordinates.

  Alternative 3: New complex item

  New command "create complex <ti1> <ti2> ..." where <ti?> is a tag or identifier identifying existing items in the canvas. These items may now be considered as a 'group', with a single identity. It may then be possible to specify as an option "-eofill 1" to specify that polygons in the group is to be painted with even-odd fill.


tkt_uuid: 2912799fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.6b1.1
resolution: Invalid
title: Compilation breaks on win7 with vs2008
comment:
  If I try to compile the latest csv branch tk stopf compilation with this error

  *** Linker has 'Win98 alignment problem'
  *** Intermediate directory will be '.\Release_VC9\tk_Dynamic'
  *** Output directory will be '.\Release_VC9'
  *** Suffix for binaries will be ''
  *** Optional defines are '-DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTDC_HEADERS -DTCL_
  CFG_OPTIMIZED'
  *** Compiler version 9. Target machine is IX86
  *** Compiler options '-W3  -Ot -Oi -fp:strict -Gs -GS -GL  -RTC1 -W3'
  *** Link options '-ltcg'
  *** Dependency rules are not being used.

  NMAKE : fatal error U1073: don't know how to make 'htmlhelp'

  This is fixed if I modify the line 58.
  Not that the patch below modifies two more lines for my system configuration.

  In C:\Users\Lis\Documents\work\tcl-cvs\tk\win: "C:\Program Files (x86)\CVSNT\cvs.exe" -q diff -u -r 1.7 
  buildall.vc.bat
  CVSROOT=:pserver:anonymous@tktoolkit.cvs.sourceforge.net:/cvsroot/tktoolkit

  Empty password used - try 'cvs login' with a real password
  Index: buildall.vc.bat
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/buildall.vc.bat,v
  retrieving revision 1.7
  diff -u -r1.7 buildall.vc.bat
  --- buildall.vc.bat   2 Oct 2008 19:13:35 -0000   1.7
  +++ buildall.vc.bat   11 Dec 2009 17:20:15 -0000
  @@ -30,9 +30,10 @@
   :: might not be correct.  You may need to edit these.
   ::
   if not defined MSDevDir (
  -    call "C:\Program Files\Microsoft Developer Studio\vc98\bin\vcvars32.bat"
  +    ::call "C:\Program Files\Microsoft Developer Studio\vc98\bin\vcvars32.bat"
       ::call "C:\Program Files\Microsoft Developer Studio\vc\bin\vcvars32.bat"
       ::call c:\dev\devstudio60\vc98\bin\vcvars32.bat
  +    call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat"
       if errorlevel 1 goto no_vcvars
   )
   
  @@ -47,7 +48,7 @@
   :: just to be explicit and convey understanding to the user.  Setting
   :: the INSTALLDIR envar prior to running this batchfile affects all builds.
   ::
  -if "%INSTALLDIR%" == "" set INSTALLDIR=C:\Program Files\Tcl
  +if "%INSTALLDIR%" == "" set INSTALLDIR=C:\tcl
   
   
   :: Where is the Tcl source directory?
  @@ -58,7 +59,8 @@
   ::
   set OPTS=none
   if not %SYMBOLS%.==. set OPTS=symbols
  -nmake -nologo -f makefile.vc release htmlhelp OPTS=%OPTS% %1
  +::nmake -nologo -f makefile.vc release htmlhelp OPTS=%OPTS% %1
  +nmake -nologo -f makefile.vc release OPTS=%OPTS% %1
   if errorlevel 1 goto error
   
   :: Build the static core, dlls and shell.


tkt_uuid: 2912962fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: Notebook does not set TTK_STATE_USER1
comment:
  The TabState function in ttkNotebook.c is not setting the TTK_STATE_USER1 flag correctly. This happend when tabs added to the notebook before the tab currently visible in first position was added, are now hidden. The TabState function check 'index == 0' but this is not working correctly when tab are hidden. Looking for the first visible tab should skip hidden tabs. The attached script triggers this problem with the tileqt theme. The attached C file has a patched TabState function.


tkt_uuid: 2913483fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Images in disabled ttk::buttons don't display on Tk/Cocoa
comment:
  If a ttk::button is set to disabled on Tk-Cocoa, the image contained in the button disappears and is replaced by a white rectangle. cf: http://www.codebykevin.com/puretk.png

  The image in a disabled Tk button is correctly displayed, i.e. grayed out. 


tkt_uuid: 2914943fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: Man page is misleading
comment:
  The manpage gives the following example:

  option add *button.foreground red startupFile

  claiming to change the look for all buttons. I tried a similar line:

  option add *entry.font "-size 14" startupFile

  On at least OS X this has no affect. Changing the option to *Entry.font" works. So the name is case sensitive and should be capital. Additionally the manpage really should describe the option syntax without referring to "usual X format", as this is not relevant on Windows and OS X.


tkt_uuid: 2915709fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: None
title: notebook bug fix 2496162 should be backported to tk8.5
comment:
  I am getting very occasional crashes with tk8.5.6 on solaris 10.

  The stack trace is:

  t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address)
  0xff235b58: Tk_GetOptionValue+0x010c:   ld       [%i3], %i1
  (dbx) where
  current thread: t@1
  =>[1] Tk_GetOptionValue(0x24198, 0x8822f8, 0x8821c0, 0x0, 0x987ef8, 0x916378), at 0xff235b58 
    [2] TtkGetOptionValue(0x24198, 0x8822f8, 0x394760, 0x916378, 0x8821c0, 0xff35bfbc), at 0xff301f5c 
    [3] NotebookTabCommand(0x24198, 0x4, 0xcc3670, 0x916308, 0x100b04, 0x63), at 0xff309700 
    [4] WidgetInstanceObjCmd(0x916308, 0xff36765c, 0x58, 0x100b04, 0x0, 0xff367674), at 0xff3199f4 
    [5] TclEvalObjvInternal(0x24198, 0x4, 0x100b04, 0x3, 0xffffffff, 0x1e0c10), at 0xff0ad2d4 
    [6] TclExecuteByteCode(0x18, 0x100b10, 0x100a88, 0xff1cf6c0, 0x394cf7, 0x24198), at 0xff10cc1c 
    [7] TclObjInterpProc(0x24198, 0x2, 0x4, 0x100a50, 0xff1d4270, 0xff1cf6c0), at 0xff16f790 
    [8] TclEvalObjvInternal(0x24198, 0x4, 0x100a38, 0x3, 0xffffffff, 0x1e0c05), at 0xff0ad2d4 
    [9] TclExecuteByteCode(0x18, 0x100a44, 0x100990, 0xff1cf6c0, 0xdc6ee3, 0x24198), at 0xff10cc1c 
    [10] TclCompEvalObj(0x22cb0, 0x1, 0x0, 0x0, 0x3, 0x24198), at 0xff10b014 
    [11] TclExecuteByteCode(0x20, 0x100a04, 0x100990, 0xff1cf6c0, 0x3f9b73, 0x3f9a98), at 0xff10ccf4 
    [12] TclObjInterpProc(0x24198, 0x2, 0x5, 0x100958, 0xff1d4270, 0xff1cf6c0), at 0xff16f790 
    [13] TclEvalObjvInternal(0x24198, 0x5, 0xffbfcb70, 0x3, 0x0, 0x1e0bf4), at 0xff0ad2d4 
    [14] Tcl_EvalObjv(0x24198, 0x5, 0xffbfcb70, 0x80000, 0x5, 0x0), at 0xff0ada2c 
    [15] AliasObjCmd(0x2, 0x24198, 0x1, 0x100944, 0x1006fc0, 0x1), at 0xff124234 
    [16] TclEvalObjvInternal(0x24198, 0x3, 0x100944, 0x3, 0xffffffff, 0x1e0bf3), at 0xff0ad2d4 
    [17] TclExecuteByteCode(0x18, 0x10094c, 0x1008a0, 0xff1cf6c0, 0xc25de8, 0x24198), at 0xff10cc1c 
    [18] TclObjInterpProc(0x24198, 0x2, 0x2, 0x100868, 0xf800, 0xff1cf6c0), at 0xff16f790 
    [19] TclEvalObjvInternal(0x24198, 0x2, 0xcc3880, 0x3, 0x0, 0x1dc7ff), at 0xff0ad2d4 
    [20] Tcl_EvalObjv(0x24198, 0x2, 0xcc3880, 0x20000, 0x3, 0x0), at 0xff0ada2c 
    [21] TclEvalObjEx(0x24198, 0x4, 0x20000, 0xe7e430, 0x100808, 0x9168e8), at 0xff0aef90 
    [22] TkInvokeMenu(0x0, 0xee2548, 0x0, 0xb977c0, 0xff368eec, 0x0), at 0xff2789f0 
    [23] MenuWidgetObjCmd(0xee2548, 0x0, 0xf149c0, 0x24198, 0x3, 0x28), at 0xff2783bc 
    [24] TclEvalObjvInternal(0x24198, 0x3, 0xf149c0, 0x4, 0x0, 0x1dc7fe), at 0xff0ad2d4 
    [25] Tcl_EvalObjv(0x24198, 0x3, 0xf149c0, 0x0, 0x2, 0x0), at 0xff0ada2c 
    [26] TclEvalObjEx(0x24198, 0x2, 0x0, 0x849d90, 0x1007d0, 0x1bc0d0), at 0xff0aef90 
    [27] Tcl_UplevelObjCmd(0x1007f8, 0x24198, 0x2, 0x7fee0, 0x100760, 0xff1cf6c0), at 0xff16e348 
    [28] TclEvalObjvInternal(0x24198, 0x3, 0x1007f8, 0x10, 0xffffffff, 0x1dc7fd), at 0xff0ad2d4 
    [29] TclExecuteByteCode(0x18, 0x100800, 0x100798, 0xff1cf6c0, 0xaff827, 0x24198), at 0xff10cc1c 
    [30] TclObjInterpProc(0x24198, 0x2, 0x3, 0x100760, 0x0, 0xff1cf6c0), at 0xff16f790 
    [31] TclEvalObjvInternal(0x24198, 0x3, 0x100658, 0x3, 0xffbfe574, 0x1dc7b4), at 0xff0ad2d4 
    [32] TclEvalEx(0x24198, 0x3, 0x3, 0x0, 0x10065c, 0xffbfe3b4), at 0xff0ae4f4 
    [33] Tk_BindEvent(0x5b, 0x38023, 0x51f58, 0xffbfe644, 0x391c8, 0x24198), at 0xff226d38 
    [34] TkBindEventProc(0x4, 0xbe0db8, 0xb38570, 0x102a4d8, 0xff35bfbc, 0x10), at 0xff22df7c 
    [35] Tk_HandleEvent(0xbe0db8, 0x0, 0x0, 0xff35bfbc, 0xff368eec, 0x24198), at 0xff2390bc 
    [36] WindowEventProc(0xbe0db0, 0xfffffffd, 0x8c, 0x1b800, 0xff35bfbc, 0x0), at 0xff239aec 
    [37] Tcl_ServiceEvent(0xfffffffd, 0x0, 0x3a380, 0xff1cf6c0, 0x10d7c, 0xbe0db0), at 0xff156dfc 
    [38] Tcl_DoOneEvent(0xfffffffd, 0x0, 0x0, 0x23e60, 0x10d7c, 0x10c00), at 0xff1570f8 
    [39] Tk_MainLoop(0x24198, 0xff368eec, 0xff15706c, 0xff1d496c, 0xff35bfbc, 0x8c), at 0xff23a014 
    [40] Tk_MainEx(0xff1d445c, 0xff14a564, 0xff368ef4, 0x24198, 0xff18efe0, 0xff1d496c), at 0xff24e954 
    [41] main(0x2, 0xffbfebec, 0xffbfebf8, 0x20e98, 0xfffeff1c, 0x10000), at 0x10d94 


  This suggests something wrong with the ttk::notebook tab option table.  I think it is very likely that this is the same as bug 2496162 which was fixed in generic/ttk/ttkNotebook.c revision 1.17 for tk 8.6.  The thought then was that changes to literals and the nre engine showed up the problem, but perhaps the same issue can arise in tk 8.5, just less frequently.

  I think that it would be a good idea to backport the #2496162 fix to the 8.5 branch, as follows:

  *** ttkNotebook.c.orig  Mon Jan 28 00:36:08 2008
  --- ttkNotebook.c       Wed Dec 16 17:36:14 2009
  ***************
  *** 1241,1248 ****
        Notebook *nb = recordPtr;
    
        Ttk_DeleteManager(nb->notebook.mgr);
  -     Tk_DeleteOptionTable(nb->notebook.tabOptionTable);
  -     Tk_DeleteOptionTable(nb->notebook.paneOptionTable);
    
        if (nb->notebook.tabLayout)
          Ttk_FreeLayout(nb->notebook.tabLayout);
  --- 1241,1246 ----


  I have done that on my installation, and will see if any more problems occur.


tkt_uuid: 2917663fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Treat SI:localuser, SI:localgroup as secure
comment:
  Since at least X11R6.8.0 there is a ServerInterpreted family of X host access.  On Ubuntu 9.10, [send] does not work because by default there are SI:localuser authorizations in the authorized hosts list.  The same is apparently true of Fedora 8 and newer.

  SI:localuser and SI:localgroup authorizations can be as secure as Xauth-only authorizations.

  This patch makes [send] continue to work even if SI:localuser and SI:localgroup authorizations appear in the authorization list.

  'xhost +' and 'xhost + localhost' still make [send] stop with an error about the X server being insecure.

  Before applying this patch, revert tkUnixSend.c r1.25 on TRUNK and r1.20.2.1 on the tk8.5 branch; that change was wrong.  It only allows a single SI: authorization.  Ubuntu 9.10 has 3 by default (this user, gdm, root).


tkt_uuid: 2917665fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Duplicate
title: SI: authorizations still broken - 1909931 is not fixed
comment:
  The patch is wrong when there is more than one SI: line, which is the case on Ubuntu 9.10 by default.  I've submitted a new patch artifact 2917663 to fix the problem.


tkt_uuid: 2917688fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: ttk::notebook pages don't take focus when tab is selected
comment:
  On Mac OS X 10.5.8, using ActiveTcl 8.5.8, I see the following peculiar behavior; a script that shows the problem is attached.

  The script creates a ttk::notebook with two tabs; each tab contains a text widget.  Do the following to reproduce the error:

  * Start the script.
  * Click in the text widget on tab Text 1.  It will take focus.
  * Click on tab Text 2.
  * The text widget on tab Text 2 does not take the focus (which is OK).
  * Type "Hello, world".
  * Click on tab Text 1.
  * You'll see "Hello, world" in the text widget on tab Text 1.

  In other words, the first text widget is retaining the focus even after it's hidden, and is still responding to keyboard events.  Per Joe English, this isn't what's supposed to happen.


tkt_uuid: 2918171fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Wish crash when destroying . with reflected channel
comment:
  When destroying ".", wish crashes with the following message (followed by lots of debug info):
  *** glibc detected *** /home/sbron/usr/bin/wish8.6: free(): invalid pointer: 0x00000000006297e0 ***

  This doesn't happen when just exiting the application. The script to reproduce this situation involves a reflected channel, so it may just as easily be a refchan problem. But since the issue only occurs in combination with wish, I opened the bug in the Tk tracker.


tkt_uuid: 2919205fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: error in tkfbox line 1822
comment:
  IS :  tk_messageBox -type ok -parent $w -message -icon warning \
      [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]

  SHOULD BE :  tk_messageBox -type ok -parent $w -icon warning -message \
      [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]


tkt_uuid: 2919709fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Windows menus don't honor Windows theme changes
comment:
  In Windows XP, when the system theme is changes, persistens menus (i.e. submenus of the main application menu) do not honor the change.

  To demonstrate just select and apply some system theme having considerably darker or lighter colors than those of the currently active theme -- the background color of persistent pull-down menus will remain that of the old theme.

  Pat Thoyts proposed that this can be caused by WM_SYSCOLORCHANGE message not being propagated to menus.


tkt_uuid: 2920409fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 12. Unix Menus
priority: 7 High
foundin: TIP Implementation
resolution: Accepted
title: TIP#360: Modernize menus on X11
comment:
  The following patches are intended to make Tk menus on X Windows function more like GNOME menus. The first patch makes the dropdown menus follow the mouse once they have initially been activated. This is the behaviour seen on Windows menus and is also used by GNOME. Currently a user must click to open every cascade menu. If the original functionality is desired, the *Menu.clickToFocus option can be set (or call tk::classic:;restore menu).
  The second stops pinning the Help menu to the extreme right of the menubar. Again the old behaviour can be restored. This time by setting the *Menu.useMotifHelp option or by calling tk::classic::restore menu.

  The patches are based on core-8-5-branch and these versions incorporate suggestions from tcl-core (delayed post cascade, option database override)


tkt_uuid: 2925561fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: Reopen of 2834772; ttk::combobox receives focus when disable
comment:
  I still get the a <FocusIn> event with latest ActiveState 8.5.8.
  Fresh download from 4.1.2010.

  OS: Sparc Solaris 10
  Tk_Patchlevel 8.5.8

  How to reproduce

  ttk::combobox .c -state disabled
  pack .c
  bind all <FocusIn> {puts "%W focus in"}

   ...click inside combox entry field..

  I see the message of the bind

  Maybe it is an OS specific issue with focus


tkt_uuid: 2926819fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Fixed
title: event generate -warp 1 doesn't work on Mac OSX Aqua
comment:
  In the Aqua build of Tk, warping the pointer doesn't work in either 8.5.8 or 8.6b1. SImple script to reproduce:

  package require Tk
  bind . <1> { puts "Yes"; event generate . <Motion> -warp 1 -x 5 -y 5 }

  in X11/MacOS, this warps the pointer as expected when clicking anywhere in the main window. This functionality is needed e.g. for a 3D game, where the pointer is hidden and only the motion is tracked.


tkt_uuid: 2927569fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: man page buglet for photo
comment:
  Greetings,

  the man page of photo documents the
  "-to" option of the "put" command as
  "Specifies the coordinates of the top-left corner (x1,y1) of the region of imageName into which data from filename are to be read."
  however, there is no reading from files
  and no filename option involved for
  this command?

  kind regards,
  Randolf


tkt_uuid: 2930958fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Error when selecting a file in unix and directory is protect
comment:
  proc ::tk::dialog::file::ListInvoke in file tkfbox.tcl

  from:

              tk_messageBox -type ok -parent $w -message -icon warning \
                      [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]

  to

              tk_messageBox -type ok -parent $w -message -icon warning -message \
                      [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]


tkt_uuid: 2931374fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: bad memory management in complex tag searches
comment:
  The module tkCanvas.c contains a serious bug
  which leds to memory corruption in some
  cases (a "segmentation fault" in malloc in
  my situation).

  The problem lies within TagSearchScanExpr and
  deals with memory allocation for TagSearchExpr.uids
  array.

  In the parsing-while loop the first if-statement:

     if (expr->allocated == expr->index) {
        expr->allocated += 15;
        ...
     }

  extends the exor->uids array, if expr->index
  has reached the maximum (expr->index points one
  ahead the last position). Please notify, that this
  construct is sufficient, if expr->index
  is (after writing the current slot) incr only once
  during the loop body!

  Looking at:

     if (looking_for_tag) {

        switch (c) {
           case ' ':/* ignore unquoted whitespace */
           case '\t':
           case '\n':
  case '\r':

        ...

        default: /* unquoted tag string */
           
  if (negate_result) {
  >>>         expr->uids[expr->index++] = searchUids->negtagvalUid;
              negate_result = 0;
           } else {
  >>>         expr->uids[expr->index++] = searchUids->tagvalUid;
           }

           ...

           *++tag = '\0';
  >>>      expr->uids[expr->index++] =
           Tk_GetUid(searchPtr->rewritebuffer);
           looking_for_tag = 0;
           found_tag = 1;
        }

     } else {    /* ! looking_for_tag */

      ...

     }

  As you can see, if the negate_result flag is on
  there are 2 slots used. Zhis results in memory 
  corruption, if expr->allocated == expr->index-1
  at the top.

  I've corrected this by making sure that there are
  at least 2 free slots in expr->uids at the top
  of the while loop:

     if (expr->allocated <= expr->index+1) {
        expr->allocated += 15;
        ...
     }


tkt_uuid: 2931538fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: TkAqua MouseWheel wrong delta step size
comment:
  The delta value %D for MouseWheel events on in TkAqua is 1 or -1 or small integers.
  On Mac X11, Linux and Windows the delta value is 120 or -120 or small multiples of these.
  This means any MouseWheel tcl code has to be special-cased for TkAqua.  I believe the 120
  value is intended to allow future mouse wheel devices that provide finer granularity.

  The TkAqua MouseWheel events should produce 120 and -120 delta values to avoid special-case
  code in applications.  Maybe this change could be introduced into the new TkAqua 8.6 Cocoa
  implementation.

  Use the following Wish script to see the delta values produced by mouse wheel events:

  bind . <MouseWheel> { puts %D }


tkt_uuid: 2931720fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Cocoa Tk loses double click events
comment:
  In the Mac Cocoa Tk (CVS source code from January 8, 2010) double click events are not produced for toplevel windows with an active button.  The following Wish script illustrates the problem:

  label .l -text filename
  pack .l
  button .b -text Open -default active
  pack .b
  bind .l <Double-ButtonRelease-1> {puts "double click"}
  bind .l <ButtonRelease-1> {puts "single click"}

  Double clicking on the label with text "filename" does not print "double click" as it should (once in a while it does but rarely).  The double click events are not produced in Cocoa Tk but they are produced by Aqua Carbon Tk 8.5.8 and Linux and WIndows Tk.  Removing the "-default active" from the button makes this work on Cocoa Tk.  If instead we bind single and double clicks to the toplevel widget it works correctly in Cocoa.  Binding the mouse events to a child (the label) is needed to produce the bug.

  This problem occurs in a file browser dialog for the UCSF Chimera molecular graphics program where double clicking on a file name is supposed to open the file.  We are working on a 64-bit Cocoa port of this program.


tkt_uuid: 2933099fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Cocoa Tk wraps text when no wrapping specified
comment:
  Cocoa Tk 8.6 Jan 8, 2010 cvs source code sometimes draws text wrapping the last letter of the text line and drawing the wrapped text outside the bounds of the Tk widget.  It appears that the Mac Cocoa text drawing is doing the wrapping rather than Tk code since the Tk widget specifies no wrapping (wrap = 0) and the drawn wrapped single letter appears outside the bounds of the widget.

  I have only observed this using Tix 8.4.3, not native Tk widgets so it is possible it is a Tix bug.  But this bug does not occur with Tix 8.4.3 and Tk 8.5.8 on Mac Carbon Tk, Linux Tk or WIndows Tk.  So it looks more likely to be a bug in the new Tk Cocoa implementation.

  If the Tix widget text width is increased by one pixel from what is returned by Tk_ComputeTextLayout() then the wrapping bug does not occur.  (Tested this with a patch to Tix generic/tixUtils.c).  The reported text size from Tk_ComputeTextLayout() however is the same between Tk 8.5.8 Carbon which does not exhibit the wrapping bug and Tk 8.6 Cocoa cvs which does exhibit the bug (77 pixels for "icosahedron" in helvetica font).  So the wrapping appears to be caused by the Tk Cocoa text drawing code, and is not due to a miscomputation of the text width.

  The following Tcl script produces the bug with the result showed in the attached image.  The text widget is given a red background and the image shows the wrapped letter "n" at the end of icosahedron below the red box where Tk believes the text should be drawn.

  tixHList .h
  tixDisplayStyle text -stylename s -background red
  .h add i -itemtype text -text icosahedron -style s
  pack .h

  Sorry I do not have a native Tk widget demonstration of the bug.


tkt_uuid: 2935309fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 3 Low
foundin: obsolete: 8.6b1.1
resolution: None
title: No multi-column menus in Tk Cocoa
comment:
  Multi-column menus are not implemented in Tk Cocoa 8.6, Jan 8, 2010 cvs source code.
  The following tcl-mac mailing list message discusses this.

  http://sourceforge.net/mailarchive/message.php?msg_id=4B04C78B.4030203%40cgl.ucsf.edu


tkt_uuid: 2941732fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Out of Date
title: wish85.exe, error hitting funtion-key [F9]
comment:
  hitting function-key [F9] at the gives an error

  system : Windows
  file      : \Tcl\bin\wish85.exe
  version:  8.5.2.2
  wish for windows console error hiting function-key [F9]


tkt_uuid: 2945088fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Tk Cocoa menu check marks not shown
comment:
  With Tk Cocoa 8.6 Jan 8, 2010 source code check marks are not drawn for checkbutton menu entries when the menu pane is posted with the post command.  The ckeck marks are drawn correctly in Tk Carbon 8.5.8 and also in Linux and Windows Tk 8.5.8.

  Here's a Wish script that demonstrates the problem.

  menu .m
  variable m1 1
  variable m2 1
  .m add checkbutton -label blue -variable m1
  .m add checkbutton -label green -variable m2
  bind . <Button-1> {.m post 100 100}

  Pressing mouse button 1 posts the menu but only the second entry has a check mark next to it.  Both should have check marks.  Posting the menu again shows no check marks for either menu entry.  If more menu entries are created, each posting removes one check mark.  Weird.


tkt_uuid: 2945098fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: None
title: Tk Cocoa zombie toplevel
comment:
  If a toplevel window is made a transient of another toplevel (master) and the master window is withdrawn, a focus and grab on the transient can cause the master to be remapped without Tk knowing about it (winfo ismapped returns 0).  The master should not be mapped.  After deleting the transient window no button clicks have any effect on any widgets in the master.  The close, iconify and maximize buttons on the master window frame also don't work.  So the master window is dead and cannot be closed using the mouse.  This happens with Tk Cocoa Jan 8, 2010 source code, but behaves correctly in Tk Carbon 8.5.8 (master is not mapped), and on Linux and Windows Tk 8.5.8.

  Here is a Wish script demonstrating the problem

  wm withdraw .
  toplevel .m
  wm transient .m .
  focus .m
  grab .m
  destroy .m
  winfo ismapped .

  Oddly the problem does not appear if this script is run as a command-line argument to Wish.  Instead the commands need to be typed one at a time to Wish.


tkt_uuid: 2945130fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: {Shift,Control,Alt}_R press is answered by _L release
comment:
  Pressing the right Shift, Control, or Alt key on Windows (checked only with Tk 8.5.7) produces
  correctly an event with a ..._R keysym. However releasing the
  same key produces an event with a ..._L keysym. The same works as
  expected on X11 systems.

  The bug was originally reported for Perl/Tk. See
  https://rt.cpan.org/Ticket/Display.html?id=47173

  For your convenience, a test script is attached.

  Regards,
      Slaven


tkt_uuid: 2946840fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Works For Me
title: ttk::checkbutton and ttk::radiobutton with grid
comment:
  Incorrect appearance of ttk::checkbutton and ttk::radiobutton with grid on WinXP.
  The last element in a frame is larger than the other. It changes its size to normal after the first mouse motion over it. This only happens if check or radio buttons are packed with grid and xpnative theme is used. Not themed Tk widgets (tk:: ) are displayed correctly.
  Software used:
  ActiveTcl 8.5.8
  Windows XP SP2
  A short example is attached.


tkt_uuid: 2946850fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Out of Date
title: Tiny fonts on WinXp again
comment:
  This bug related to 8.5.7 is marked as fixed, but it looks like it's still there.
  ActiveTcl 8.5.8, Windows XP SP2, fixed and ansifixed:

  foreach f [font names] {puts "$f => [font configure $f]"}
  fixed => -family Courier -size 5 -weight normal -slant roman -underline 0 -overstrike 0
  oemfixed => -family Terminal -size 11 -weight normal -slant roman -underline 0 -overstrike 0
  TkDefaultFont => -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  TkMenuFont => -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  ansifixed => -family Courier -size 5 -weight normal -slant roman -underline 0 -overstrike 0
  systemfixed => -family Fixedsys -size 11 -weight normal -slant roman -underline 0 -overstrike 0
  TkHeadingFont => -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  device => -family System -size 10 -weight bold -slant roman -underline 0 -overstrike 0
  TkTooltipFont => -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  defaultgui => -family {MS Shell Dlg} -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  TkTextFont => -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  ansi => -family {MS Sans Serif} -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  TkCaptionFont => -family {Trebuchet MS} -size 10 -weight bold -slant roman -underline 0 -overstrike 0
  system => -family System -size 10 -weight bold -slant roman -underline 0 -overstrike 0
  TkSmallCaptionFont => -family Tahoma -size 8 -weight bold -slant roman -underline 0 -overstrike 0
  TkFixedFont => -family {Courier New} -size 9 -weight normal -slant roman -underline 0 -overstrike 0
  TkIconFont => -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0

  My current Tkinter release uses Tk 8.5.7 and there all fixed fonts are of size 5 (I had to make a patch).


tkt_uuid: 2947339fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: ttk::combobox : enhance dropdown list
comment:
  Subject : Make the width of the dropdown list of ttk::combobox configurable (and/or add the possibility to have a 2 columns dropdown list)

  When the user has to select an item in a popdown list of a combobox, it is sometime desirable to show beside each entry in the list a short text giving explanation about the choice to be selected. This is particularly usefull in database applications when the choices to be made are keys/abreviations not easy to remember for the user.
  In that case, it would be nice if the width of the popdown list could be configurable and not be depedant of the width of the text field of the combobox.

  Thanks a lot

  Jean-Marie


tkt_uuid: 2947842fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: None
resolution: None
title: Clarify tk busy manpage
comment:
  The tk busy command does nothing to prevent keyboard evens from being sent to the 'busy' widgets. It mentions you have to set to focus to a none 'busy' widget but keyboard traversal can bring focus back to the 'busy' widgets. This patch tries to make clearer the tk busy command does not block keyboard event and gives and example how to prevent focus from being set to a 'busy' widget by focussing on a widget which can't be left using keyboard traversal.


tkt_uuid: 2948152fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Duplicate
title: Tk Cocoa crashes when Option-e pressed
comment:
  Using Mac Cocoa Tk 8.6.0 Jan 8, 2010 source code Wish crashes when Option-e is pressed.  Also crashes when Option-n or Option-u pressed but not on Option-p or Option-w.  Note the key pressed has the Option modifier which is not the same as the Command modifier (apple key) that actives menu entries.  When the crashing keys are typed in a Mac Terminal the displayed characters are all diacriticals (accents that would normally appear over another character).  The non-crashing Option-p is the symbol pi and non-crashing Option-w is the greek uppercase sigma.  Looking at the Tk Mac source code it appears that the problem is from accessing the index 0 position of a string that has no characters.  The attached Mac crash dump appears to be wrong in identifying which Tk routine was last called, but the Mac system calls where the crash occurred are probably correct.

  Pressing Option-e in the Wish window produces a crash and the following output:

  $ Wish.app/Contents/MacOS/Wish
  % 2010-02-08 15:31:49.607 Wish[68221:903] An uncaught exception was raised
  2010-02-08 15:31:49.609 Wish[68221:903] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
  2010-02-08 15:31:49.609 Wish[68221:903] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
  *** Call stack at first throw:
  (
  0   CoreFoundation                      0x00007fff8397e444 __exceptionPreprocess + 180
  1   libobjc.A.dylib                     0x00007fff87dfe0f3 objc_exception_throw + 45
  2   CoreFoundation                      0x00007fff8397e267 +[NSException raise:format:arguments:] + 103
  3   CoreFoundation                      0x00007fff8397e1f4 +[NSException raise:format:] + 148
  4   Foundation                          0x00007fff889d13d5 -[NSCFString characterAtIndex:] + 97
  5   Tk                                  0x00000001000c4e9e Tk_SetCaretPos + 685
  6   Tk                                  0x00000001000cb3c8 Tk_MacOSXSetupTkNotifier + 699
  7   Tcl                                 0x00000001001dd6ea Tcl_DoOneEvent + 297
  8   Tk                                  0x000000010001d5e4 Tk_MainLoop + 24
  9   Tk                                  0x000000010002b0ce Tk_MainEx + 1491
  10  Wish                                0x00000001000054d5 0x0 + 4294989013
  11  Wish                                0x0000000100005434 0x0 + 4294988852
  )
  terminate called after throwing an instance of 'NSException'
  Abort trap


tkt_uuid: 2949069fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: ttk::combobox - correct (and full) operation on Windows.
comment:
  This is add-on code that I have made to make ttk::combobox function properly on Windows. This includes:

    1. Entry completion while combobox is editable
    2. Entry completion while combobox is readonly
    3. Selection completion when the list is dropped down

  When in editable mode, you can begin to type text and it will autocomplete the text as you type. When in readonly mode, pressing a key will select an item from the list that begins with that key (case insensitive). When the drop down is visible, pressing a key will select the item from that list that begins with that key (case insensitive). When the drop down is not present (readonly or editable), using your Up/Down arrow keys will cycle through the list values. Pressing Alt-Down in the edit widget (readonly or editable), the drop down list will appear. Pressing Alt-Up while the drop down list is active will update the selection and close the drop down list.

  These are the actions of how the combobox functions on Windows. I am unsure of how comboboxes work on Linux and OS X.


tkt_uuid: 2949297fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: macosx 10.6 build errors, deprecated APIs
comment:
  I'm getting a build error on my iMac 11,1 running OSX 10.6.2 with xcode 3.2.1 newly installed.
  1. APIs called from tkMacOSXBitmap.c.
  These APIs are marked as deprecated as of OSX 10.4 and they don't seem to be in the Carbon.h default include path
  (I confess I have not tried to hack past the Carbon.h include).
  There are about 10 such API failures; see attached. For example, I see the declaration and deprecation of PaintRect in
  ./ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/Headers/QuickdrawAPI.h

  2. undeclared type CIconHandle, also from tkMacOSXBitmap.c (this is where the compile fails outright) but it is present in
  ./ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/Headers/Icons.h.

  I'm hopelessly confused. H E L P


tkt_uuid: 2949356fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Cocoa Tk does not deiconify from Dock icon
comment:
  After iconifying Wish or our app (UCSF Chimera) that uses Tk Cocoa 8.6 Jan 8, 2010 source code, the app does not deiconify when the Mac Dock icon for the application is clicked. There are generally two icons shown on the Mac Dock, the application icon, and the instance icon.  The instance icon shows a miniature image of the app window.  The app icon show the application standard icon.  The instance icon correctly deiconifies the app.  The app icon does nothing when clicked.  The windows remain iconified.  All Mac app icons are supposed to deiconify the running application when clicked.  In Carbon Tk 8.5.8 deiconifying using the app icon works correctly.  The incorrect behavior is seen on Mac OS 10.6.2.  The same incorrect behavior is exhibited by the system Wish (/usr/bin/wish, Tk 8.5.7) on Mac OS 10.6.


tkt_uuid: 2949648fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: None
title: 'text see' doesn't work when the text is not yet
comment:
  An initial 'text see' command issued just after populating the text often doesn't work. In specific cases of complex layout, and/or when the text contains a lot of lines, doing 'update idletasks' or 'update' before the 'text see' doesn't solve the problem, and neither does performing the see in an 'after idle' or via a custom event sent via 'event generate'.

  The wrong behavior can be seen with the attached example script: the initial call to center_text does not center the line in the text on display. Successive calls via the 'Center' button work.

  A workaround seems to be to add the following lines at the beginning of proc center_text:
  .texts.txt count -update -ypixels 1.0 end
  .texts.lines count -update -ypixels 1.0 end
  and to replace the line center_text with:
  tkwait visibility .texts
  after idle after 5 center_text
  (thanks to Peter Spjuth for this)

  This workaround is quite complicated and basically impossible to find without help. It would be better if an initial 'text see' command worked out of the box, without any need for such a trick.


tkt_uuid: 2949774fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Cascade menus not unposted
comment:
  TIP 360 seems to have introduced a problem with cascade menus not being unposted when traversing a menu. This is an example:

  menu .m -tearoff 0
  . configure -menu .m
  .m add cascade -label M -menu .m.m
  menu .m.m -tearoff 0
  .m.m add cascade -label A -menu .m.m.a
  .m.m add command -label B
  .m.m add command -label C
  menu .m.m.a -tearoff 0
  .m.m.a add command -label X
  .m.m.a add command -label Y

  Now click on the menubar entry "M", and move the mouse down over the menu. When the pointer is over "A", a submenu appears (which is ok). However, when moving the mouse further down (over the "B" and "C" entries), the submenu should disappear and this does not happen.


tkt_uuid: 2954673fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Canvas line stipple ignored in Tk Cocoa
comment:
  Canvas line stipple gray25 is ignored by Tk Cocoa 8.6 source code from Jan 8, 2010.  The line appears solid as if no stipple was specified.  The line stipple also has no effect in Tk Aqua 8.5.8.  It works correctly in Tk 8.5.8 with X windows on the Mac.

  Below is a Wish script that demonstrates the problem.  The upper line of the two lines shown should show only a checkerboard of pixels while the lower line should be solid.  In Tk Cocoa 8.6 and Tk Aqua 8.5.8 both are solid.

  canvas .c
  pack .c
  .c create line 0 50 100 50 -stipple gray25 -width 5
  .c create line 0 60 100 60 -width 5


tkt_uuid: 2956100fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete ----
resolution: Duplicate
title: Text widgets with "-" in names vs anchor tags
comment:
  Try this:

  pack [text .t] -side top
  pack [text .t-2] -side top

  .t insert end "Double click me"
  .t-2 insert end "Double click me"

  and follow instructions.  Double-clicking on a word in .t-2 raises an error "bad text index "tk::anchor.t-2 - 1c"
  bad text index "tk::anchor.t-2 - 1c"
      while executing
  "$w compare $cur < $first"
      (procedure "tk::TextSelectTo" line 33)
      invoked from within
  "tk::TextSelectTo .t-2 96 15"
      (command bound to event)


tkt_uuid: 2957244fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.5.9
resolution: None
title: Tearoffs not showing for deep cascades
comment:
  Consider the following example:

  menu .main
  menu .main.submain
  menu .main.submain.subsub
  . configure -menu .main
  .main add cascade -label submain -menu .main.submain
  .main.submain add cascade -label subsub -menu .main.submain.subsub
  .main.submain.subsub add command -label subsubcmd -command {puts "subsubcmd executed"}

  Now open "subsub" cascade and tear it off - nothing happens. Well, not exactly, but it looks so - the torn-off menu is invisible.

  Try something different - first tear the "submain" off, and then tear the "subsub" off from it (not from the main window). This works as expected.

  It was the latest change in tearoff.tcl that causes it (2010-01-03  Pat Thoyts  <patthoyts@users.sourceforge.net> - "tearoff menus should be transient and use the toolwindow style on Windows").

  The attached patch contains a proposed fix for this.


tkt_uuid: 2958768fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: error immediately destroying interpreter
comment:
  If an interpreter is created and then immediately destroyed, an error occurs:
  % interp eval [interp create] { package require Tk; destroy . }
  % can't invoke "event" command:  application has been destroyed
      while executing
  "event generate $w <<ThemeChanged>>"
      (procedure "ttk::ThemeChanged" line 6)
      invoked from within
  "ttk::ThemeChanged"


tkt_uuid: 2961564fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: No italic TkDefaultFont in Tk Cocoa
comment:
  Making a label with font TkDefaultFont and italic slant displays a non-italic font with Tk Cocoa 8.6, Jan 8, 2010 source code.  With Tk 8.5.8 Aqua (Carbon) an italic font is shown.  The default Tk Cocoa font should have an italic version.

  Here's a Wish script demonstrating the problem:

  label .l -text "in italics?" -font "TkDefaultFont 13 italic"
  puts [font actual {TkDefaultFont 13 italic}]
  pack .l

  On Tk Cocoa 8.6 this shows a non-italic label and prints the following actual font being used:

  -family {Lucida Grande} -size 13 -weight normal -slant roman -underline 0 -overstrike 0

  On Tk Aqua (Carbon) 8.5.8 the displayed label is italic and the script prints the actual font as:

  -family Geneva -size 13 -weight normal -slant italic -underline 0 -overstrike 0

  Both tests were run on Mac OS 10.6.2.


tkt_uuid: 2962576fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 8
foundin: None
resolution: None
title: Popup cascaded submenus not functioning
comment:
  In a popup cascade submenu, -command does not fire, select does not work, active entry is not showing. 
  The problem seems to exist only for cascaded submenus, and has been observed with Tk versions 8.4,8.5 and 8.6b1.1. 
  The following code reproduces the problem:

  proc foo {} {puts ok}
  menu .mc
  .mc add radiobutton -label test1 -variable ::rb -value 0 -command ::foo
  .mc add radiobutton -label test2 -variable ::rb -value 1 -command ::foo
  menu .m
  .m add cascade -label test -menu .mc
  .m post 100 100

  However, posting the submenu directly with :

  .mc post 100 100

  doesn't seem to have a problem.


tkt_uuid: 2963397fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Wont Fix
title: Scrollbar config not working
comment:
  scrollbar .sb
  pack .sb
  .sb configure -borderwidth 3
  .sb configure -elementborderwidth 3
  .sb configure -relief flat
  .sb configure -activerelief flat

  Win XP
  these configurations actually have no effect.

  thx


tkt_uuid: 2964992fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: ttk::combobox::post config problem?
comment:
  The ConfigureListbox grids or removes the scrollbar before the height of the list changes in Placepopdown - so you might end up having a listbox with no scrollbar having to many elements in it ...

  thx


tkt_uuid: 2965133fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 8
foundin: obsolete: 8.6b1
resolution: None
title: Directory or list thereof (Was: Garbage in -install_name)
comment:
  When I build current Tk HEAD (just cd tk/macosx; make test) on this PPC G4 machine running OS X 10.5.8, I get the somewhat curious error

  dyld: Library not loaded: /Library/Frameworks/Tk.framework/Versions/8.6:NONE/Tk

  as soon as it's trying to start tktest. That ":NONE" looks rather suspicious, don't you think?

  As far as I can tell, the problem is that LIB_RUNTIME_DIR is being set up as a colon-separated list of directories, which is then copied to DYLIB_INSTALL_DIR, which in turn is treated as just one directory. Makefile.in sets it up thus:

    DYLIB_INSTALL_DIR= ${LIB_RUNTIME_DIR}

  and this variable is only used in configure.in, thus:

    TK_SHLIB_LD_EXTRAS="${TK_SHLIB_LD_EXTRAS}"' -install_name "${DYLIB_INSTALL_DIR}"/${TK_LIB_FILE}'

  But configure.in also contains commands (probably conditionalised) such as

    LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${TCL_EXEC_PREFIX}/lib"

    LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${x_libraries}"

  that treat LIB_RUNTIME_DIR very much as a list of paths.

  There is probably also a secondary bug that NONE is being treated as a path, when it really is some kind of null (=no data), but working out what goes wrong there likely requires some understanding of configurations for other platforms, so I won't form any opinion on that.

  FWIW, manually editing the build/tk/*/Makefile to remove the second components from the two definitions of LIB_RUNTIME_DIR (one near the top, one in the tktest target instructions) made the Development test succeed, although the Deployment tktest crashes:
  /bin/sh: line 1: 53644 Bus error               ./tktest /Users/lars/Projekt/Tcl-projekt/Tcl/tk/unix/../tests/all.tcl -geometry +0+0
  make[2]: *** [test-classic] Error 138
  make[1]: *** [test-tk] Error 2
  make: *** [test-deploy] Error 2
  But maybe it's better to leave that be until the makefile issue has been sorted out (I'm happy that I could install the Development variant).


tkt_uuid: 2967911fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: [wm forget] fails when main window is iconified
comment:
  After the following commands, the .f widget hierarchy seems to be lost. It cannot be recovered.

  pack [frame .f]
  pack [text .f.t]
  wm manage .f
  wm iconify .
  update
  wm forget .f
  wm deiconify .
  pack .f

  This problem seems to have been introduced by fixing bug 2009788.


tkt_uuid: 2968379fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: Segfault when doing dump on text peer
comment:
  A segfault occurs reliably when doing a dump -all on a text peer.
  This happens on ArchLinux 32bit and 64bit as well as with ActiveTcl on Windows 7.
  Valgrind: http://paste.tclers.tk/2008
  GDB: http://paste.tclers.tk/2010

  Code to reproduce the issue:

  text .t1
  .t1 peer create .t2
  .t2 dump -all 1.0 end


tkt_uuid: 2969401fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: Coordinates reported wrongly on ppc
comment:
  This applies to all versions from 8.4.7 up through 8.6b1.1 when running on a ppc-based Mac with OSX 10.3. After you move a window by dragging its titlebar, the geometry is subsequently reported wrongly. For instance if it is a toplevel window, the command 'winfo geometry .' gives the result 200x200+0+22, wherever the window is moved to (the size is reported correctly, the offset is wrong). Also the coordinates returned for the mouse position relative to the window in bound commands are wrong;  the %x and %y keywords are substituted with the same values as the %X and %Y keywords.
  The correct behaviour can be restored after moving the window, by maximizing and then normalizing it.


tkt_uuid: 2971081fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: listbox returns wrong active element index
comment:
  The result of "pathName index active" when called as a result of a <<ListboxSelect>> event triggered when the listbox is clicked on, always returns the index of the last active element in the listbox, rather than the current active element.

  Example code to illustrate the problem:

  package require Tk
  set lv "element_0 element_1 element_2"
  proc lb_report {path} {puts "current selection: [$path curselection]" ; puts "active index: [$path index active]"}
  listbox .lb -listvariable lv
  bind .lb <<ListboxSelect>> "lb_report %W"
  pack .lb

  Clicking on the elements in the listbox created echoes the current selection and the active index.  They should be the same, but in successive clicks the active index lags the current selection by 1.  This becomes a serious problem when the "-multiple" option is used on creation of the listbox, so the current selection and the active index are not necessarily the same, but the active index is needed to identify the users's choice and process the event properly.

  Thinking this might be a case of the script being called before all event bindings were processed, I changed the binding using the following command: 

  bind .lb <<ListboxSelect>> "after idle lb_report %W"

  But even after the event queue is empty, the wrong active index is reported in the same way.

  As a workaround I used the following binding:

  bind .lb <<ListboxSelect>> "after 100 lb_report %W"

  This produces the correct active index when the listbox is clicked on.  But doing event programming that depends explicitly on timing is a very poor design choice.

  The Tk FAQ suggests a workaround of binding to a mouse click event and finding the mouse cursor position to deduce the user's choice, but of course this only works if the mouse is used for selection, rather than key presses, which the default bindings enable. 

  ActiveTcl 8.5.8 on Ubuntu Intrepid.


tkt_uuid: 2971663fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Up and down arrow keys in entry fields, Mac Cocoa
comment:
  Pressing the up or down arrow keys in an entry field in Tk Cocoa 8.6 from Jan 8, 2010 source code causes unicode arrow key codes to be placed in the text variable associated for up or down arrows.  Those inserted are invisible in the displayed entry field and lead to errors parsing the entry text by client code which the user cannot understand because they do not see the invisible characters.  In general Tk ignores invisible characters (e.g. ctrl-Y, up arrow, ...) that are typed into entry fields unless they have special bindings (like left/right arrow for moving the insert cursor).  Aqua Tk (Carbon) 8.5.8 does not put invisible arrow keys in entry fields, nor does Tk Mac X11 8.5.8.  I believe the correct behavior is to not put the up / down arrow key unicode into the entry field text variable when the user presses those keys.

  Here's a Wish script demonstrating the problem.

  variable tv "test"
  entry .e -textvariable tv
  pack .e

  Click into the entry field, press the down arrow key, then display the string

  puts $tv
  -> tei\234\201st

  This problem may be related to the fact that the %A substitution used to show unicode for KeyPress events is non-empty for Tk Cocoa 8.6 while it is empty for Tk Carbon 8.5.8.


tkt_uuid: 2971762fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Duplicate
title: grid-pack interaction hangs interpreter
comment:
  The following code hangs the interpreter it is executed in, and causes the CPU to peg permanently at 100%.  Sometimes it hangs my entire computer, though I can't repeat that behavior reliably.  I'm using ActiveTcl 8.5.8 on Ubuntu Intrepid with the default Gnome desktop.

  package require Tk
  toplevel .gridpack
  label .gridpack.grid -text grid
  label .gridpack.pack -text pack
  grid .gridpack.grid
  pack .gridpack.pack


tkt_uuid: 2974003fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Works For Me
title: winfo rootx/rooty broken on Aqua
comment:
  winfo rootx and rooty on Aqua appear to be returning values that are relative to the top left corner of the toplevel in 8.4.19, rather than the top left corner of the screen. [winfo rootx .] and [winfo rooty .] both return 0 wherever the toplevel is moved on screen.

  I noticed this while migrating from Tile 0.7.6 to tile 0.8.2, when I found its combobox was behaving very badly (not responding to clicks in the popdown except to hide it, and popdown placed in the wrong place after moving the window the combobox is in). But after trying to isolate the issue to changes in Tile, I found it was doing this in my released app, too, which was recently upgraded to Tcl/Tk 8.4.19 (but still Tile 0.7.6). It was at that point that I found that rootx/rooty are returning bogus values in 8.4.19.

  This was previously working with 8.4.9, so I believe this to be a regression somewhere between 8.4.9 and 8.4.19.


tkt_uuid: 2975142fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: tk::CheckEnter broken with itcl variables
comment:
  # Tk 8.5.8 with Itcl on Linux (does not happen in 8.5.5).
  # Error when a *itcl* variable is used as -variable for checkbutton.
  # tk::CheckEnter assumes it can access the variable in global scope by prefixing it with "::"
  # This is wrong for variables in itcl-namespaces:

  wm geometry {.} 100x100
  package require Itcl

  itcl::class testclass {
      private variable foobar 1
      constructor {} {
  pack [checkbutton .c -indicatoron false -variable [itcl::scope foobar]] -fill x
      }
  }

  testclass #auto

  # Move mouse over checkbutton:
  # can't read "::@itcl ::testclass0 ::testclass::foobar": no such variable
  # can't read "::@itcl ::testclass0 ::testclass::foobar": no such variable
  #     while executing
  # "set ::[$w cget -variable]"
  #     (procedure "tk::CheckEnter" line 26)
  #     invoked from within
  # "tk::CheckEnter .c"
  #     (command bound to event)

  # proposed patch: use uplevel instead of ::, see attached patch


tkt_uuid: 2976019fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Deployment executables go bus error
comment:
  As mentioned at the end of bug #2965133, a crash remains even after fixing the makefile problems.

  On a PPC G4 machine running OS X 10.5.8, make test fails with:

   make -C "/Users/lars/Projekt/Tcl-projekt/Tcl/tk/macosx/../../build/tk/Deployment" test INSTALL_ROOT='' INSTALL_TARGETS='install-binaries install-libraries
  install-private-headers install-demos' VERSION='8.6' DYLD_FRAMEWORK_PATH="`pwd`:/Users/lars/Projekt/Tcl-projekt/Tcl/build/tcl/Deployment:${DYLD_FRAMEWORK_PATH}"; export DYLD_FRAMEWORK_PATH; TCL_LIBRARY=/Users/lars/Projekt/Tcl-projekt/Tcl/tcl/library; export TCL_LIBRARY; TK_LIBRARY=/Users/lars/Projekt/Tcl-projekt/Tcl/tk/library; export TK_LIBRARY; ./tktest /Users/lars/Projekt/Tcl-projekt/Tcl/tk/unix/../tests/all.tcl -geometry +0+0
   /bin/sh: line 1: 6111 Bus error ./tktest /Users/lars/Projekt/Tcl-projekt/Tcl/tk/unix/../tests/all.tcl -geometry +0+0
   make[2]: *** [test-classic] Error 138
   make[1]: *** [test-tk] Error 2
   make: *** [test-deploy] Error 2

  In other words, it crashes as soon as it gets to running the Deployment executable. On the other hand, the Development executables all seem fine (test completes without crashes).

  Any suggestions/instructions on how I might proceed with debugging?


tkt_uuid: 2978063fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: Localizing application first menu entries
comment:
  The hardcoded menu entries in the first application menu are localized by :NSLocalizedString(@"string", nil), e.g.

   [NSString stringWithFormat:NSLocalizedString(@"About %@", nil), aboutName]

  so that the file Localizable.strings in the language folder /Resources/<lang>.lproj can substitute the menu entries

  In the attachment there is a numbered extract with the changed lines in  tkMacOSXMenus.c

  I will look into other files, too, but what is done is done ...

  Great project!

  Zbigniew


tkt_uuid: 2978410fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: tk HEAD fails on HP-UX
comment:
  cc: ".../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.
  cc: "../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.
  cc: ".../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.
  cc: ".../unix/tkUnixRFont.c", line 90: error 1521: Incorrect initialization.

  this is just one line.


tkt_uuid: 2980135fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 28. Utility Functions
priority: 5 Medium
foundin: None
resolution: None
title: TkBackgroundEvalObjv - support return options
comment:
  TBEO() saves and restores interp state using
  old patterns.  Should be updated to use 
  Tcl_Save|RestoreInterpState() so that return
  options beyond -errorinfo and -errorcode get
  proper treatment.


tkt_uuid: 2980137fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 58. [send]
priority: 5 Medium
foundin: None
resolution: None
title: support return options
comment:
  The various implementations of [send] have schemes
  to transport the errorInfo and errorCode values from
  script evaluation, but have never been updated to
  accommodate the full return options dictionary
  produced by evaluation in Tcl 8.5+ interps.


tkt_uuid: 2981253fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: spinbox button frozen in case of repeated depressions
comment:
  When one depresses +/- buttons in a spinbox fast (say 2Hz) multiple times, the spinbox value is correctly updated, but the buttons are frozen and don't get visually depressed.


tkt_uuid: 2983824fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Image output format autodetection broken
comment:
  When writing to any popular image format (PNG, GIF, BMP, TIFF) an image containing antialiased text (for example one from a canvas captured through img::window), the 256-entry color palette overflows quickly, and the [$im write $file] command errors with "too many colors".
  So, bottom line, it is impossible to save a canvas's contents to any practical image format, even with [package require Img].
  By "practical" I mean, something that a typical Windows end-user could manipulate and/or paste into Word...

  I acknowledge the fact that this is 50% of the "Printing in Tcl" issue. However, it is much simpler since it doesn't go all the way to the printer.

  Note that this impossibility could be attenuated by a workaround like disabling antialiasing in the canvas, but I don't know how to.
  Alternatively, supporting truecolor (instead of indexed palette) in just one of these formats would do.


tkt_uuid: 2984787fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: PNG: Bug in generated png images files
comment:
  The attached PNG was generated from a trivial photo image by:
     $img write x.png

  It is apparently buggy; OSX's quick view in Finder.app can view it, but neither Preview.app nor Firefox like it. Other apps (used by a website, so identity unknown) also don't like it.


tkt_uuid: 2987995fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5.8
resolution: Fixed
title: Tk_getOpenFile returns garbage under described circumstances
comment:
  Tcl/Tk - ActiveTcl 8.5.8
  System: 64-bit Windows 7 Professional

  When using tk_getOpen file with "-multiple 1", it returns garbage under the following circumstance:

  - Type a partially matching filename in the "File name:" section of the dialog
  - Now, select a file from the list of presented (matching) files
  - Print out the results - they are complete garbage

  I cannot reproduce this under 32-bit Windows XP.  So, it's either a Win7 oddity or a 64-bit oddity.  As I don't have either 64-bit XP or 32-bit Win 7, I can't verify which is the issue.

  Remember, the keys to reproducing this are:
  - Win 7 / 64-bit
  - set "-multiple 1"
  - partially type a file name and then select from the presented matches


tkt_uuid: 2989842fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Notebook: optional TabPosition
comment:
  It would be nice if I can determine the position of the tab in the tkk::notebook

  e.g:  -tabpos [e|s|w|n]

  I need this to have many tabs and to use the lage width of the screen.


tkt_uuid: 2992129fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.5.8
resolution: Fixed
title: crash when using Pinyin or Japanese (Hiragana) IME input
comment:
  8.5.8/8.5.8.1 does crash when using Pinyin or Japanese (Hiragana) IME input, which 8.4.19 does function correctly.
  OS:WinXP pro with sp3
  windows report:
  AppName: wish85.exe AppVer: 8.5.2.8 ModName: ntdll.dll
  ModVer: 5.1.2600.5755 Offset: 0000120e


tkt_uuid: 2993162fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 3 Low
foundin: obsolete: 8.6b1
resolution: Wont Fix
title: Cocoa: waiting for variable hangs after exit called
comment:
  Cocoa API on MacOS: Selecting "Quit Wish" from the main menu sends an exit command to your application. If you want the app to do something after this happens, e.g., save user files, you rename the exit command and write your own handler procedure called exit. However, if this includes a 'tkwait variable' or 'vwait' instruction, the application hangs. 


tkt_uuid: 2993702fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Works For Me
title: Rotated text on canvas grows larger
comment:
  When a text string is rotated on the canvas (in this case, to 90 degrees), it gets noticeably larger.  When it's rotated back to 0 degrees, a portion of the text is not properly removed from the screen.  The size of that remaining portion seems to be the difference between the original text size and the now-too-large text size after rotation.

  So, for instance, if the original string was 100 pixels wide, it might be 120 pixels high after rotation.  When it's rotated back to horizontal, a 20 pixel piece (in this example) would be left behind.  

  Win 7, x64, AS 8.6b1.1

  The attached image should help to explain things better.


tkt_uuid: 2995325fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Out of Date
title: ttk::sizegrip does not take [wm resizable . h v]into account
comment:
  The ttk::sizegrip widget does not take the prior [wm resizable . h v]  calls into account for the toplevel it is intalled in.


tkt_uuid: 2995339fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: ttk::sizegrip strange behaviour
comment:
  Sometimes, yet to be determined, grabbing the sizegrip MOVES (instead of resizes) the window. The window is shifted by 10 pixels or so to the bottom of the screen.
  The sizegrip is packed to the right of an expanded frame packed to the bottom of the toplevel.


tkt_uuid: 2996165fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Duplicate
title: wish fails to start if $DISPLAY contains ::
comment:
  Hi!

  If $DISPLAY environment variable contains ::, which could be possible with IPv6 like DISPLAY=::1:0.0, wish immediately crashes at start with the following messages:

  % DISPLAY=::1:2 wish8.6
  Application initialization failed: Can't find a usable tk.tcl in the following directories: 
      ../tk8.6 ../../tk8.6 /usr/share/tcltk/tcl8.6/tk8.6 /usr/lib/tk8.6 /usr/local/lib/tcltk/tk8.6 /usr/local/share/tc
  ltk/tk8.6 /usr/lib/tcltk/tk8.6 /usr/share/tcltk/tk8.6 /usr/lib/tcltk/tcl8.6/tk8.6 /lib/tk8.6 /usr/library

  /usr/share/tcltk/tk8.6/tk.tcl: can't access "::tk::Priv.::1:2": parent namespace doesn't exist
  can't access "::tk::Priv.::1:2": parent namespace doesn't exist
      while executing
  "upvar #0 ::tk::Priv.::1:2 ::tk::Priv"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 upvar #0 ::tk::Priv.$disp ::tk::Priv"
      (procedure "tk::ScreenChanged" line 9)
      invoked from within
  "tk::ScreenChanged [winfo screen .]"
      (file "/usr/share/tcltk/tk8.6/tk.tcl" line 288)
      invoked from within
  "source /usr/share/tcltk/tk8.6/tk.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

  %

  The problem is in ::tk::ScreenChanged which uses the value of $DISPLAY as a variable name, so :: in it is treated as namespace delimiter. Simple mapping of :: to some safe string (which never occurs in $DISPLAY values)  will solve the bug.


tkt_uuid: 2997657fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 4
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: Labelframe loses border and title when it's a container
comment:
  This happened with Tk 8.5.8 from the Debian repositories. Labelframes created with "-container true" and I passed their [winfo id] as values for argv {-use} while creating slave interpreters. The slaves windows were embedded in the labelframes areas, but they lost their borders and titles. I don't know how labelframe widgets are designed, but it seems that [winfo id] on a labelframe returns the ID of its "outer", container frame, not of its interior as expected.

  Thanks!

  Fabricio Rocha
  Brasilia, Brasil
  rocha_fabricio@yahoo.com.br


tkt_uuid: 3000002fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: ttk::scrollbar doesnt use Appearance settings for size
comment:
  On Windows Vista and possibly Win7, the width of a ttk::scrollbar is fixed at 17 pixels. Changing the scrollbar size in Appearance settings has no effect. This worked fine in 8.5.7. The TK scrollbar behaves correctly on Vista.

  Interestingly, on XP both scrollbar and ttk::scrollbar have the same correct size matching the system scrollbar size.


tkt_uuid: 3000213fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 1 Zero
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Inactive menu entries not grayed out, Mac Cocoa
comment:
  Inactive menu entries are not grayed out on Mac Cocoa using Tk 8.6 CVS source code from May 10, 2010 if tk_setPalette is called.  If tk_setPalette is not called then the inactive menu entries are correctly shown as gray.

  Here is a Wish script demonstrating the problem:

  menu .m
  . config -menu .m
  menu .m.f
  .m add cascade -label File -menu .m.f
  .m.f add command -label Open
  .m.f add command -label Save -state disabled

  tk_setPalette tan

  The disabled menu entry "Save" will not appear gray.  Removing the last line of the script will make the disabled entry gray.

  This problem was observed when using the Tix meta-widget package which does a tk_setPalette to match the Tk color scheme to the color scheme in use by the operating system.

  The problem appears to be in tkMacOSXMenu.c in TkpConfigureMenuEntry() where it sets the font attributes foreground color if the foreground color is not the default value.  Commenting out that color setting code fixed the problem but probably also disables the use of colored fonts in menus.


tkt_uuid: 3001403fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Wish crash on Windows XP when trying to free a color
comment:
  Hello,

  Using a tool emulating an msdos console (dosbox) in order to play old games. This tool change the colormap of the display.
  I launch amsn, after what i launch this tool. Then an error message is displayed saying "Tried to free a color that isn't allocated."

  I report the bug to the amsn team, which explain me it's linked to tcl/tk library -> http://www.amsn-project.net/forums/index.php/topic,7910.msg46589.html

  This bug appears already occur on version 8.4 -> http://sourceforge.net/tracker/?func=detail&aid=1708823&group_id=12997&atid=112997
  and on previous version too ? -> http://lists.jabber.ru/pipermail/tkabber/2003-February/000085.html

  Regards,
  Anael


tkt_uuid: 3002230fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Fixed
title: tk_chooseDirectory returns garbage on cancel
comment:
  This happens only on Windows 2000.

  Do as follows:
  in the console issue tk_chooseDirectory command, then when the dialog pops up, press the "Cancel" button. The console prints some garbage characters.
  On Windows XP onwards, in the same circumstances, the result is an empty string (or, better said, there's no result, as the user cancelled the dialog).


tkt_uuid: 3002484fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: None
title: Hard crash in wish on OSX when no windowserver
comment:
  When I start wish on OSX from a session that does not have access to the window server (for instance using an SSH connection as a user that is not logged on on the console) I get a hard crash due to an uncaught ObjC exception:

  Sun May 16 11:30:39 Rivendell.local Wish[37073] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
  _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
  % 2010-05-16 11:30:39.691 Wish[37073:903] setCanCycle: is deprecated.  Please use setCollectionBehavior instead
  2010-05-16 11:30:39.704 Wish[37073:903] An uncaught exception was raised
  2010-05-16 11:30:39.704 Wish[37073:903] Error (1002) creating CGSWindow
  2010-05-16 11:30:39.705 Wish[37073:903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
  *** Call stack at first throw:
  (
  0   CoreFoundation                      0x00007fff85e31d24 __exceptionPreprocess + 180
  1   libobjc.A.dylib                     0x00007fff860000f3 objc_exception_throw + 45
  2   CoreFoundation                      0x00007fff85e31b47 +[NSException raise:format:arguments:] + 103
  3   CoreFoundation                      0x00007fff85e31ad4 +[NSException raise:format:] + 148
  4   AppKit                              0x00007fff84614aba _NSCreateWindowWithOpaqueShape2 + 473
  5   AppKit                              0x00007fff845a9055 -[NSWindow _commonAwake] + 1214
  6   AppKit                              0x00007fff845c6d3d -[NSWindow _makeKeyRegardlessOfVisibility] + 96
  7   AppKit                              0x00007fff845c6cb2 -[NSWindow makeKeyAndOrderFront:] + 24
  8   Tk                                  0x00000001000c435a XMapWindow + 139
  9   Tk                                  0x0000000100032d3c Tk_MapWindow + 84
  10  Tk                                  0x000000010003db5f TkCreateFrame + 1869
  11  Tcl                                 0x00000001001eec9c TclServiceIdle + 76
  12  Tcl                                 0x00000001001d531d Tcl_DoOneEvent + 340
  13  Tk                                  0x000000010001af93 Tk_MainLoop + 29
  14  Tk                                  0x0000000100027257 Tk_MainEx + 1589
  15  Wish                                0x00000001000044fe 0x0 + 4294984958
  16  Wish                                0x00000001000044ac 0x0 + 4294984876
  )
  terminate called after throwing an instance of 'NSException'
  Abort trap


  I'd expect to get a Tcl error instead of a hard abort.

  This also affects embedders of Tcl/Tk, the reason I post this issue is the following issue in the Python tracker: <http://bugs.python.org/issue8716>. I'm looking for a workaround for that issue (because we'll have to work with system versions of Tk) but it would be nice if this were fixed upstreams as well.


tkt_uuid: 3002768fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: new test failures
comment:
  These ttk notebook tests just recently
  started failing for me:

  ==== notebook-5.1 Virtual events FAILED
  ==== Contents of test case:

      toplevel .t
      set ::events [list]
      bind .t <<NotebookTabChanged>> { lappend events changed %W }

      pack [set nb [ttk::notebook .t.nb]] -expand true -fill both; update
      $nb add [frame $nb.f1]
      $nb add [frame $nb.f2]
      $nb add [frame $nb.f3]

      $nb select $nb.f1
      update; set events

  ---- Result was:

  ---- Result should have been (exact matching):
  changed .t.nb
  ==== notebook-5.1 FAILED



  ==== notebook-5.2 Virtual events, continued FAILED
  ==== Contents of test case:

      set events [list]
      $nb select $nb.f3
      update ; set events

  ---- Result was:

  ---- Result should have been (exact matching):
  changed .t.nb
  ==== notebook-5.2 FAILED



  ==== notebook-5.4 Reenable tab FAILED
  ==== Contents of test case:

      set events [list]
      $nb tab $nb.f2 -state normal
      $nb select $nb.f2
      update
      list $events [$nb index current]

  ---- Result was:
  {} 1
  ---- Result should have been (exact matching):
  {changed .t.nb} 1
  ==== notebook-5.4 FAILED


tkt_uuid: 3003353fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 7 High
foundin: obsolete: 8.5.8
resolution: Fixed
title: crasher in unix/tkUnixWm.c UpdatePhotoIcon
comment:
  I'm developing coccinella on OpenBSD, and wanted to try the port on other architectures than i386. 
  So I tried on OpenBSD 4.7 sparc64, or OpenBSD -current mips64, and I get random crashes with the following, and similar backtraces:

  Program received signal SIGSEGV, Segmentation fault.                                                                                                                                                                                                                               
  0x0000000057292780 in _XData32 () from /usr/X11R6/lib/libX11.so.12.0                                                                                                                                                                                                               
  (gdb) bt                                                                                                                                                                                                                                                                           
  #0  0x0000000057292780 in _XData32 () from /usr/X11R6/lib/libX11.so.12.0                                                                                                                                                                                                           
  #1  0x000000005725fafc in XChangeProperty () from /usr/X11R6/lib/libX11.so.12.0                                                                                                                                                                                                    
  #2  0x000000005b89b99c in UpdatePhotoIcon () from /usr/local/lib/libtk85.so.0.5                                                                                                                                                                                                    
  #3  0x000000005b894428 in TkWmMapWindow () from /usr/local/lib/libtk85.so.0.5                                                                                                                                                                                                      
  #4  0x000000005b7ddc44 in Tk_MapWindow () from /usr/local/lib/libtk85.so.0.5                                                                                                                                                                                                       
  #5  0x000000005ac39a70 in _ftext () from /usr/local/lib/tktray1.2/libtktray12.so.0.0                                                                                                                                                                                               
  #6  0x0000000000000001 in ?? ()                                                                                                                                                                                                                                                    
  Cannot access memory at address 0xfffffffffffffffe 


  static void
  UpdatePhotoIcon(
      TkWindow *winPtr)
  {                    
      WmInfo *wmPtr = winPtr->wmInfoPtr;
      unsigned char *data = wmPtr->iconDataPtr;
      int size = wmPtr->iconDataSize;          

      if (data == NULL) {
          data = winPtr->dispPtr->iconDataPtr;
          size = winPtr->dispPtr->iconDataSize;
      }                                        
      if (data != NULL) {                      
          /*                                   
           * Set icon:                         
           */                                  

          XChangeProperty(winPtr->display, wmPtr->wrapperPtr->window,
                  Tk_InternAtom((Tk_Window) winPtr, "_NET_WM_ICON"), 
                  XA_CARDINAL, 32, PropModeReplace,                  
                  (unsigned char *) data, size);                     
      }                                                              
  }

  Searching google for XChangeProperty, or _XData32 I found a lot of similar bug reports with similar backtraces in other applications, which was not considered a bug in Xorg, but in the application, in the call to XChangeProperty. This seems to be a 64Bit problem.

  On OpenBSD 4.6 i386, I do not have that problem, there everything works perfectly. 
  I'll try to install and run it on my other 32Bit systems, a sparc and vax in the next couple of days, but I guess there the problem will also not show up.


tkt_uuid: 3003891fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: OPTS=threads required to build on Windows with Makefile.vc
comment:
  When building Tk on windows using makefile.vc, it is required to specify OPTS=threads on the command line as otherwise the linker will look for tcl86.lib and building Tcl only generated tcl86t.lib


tkt_uuid: 3003892fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: TCLDIR default when building with makefile.vc
comment:
  Building Tk on windows require TCLDIR to be specified. TCLDIR can get a meaningful default as almost always tcl and tk source directories are placed in the same directory.


tkt_uuid: 3003895fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: None
resolution: None
title: improved range for Scale widget
comment:
  The current Scale widget isn't able to display a range starting with 1 and having a resolution of 2. Instead the "-from" value is rounded to be a multiple of the "-resolution".

  Example:
  pack [scale .s -orient hor -from 1 -to 9 -resolution 2 -tickinterval 1] -fill x

  The attached diffs contain all changes necessary to fix this odd behaviour. It's a diff for Tk 8.5.8, tkScale.c and tkScale.h.
  The "TkRoundToResolution" function has to be updated and "TkRoundTickToResolution" is introduced. The first one now refers to the "-from" value, too, and the latter is needed to round the "-tickinterval" without any reference to this value.


tkt_uuid: 3005455fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: error with neo keyboard layout input
comment:
  It's not possible to enter left-side fourth level keys from the Neo layout (see http://neo-layout.org/) with X server/GNU Linux. Mod4+v/ü/p should give Backspace/Escape/Return respectively, but give control characters. Mod4+ö works (Tab), the rest does nothing.


tkt_uuid: 3006842fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: Empty binding scripts
comment:
  This may be a very minor windows only bug, but activestate tcl-8.5.8.2 (WinXP) crashes immediately when i assign a null binding to button-1 on a treeview widget, and click on the widget.
  The code that causes it is
    $w.tree tag bind click1 <Button-1> {}
  When using click1 as a tag such as
    $w.tree insert {} 0 -values $values -tag [list click1 click2 treefont]

  Problem is easily solved by removing null binding.

  Sorry for such a shitty bug report, but it may be interesting to someone

  Project is scidvspc , subversion release 42
  http://scidvspc.svn.sourceforge.net/viewvc/scidvspc?view=rev&revision=42


tkt_uuid: 3007843fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 88. Themed Tk (Ttk)
priority: 3 Low
foundin: None
resolution: Out of Date
title: Autolabeling ttk::treeview nodes with their index number
comment:
  in tree mode ( -show tree) is it not possible to put index number in integer foam.
  i mean first column in tree mode always give row numbers. whenever we delete an item the row number should be updated.
  for example lets have height of treeview is 10, so we have 10 rows , column 0 indicate 1 to 10 in integer. if i delete item 5 then it should update all index numbers.
  if you could add this feature then it would be great.
  Thanks


tkt_uuid: 3009450fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Can't deiconify window if a child toplevel is grabbed
comment:
  Under windows, if a child toplevel has a grab and is transient, you can not deiconify the application.

  # Better example than words:
  package require Tk
  toplevel .t
  wm transient .t .
  grab .t

  # Now, click on "Show desktop" button
  # You will not be able to deiconify the application

  Bug introduced by resulotion of #1847002 ?


tkt_uuid: 3009885fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: tk_messageBox can return empty string on Windows
comment:
  If the parent window of a tk_messageBox is transient, and the window is iconified, the message box disappears and returns the empty string.

  # Example;
  package require Tk

  tk_messageBox -message test   
  # Iconify the application, the message dialog stay open

  toplevel .t
  tk_messageBox -parent .t -message test
  # Iconify the application, the message dialog stay open

  wm transient .t .
  tk_messageBox -parent .t -message test
  # Iconify the application, the message dialog disappears
  # Deiconify the application, tk_messageBox returns empty string


tkt_uuid: 3009998fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 8
foundin: None
resolution: Accepted
title: Binding procedure reform
comment:
  Attached patch winscrollbar-bindproc replaces the TkBindEvalProc ScrollbarBindProc with an ordinary event handler.

  (Description to follow).


tkt_uuid: 3012605fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Menubar entries not normalized after viewing disabled
comment:
  Enter these commands:
  . config -menu [menu .m1]
  .m1 add cascade -menu [menu .m2] -label Foo
  .m2 add command -label Bar

  You can now select Foo from the top menu and select the Bar entry from it

  .m1 entryconfig Foo -state disabled

  Foo can still be selected but the entry Bar is greyed out and cannot be selected

  .m1 entryconfig Foo -state normal

  Bar is still greyed out and still cannot be selected.
  Note that if you do not select Foo between disabling and normalizing it, Bar can still be selected after normalizing it. Also if you enter 

  .m2 entryconfig Bar -state normal

  ...then Bar will be selectable again.


tkt_uuid: 3016181fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: Accepted
title: Crash after scrollbar destroyed, Tk Cocoa
comment:
  After deleting a Tk scrollbar a crash sometimes occurs on a mouse down click in the pane associated with the former scrollbar.  Happens with Tk 8.6 source code from May 10, 2010 with the Mac Cocoa build.  This was hard to debug because it requires about 100 mouse clicks and scrollbar deletions done by hand to generate the crash in a molecular visualization program UCSF Chimera.  But I reproduced a few dozen times.  Using the Tcl/Tk debugging libraries produced the attached stack trace showing an invalid interpreter pointer from a TkScrollbar is being used and that it came from a Mac NSScroller object.  It appears that the scrollbar has been destroyed and the NSScroller released but a call to tkScroller() in tkMacOSXScrlbr.c occurs later and uses the invalid TkScrollbar pointer in NSScroller.  I'll attach a patch that fixed this problem by setting the NSScroller copy of the TkScrollbar pointer to null.


tkt_uuid: 3016598fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 3 Low
foundin: obsolete: 8.6b1
resolution: Fixed
title: Conflicts from [package require tile]
comment:
  (Reported on Usenet a week or two ago):

  Reports of existing scripts and packages that call [package require tile]  breaking in various ways when run under an 8.6 beta / CVS HEAD wish.

  $tk_library/ttk/ttk.tcl (which is sourced at Tk initialization time) currently says:

  package ifneeded tile 0.8.0 { package require Tk ; package provide tile 0.8.0 }

  in an attempt to make [package require tile] an effective no-op under 8.5 and up.   

  However, there are extant releases of tile with a larger version number -- the official release 0.8.2 [*], also CVS HEAD builds with version 0.8.3 distributed by ActiveState via the teapot.  If any of those are present on the system, [package require tile] will load them instead of executing the built-in dummy ifneeded script for version 0.8.0.


tkt_uuid: 3017005fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: 'update idletasks' not sufficient on windows
comment:
  I have found that when creating multiple items on a canvas that in order for them to be drawn as they're created on Windows I have to use 'update' whereas on Linux I can use 'update idletasks'.

  I have see this behaviour in both the latest 8.5 and 8.6 from AS. The attached file should draw some coloured random koch snowflakes as they're created - I've annotated the problem area. The file itself will run ok since there is a platform dependent selection of the update mode.


tkt_uuid: 3019563fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: copy and paste from Tk entry fails
comment:
  Platform: SPARC Solaris 10, tk 8.6 cvs head (happens in older versions of Tk as well)
  displaying on Windows XP SP 3 via either Hummingbird Exceed or Cygwin/X
  Program:
  package require Tk
  entry .e
  entry .f
  pack .e .f


  Case 1:
  I type the words "English1 English2" into the entry box.
  I press down on the mouse button, and drag across the first word.
  I press control-c to copy the text.
  I move the mouse into Microsoft Word 
  I press control-v to paste.
  Only the first character of the text is pasted.

  Case 2:
  Using the same program, with the same text in the entry, I double click on the string "English1".
  I press control-c to copy
  I move the mouse into Microsoft Word and press control-v.
  The word "English1" is pasted.
  I move the mouse back to the Tk entry widget, and double click on the word "English2".
  I press control-c to copy.
  I move the mouse back to Microsoft Word and press control-v.
  The world "English1" - which was the previous item copied to the clipboard - is pasted.

  Note that if I move the mouse to the second entry box, type some text there, and double click it, then move back to the first box and double click English2, 
  press control-c, move the mouse into Microsoft Word and press control-v, the correct word is pasted. 


tkt_uuid: 3019624fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 51. [place]
priority: 6
foundin: None
resolution: Fixed
title: Fix crash on calling place in a half-dead application
comment:
  The following code segfaults on last tk CVS head (8.5 seems ok):

  package require Tk
  bind . <Destroy> {puts [place slaves .]}
  destroy .

  Problem: Tk_PlaceObjCmd uses Tk_MainWindow(interp) to get a window needed for TkGetWindowFromObj. Main window of an interp is removed from main window list _before_ <Destroy> bindings are evaluated. Tk_MainWindow(interp) starts to return NULL, [place] doesn't check for it, and a bad thing happens.

  Solution: other geometry managers, [grid]/[pack] at least, install an interp main window pointer as a command's client data (see tkWindow.c). During the time this report is about, main window is half-dead and removed from main window list, but not deallocated, and [grid]/[pack] have no problem accessing it. Changing tkPlace.c along these lines is trivial, as the [place] clientData is unused by now.

  P.S. among other commands not taking main window as their ClientData, [wm] looks suspicious (it's formally a geometry manager, at least). I'll look deeper into it when I have more time.


tkt_uuid: 3020550fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: None
resolution: None
title: grid, pack, place on half-dead windows resurrects hash entry
comment:
  I've explored this issue in depth for "grid" manager only, but others seems to be affected, too. 

  Code in tkGrid.c uses hash table to find stored information for managed windows. It's a hash table with one-word keys, mapping from tkwin to "struct Gridder*"; when some grid operation on a tkwin is requested for the first time, this structure is allocated and added to hash table. It is deleted from the hash table on DestoyNotify event.

  A very bad thing happens when some <Destroy> binding executes a grid subcommand
  on a destroyed window (it may be [grid info] or even [grid forget]). Binding is executed when DestroyNotify handler has already removed a Gridder* from the hash table; hence a Gridder for dead window is [re]created and added to the hash table. _No one will remove it from there any more_. 

  But it's not just a tiny memory leak: tkwin is going to become invalid as soon as Tk_DestroyWindow finishes, and its memory block can be reused for any other data structure. For some allocators (tclThreadAlloc at least) this structure will be probably another tkwin, for a new window. Any grid operation on this unhappy window will find an "existing" Gridder* and use it. Tk_CreateEventHandler is not called when Gridder* already exists. We now have a window that looks alright from the scripts' point of view, but (1) it doesn't rearrange slaves when resized, and (2) it won't be removed from the hash table, even if no grid calls in <Destroy> bindings occur this time. Both actions, (1) and (2), depend on an event handler (StructureNotifyMask -> GridStructureProc) that is not installed.

  Destroyed tkwin addresses are reused surprisingly often. I was debugging the hv3 tabbed browser (where <Destroy> handler on notebook widget does [grid forget]), and after destroying a tab, the next new tab was disfunctional (the way described above) for about 10-30% of attempts. Thank God, such frequency enabled me to track down the problem.

  It seems to be an optimal solution to conceal the window's death for "informational" and "removing/forgetting" geometry manager subcommands, returning an empty value with no error, and to generate an error if a script tries to add or configure a slave of the dead window, or a dead window itself.

  Another variant, minimizing required effort and probably rather good semantically, is to add support for an _ultimate_ dead-window callback chain, called in Tk_DestroyWindow when no bindings or normal event handlers will be invoked any more. Removing tkwin from a hash table should happen in this callback. 

  A _pseudo-solution to be avoided_ is to reverse invocation order of [bind] handlers and Tk handlers for DestroyNotify event, ensuring that [bind] scripts are called first. Among other disadvantages, it is _unsafe_: adding a command trace for widget command deletion allows hooking into non-[bind] DestroyNotify handler chain.


tkt_uuid: 3021044fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: None
resolution: None
title: Partial fix for Bug#3020550
comment:
  An attempt to fix Bug #3020550, limited to [grid]-related code (other geometry managers are probably affected, and fixable using the same approach).

  The patch introduces a new internal Tk function, TkGetWindowSpecificData (added into tkInt stub table). It maintains a linked list of data blocks associated with each TkWindow, where each module (e.g. grid geometry manager) can store its own data related to a window; all data blocks in the chain are freed (Tcl_EventuallyFree'd with a specified freeProc) at the end of Tk_DestroyWindow, when _really_ no one should reference TkWindow any more. 

  Tk/generic/tkGrid.c is modified so it doesn't use hash table for tkwin-to-Gridder* mapping, but gets a Gridder with TkGetWindowSpecificData. The most visible part of #3020550, that is, recreating Gridders for tkwins that are then invalidated, goes away with this change automatically.

  As of handling [grid] operations for dead windows, e.g. called by <Destroy> bindings, this patch doesn't generate errors on them, even on configuring/adding dead windows (or _into_ dead masters). It tries to behave as if destroyed windows were alive and about to die: e.g. if any window is gridded into a dead master, it is detached from its previous master and ends up unmapped. As Gridder* structure now remains valid when <Destroy> bindings are called, and freed only at the very end of Tk_DestroyWindow, I needed only a few `ifs' added to avoid breaking things with dead windows: we just have to prevent relinking slaves and masters if either of them is dead, and avoid using null tkwin from a dead Gridder in Tk window operations.

  I chose this approach instead of complaining about dead windows because there is probably a lot of code expecting this behavior (_surely_ a lot of code expect [grid forget] to succeed). Without this patch, such code got an obscure reusing-dead-Gridders bug along with `succeeding' grid operations, but I decided it not to be a reason to _start_ generating errors in these cases.

  I'm asking anyone interested to test this patch and review the code. If this patch is accepted, I'm going to modify tkPack.c and tkPlace.c so they use TkGetWindowSpecificData instead of tkwin-keyed hash table too.


tkt_uuid: 3025033fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: APPCRASH if open IME on Win32
comment:
  Downloaded tcl 8.6 from ActiveTcl, playing those demos on Win7 32 bit, if you open IME (input method fro non-English languages) in any of the textbox, the whole app crash.


tkt_uuid: 3028365fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Default LIBDIR not on Tk's auto_path
comment:
  Having recently bought a new computer, I've had to recompile a number of packages. In doing so, I've noticed that TEA seems default to putting things in /usr/local/lib, which I suppose makes sense. The problem is however that this directory doesn't appear on Wish's auto_path:

  % info patchlevel
  8.6b1.2
  % set auto_path
  /Library/Frameworks/Tcl.framework/Versions/8.6/Resources/Scripts /Library/Frameworks/Tcl.framework/Versions/8.6/Resources /usr/local/bin/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/lib ~/Library/Tcl /Library/Tcl /System/Library/Tcl ~/Library/Frameworks /Library/Frameworks /System/Library/Frameworks /Library/Frameworks/Tk.framework/Versions/8.6/Resources/Scripts /Library/Frameworks/Tk.framework/Versions/8.6/Resources/Scripts/ttk
  % info nameofexecutable
  /usr/local/bin/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/MacOS/Wish

  I suppose the problem surfaces for wish but not for tclsh because the actual wish executable isn't locaed in /usr/local/bin, whereas tclsh gets its /usr/local item on auto_path from [info nameofexecutable]; for tclsh the corresponding results are:

  % info patchlevel
  8.6b1.2
  % set auto_path
  /Library/Frameworks/Tcl.framework/Versions/8.6/Resources/Scripts /Library/Frameworks/Tcl.framework/Versions/8.6/Resources /usr/local/lib ~/Library/Tcl /Library/Tcl /System/Library/Tcl ~/Library/Frameworks /Library/Frameworks /System/Library/Frameworks
  % info nameofexecutable
  /usr/local/bin/tclsh8.6

  I'm not sure how best to proceed. It would be nice if TEA could rather default to have at least platform-independent files in /Library/Tcl on MacOSX, but perhaps the more pragmatic approach is to ensure Wish is looking in /usr as well.


tkt_uuid: 3028676fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 70. Event Loop
priority: 7 High
severity: Minor
foundin: current: 8.6.0
resolution: Wont Fix
title: Cocoa event loop won't let external events through
comment:
  I've got a program where I've chopped up a long running computation into smaller pieces, using the

    after 0 [after idle {next_iteration}]

  idiom for scheduling the next chunk of work while allowing the GUI to stay responsive; I believe this is the recommended way to do this.

  Unfortunately my program, which has worked well on my old PPC macs, does not seem to work on my new Intel mac: although the GUI is being updated in response to changes in e.g. label -textvariable values, I'm no longer getting any response to pressing buttons when the computation is running. Since this includes buttons I'd press to control the program, it makes it pretty useless!

  Instructions to see the problem:

  1. Start wish from a terminal.
  2. [source] the attached beachball-bug.tcl.
  -> This will create a window "Control panel" with three buttons "Halt", "Pause", and "Run", and two labels (each displaying the number 0).
  3. Press "Run".
  -> The left label will start to count upwards, slowing down as it goes. The right label will mostly say 1 but sometimes 0.
  4. Press "Pause"
  -> What should happen is that the counting stops and the right label changes to 2; an [after info] command (that may be typed at the prompt in the terminal) should confirm nothing is happening.
  ->< However, what rather happens is that the "Pause" button becomes highlighted and *stays highlighted*, while the counting continues unaffected. The mouse pointer will soon turn into the spinning beach ball above wish windows, confirming that wish is not processing any events. At this stage, you may type one (1) command at the terminal and have wish evaluate it; if you make this command "after cancel [after info]" then you can still stop the counting, but otherwise there's no way of stopping it short of killing the wish process.

  I see this problem for:
  * Tk 8.6b1.2 that I've compiled myself from sources checked out from CVS.
  * Tk 8.5.7 from /System/Library/Frameworks/Tk.framework/..., that I suppose Apple compiled.

  I don't see this problem for:
  * Tk 8.4.19 from /System/Library/Frameworks/Tk.framework/..., that I again suppose Apple compiled.
  * Tk 8.5.6 that I compiled on my old mac; this is a PPC executable, but it runs (I suppose) using Rosetta.

  The problematic wishes all seem to be 64-bit executables (tcl_platform(wordSize) is 8) whereas the working ones are 32-bit (tcl_platform(wordSize) is 4). I suppose this could mean the faulty/working distinction is rather one of Cocoa/Carbon, but I don't know if there is some other way to check if the 8.4.19 is Carbon or Cocoa.


tkt_uuid: 3030697fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Invalid
title: tk_dialog ignores window manager close
comment:
  Platform: sparc solaris 10, gnome window manager, tcl/tk 8.5.8 as well as 8.6 beta current cvs head.

  Sample script:
  #!/usr/tcl85/bin/tclsh8.5

  package require Tk

  wm withdraw .

  set res [tk_dialog .showproblem "You Must Use Button" "You cannot dismiss me by clicking the window manager's little X in the corner, even if I only have a single button that says OK" info 0 OK]

  puts $res
  exit 0

  tk_dialog box appears, with window manager decoration. User clicks on the window manager X to close dialog, but that is ignored.
  Response http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/4430353ac153366b/0c0eeddf9d4dbf13?tvc=1#0c0eeddf9d4dbf13
  by Jeff Hobbs says:

  "[...] tk_dialog does.  It pops up a modal, complete with wm 
  frame, for user interaction.  It should have the wm [X] to close it, 
  and that should work. "


tkt_uuid: 3033786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 3 Low
foundin: None
resolution: Wont Fix
title: Cannot embed Tk in a Cocoa Application
comment:
  Tk built against Cocoa does not allow Tk to be embedded in another Cocoa application.  This is apparent when embedding Python inside of a Cocoa application.  The tkinter module does not work.

  I think the problem stems from the fact that the Tk initialization code subclasses NSApplication.  If another application gets a chance to create an NSApplication object errors like this are thrown:

  2010-07-23 15:30:59.721 X-Chat Aqua[32706:903] -[SGApplication _setup:]: unrecognized selector sent to instance 0x606aa0
  2010-07-23 15:30:59.722 X-Chat Aqua[32706:903] Exception raised during posting of notification.  Ignored.  exception: \'-[SGApplication _setup:]: unrecognized selector sent to 

  See the attached example to reproduce the problem (requires Xcode).

  I\'ve found at least two applications that use Python scripting on the Mac that are broken with respect to being able to use Tk.  Our application works on 10.5 (since Tk there is built against Carbon).

  http://golly.sourceforge.net/
  https://sourceforge.net/projects/xchataqua/

  These are both open source applications, but any application that uses Python scripting is probably broken (see http://wiki.python.org/moin/AppsWithPythonScripting).


tkt_uuid: 3039337fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Invalid
title: Test Suite isn't work correctly
comment:
  I try to porting tcl/tk on z/OS. And when I truy to run 'make test' for tk then I get next error message

  LD_LIBRARY_PATH="`pwd`:/u/pdmosk/local/lib:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH; TCL_LIBRARY=/u/pdmosk/tcl8-5-8/library; export TCL_LIBRARY; TK_LIBRARY=/u/pdmosk/tk8-5-8/library; export TK_LIBRARY; ./tktest /u/pdmosk/tk8-5-8/unix/../tests/all.tcl -geometry +0+0
  Tests running in interp:  /u/pdmosk/tk8-5-8/unix/tktest
  Tests located in:  /u/pdmosk/tk8-5-8/tests
  Tests running in:  /u/pdmosk/tk8-5-8/unix
  Temporary files stored in /u/pdmosk/tk8-5-8/unix
  Test files sourced into current interpreter
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Wed Aug 04 06:09:03 EDT 2010
  bell.test
  EZYXW10E X Error of failed request:  BadName (named color or font does
  not exist)
    Major opcode of failed request:  45 (X_OpenFont)
    Serial number of failed request:  65
    Current serial number in output stream:  67
  gmake: *** [test-classic] Error 1

  What is it may be? someone faced with this? 
  PS Sorry for my broken english ))


tkt_uuid: 3042724fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: TK dies with specific filename
comment:
  if I name a file 'menubutton.tcl' it errors on mouseover. Simplest file:
  pack [text .e]

  If I name it other things, it works fine. If I name it 'menubutton.tcl', every mouse over  generates the following message, twice:
  unknown option "-state"
      while executing
  "$w cget -state"
      (procedure "tk::MbEnter" line 8)
      invoked from within
  "tk::MbEnter ."
      (command bound to event)

  I'm running ActiveState 8.5.8


tkt_uuid: 3044863fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Tk Mac crashes when accelerator key spawns window
comment:
  I have a cross-platform application that I have just added menu accelerators (keypress shortcuts) to.Works fine on Tcl/Tk in Linux and in Windows (Cygwin Insight). Freezes on Mac OS X 10.6 Snow Leopard when an accelerator key is pressed to spawn a window.

  I have a demonstration of this freeze (can't upload the tarball code, there's a 256k limit):
  http://personal.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/savi-dev-kevin.tar.gz
  tar xvf savi-dev-kevin.tar
  cd savi-dev-kevin
  make ARCH=macosx
  ./savi &
  Click on the letterbox-shaped table-of-numbers window, then press either command-G to spawn the Global coverage window, command-F to spawn the fisheye window, or command-M to get the _empty space_ dialog - all windows will draw but missing a Mac titlebar and controls, and then the application freezes.

  If you relaunch savi and only point and click on the menu options, everything is fine. If you relaunch savi and force use of popup menus rather than the Mac menubar with the savi -redrawn-menus flag (more on the reason for that flag below), accelerators work fine. It's accelerators plus the Mac menubar that is the problem.

  A previous example you may have read about on the tcl-mac mailing list: The Tk Mac menubar never worked at all in 10.5 when Tk applications were launched from the terminal (I implemented a workaround for that in savi with -redrawn-menus and popup menus within window frames that avoided using the broken menubar - oddly, I see accelerators work fine from the Mac popup menus I implemented to work around that previous problem. Again, it's related to the Mac menubar). The release of 10.6 and the upgrade to Tcl/Tk in Xcode eventually fixed that problem (along with other Mac-specific problems like too-wide listboxes causing hangs), but that took eighteen months to happen, and has now exposed this crash.

  This appears at first glance to be a similar _maybe the Tk shipped with 10.7 will fix it_-level Mac menuing bug; I do not see what I can do about it, as the installed base on Snow Leopard has Xcode with Tcl/Tk 8.5.7 and that's it.

  Tk on the Mac should imo be as robust as Tk on other platforms, and should not require workarounds to prevent crashes.

  (I posted about this to the tcl-mac list, but, despite being a subscriber, my posts hit a filter rule and are queued for a moderator to look at. Hence the background detail here.)


tkt_uuid: 3046742fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Unknown option "-relief" in [bgerror]
comment:
  The <Return> binding for the standard Tk [bgerror] dialog sets the -relief option of the OK button.  However, the OK button is a [ttk::button] and therefore does not have a -relief option.

  To test, run "bgerror foo", click on the bgerror dialog that pops up, and press Return (or Enter, whatever).  The error text will change to reflect the new problem.


tkt_uuid: 3046743fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Invalid
title: Invoked "break" outside of a loop in [bgerror]
comment:
  Clicking "Skip Messages" in the standard Tk [bgerror] dialog results in an invoked "break" outside of a loop error, when there is only one error.

  To test, type "bgerror foo", then click Skip Messages in the pop-up dialog.  The error is returned by [bgerror].  Next, type "bgerror foo" again and press Return to generate an unknown option "-relief" error (bug 3046742).  Now click Skip Messages, and there is no break error.


tkt_uuid: 3046750fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: No handler for "X" close button in [bgerror]
comment:
  At least on MS-Windows, the "X" close button in the Tk [bgerror] dialog has no effect.  I expect it to work the same as Skip Messages.


tkt_uuid: 3047583fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: None
title: line -smooth raw looks funny in Postscript
comment:
  Program-generated cartoon has lines on canvas .c with option -smooth raw such that they render as cubic bezier.

  If there are more than 1 bezier sequence, then the line width varies wildly at the limb points.

  Demonstration: create canvas .c, then source manneken.dump, then say .c postscript, then watch the result.

  Compare with manneken.ps

  If there are questions, mail to wolf-dieter.busch@gmx.de


tkt_uuid: 3049518fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: None
title: Fire Event when a used font changes
comment:
  When a named font is used by a widget:
  % font create Custom -size 8
  % label .l -font Custom
  and the font is reconfigured:
  % font configure Custom -size 17
  all core widgets automatically change their size.

  If a megawidget uses a named font and does some position calculations on the font size,
  there is no way to get notified if the font size change to trigger a size change.
  In consequence, widgets look corrupted after a font size change.

  Example megawidgets are: NoteBook from BWidgets, TableList

  The demanded feature is to send an event if the size of the font changes.
  Example:
  bind .l <FontChange> reConfigure

  This would be similar to the Configure event.


tkt_uuid: 3053347fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5.8
resolution: Fixed
title: Invalid read in tkText.c:DumpLine
comment:
  I had a crash across platforms in text.test and running under valgrind it indicates:

  ==9088== Invalid read of size 4
  ==9088==    at 0x4A7803: DumpLine (tkText.c:4771)
  ==9088==    by 0x4A6E54: TextDumpCmd (tkText.c:4544)
  ==9088==    by 0x4A1CE1: TextWidgetObjCmd (tkText.c:1231)
  ==9088==    by 0x522C28: TclEvalObjvInternal (tclBasic.c:3689)
  ==9088==    by 0x588D53: TclExecuteByteCode (tclExecute.c:2419)
  ==9088==    by 0x586741: TclCompEvalObj (tclExecute.c:1542)
  ==9088==    by 0x52513E: TclEvalObjEx (tclBasic.c:5264)
  ==9088==    by 0x5E9D54: Tcl_UplevelObjCmd (tclProc.c:948)
  ==9088==  Address 0x7df3ad8 is 72 bytes inside a block of size 101 free'd
  ==9088==    at 0x4C23DD8: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==9088==    by 0x62D99F: TclpFree (tclAlloc.c:731)
  ==9088==    by 0x52BBB3: Tcl_DbCkfree (tclCkalloc.c:639)
  ==9088==    by 0x52BD88: Tcl_Free (tclCkalloc.c:765)
  ==9088==    by 0x4AE9AA: CharSplitProc (tkTextBTree.c:4559)
  ==9088==    by 0x4AAECC: SplitSeg (tkTextBTree.c:1210)
  ==9088==    by 0x4AC0AB: TkBTreeTag (tkTextBTree.c:2211)
  ==9088==    by 0x4BECCC: TkTextTagCmd (tkTextTag.c:203)
  ==9088==

  It appears that segPtr is no longer valid there, especially since we are in the lineChanged condition.  Donal was the last in this area of code, though it has been a while.

  This may also be in head, just was testing 8.5.9 and found this.


tkt_uuid: 3055902fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Control-a key binding for text widget is broke
comment:
  The <Control-a> binding for text widgets doesn't work properly with regards to the sel tag.
  <Control-o> works fine. 

  It seems to be related to newlines somehow, as even the Control-o binding (below) inserts extra newlines.
  Tested on 8.4 and 8.5. Hope i'm not missing something...
  -----------------
  pack [text .t]
  .t insert end {some text
  and more}
  bind .t <Control-a> {.t tag add sel 0.0 end-1c}
  bind .t <Control-o> {.t tag add sel 0.0 end-1c}


tkt_uuid: 3057573fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: ttk::combobox disabled state under Win 7
comment:
  Under Windows 7, the disabled state of the ttk::combobox is not very visible.  When disabled, the down arrow is grayed out and there is a slight border change, but the background color of the text area is not changed, nor is the color of the text itself.  This makes it difficult to determine the state of the widget at a glance.  

  Under Windows XP, in addition to the above visual cues, the background color of the text area and the button area are also changed.  

  The text color is not changed when the widget is disabled under either OS.  This does not match the visual look of other disabled ttk widgets (entry, etc), where the text is grayed out also.


tkt_uuid: 3059100fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Missing documentation for wm attributes -type
comment:
  X Window Extended Window Manager Hints were added
  as the wm attributes -type option in Tip 359
  This has not been documented in the wm man page.

  A list of possible values could be adapted from the
  _NET_WM_WINDOW_TYPE section of
  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html


tkt_uuid: 3059923fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
severity: Minor
foundin: None
resolution: Out of Date
title: fixes for mingw64 - gcc4.5.1 tdm64-1
comment:
  mingw64 doesn't have SEH, and apparently amd64 arch (w64) doesn't need it.
  also fixes a conflicting value for _WIN32_IE on mingw64 environment.


tkt_uuid: 3069474fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: undefined reference to `_TkFinalize
comment:
  patch 3059923 fixes this compiler error by removing usage of SEH on this case (gcc, have_no_seh, win64)

  environment:
  windows7 x64 - gcc-4.5.1 mingw64 - w64 target

  x86_64-w64-mingw32-gcc -shared -O2 -fomit-frame-pointer -DUNICODE -D_UNICODE  -o tk86.dll -pipe            -Wl,--out-implib,libtk86.a tkConsole.o tkUnixMenubu.o tkUnixScale.o xcolors.o xdraw.o xgc.o ximage.o xutil.o tkWin3d.o tkWin32Dll.o tkWinButton.o tkWinClipboard.o tkWinColor.o tkWinConfig.o tkWinCursor.o tkWinDialog.o tkWinDraw.o tkWinEmbed.o tkWinFont.o tkWinImage.o tkWinInit.o tkWinKey.o tkWinMenu.o tkWinPixmap.o tkWinPointer.o tkWinRegion.o tkWinScrlbr.o tkWinSend.o tkWinSendCom.o tkWinWindow.o tkWinWm.o tkWinX.o stubs.o tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkBusy.o tkButton.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o tkCanvWind.o tkCanvas.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkCursor.o tkEntry.o tkError.o tkEvent.o tkFileFilter.o tkFocus.o tkFont.o tkFrame.o tkGC.o tkGeometry.o tkGet.o tkGrab.o tkGrid.o tkImage.o tkImgBmap.o tkImgGIF.o tkImgPNG.o tkImgPPM.o tkImgPhoto.o tkImgPhInstance.o tkImgUtil.o tkListbox.o tkMacWinMenu.o tkMain.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkPointer.o tkRectOval.o tkScale.o tkScrollbar.o tkSelect.o tkStyle.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o tkTrig.o tkUndo.o tkUtil.o tkVisual.o tkStubInit.o tkWindow.o ttkWinMonitor.o ttkWinTheme.o ttkWinXPTheme.o ttkBlink.o ttkButton.o ttkCache.o ttkClamTheme.o ttkClassicTheme.o ttkDefaultTheme.o ttkElements.o ttkEntry.o ttkFrame.o ttkImage.o ttkInit.o ttkLabel.o ttkLayout.o ttkManager.o ttkNotebook.o ttkPanedwindow.o ttkProgress.o ttkScale.o ttkScrollbar.o ttkScroll.o ttkSeparator.o ttkSquare.o ttkState.o ttkTagSet.o ttkTheme.o ttkTrace.o ttkTrack.o ttkTreeview.o ttkWidget.o ttkStubInit.o tk.res.o "/c/pd/tcltk-cvs/tcl/win/libtclstub86.a" -lkernel32 -luser32 -ladvapi32 -lws2_32 -lgdi32 -lcomdlg32 -limm32 -lcomctl32 -lshell32 -luuid -lole32 -loleaut32
  Creating library file: libtk86.atkWin32Dll.o:tkWin32Dll.c:(.text+0x59): undefined reference to `_TkFinalize
  '
  collect2: ld returned 1 exit status
  make: *** [tk86.dll] Error 1


tkt_uuid: 3071836fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Crash/Tcl_Panic on WinXP saving file to C:\
comment:
  Using tk_getSaveFile may cause a Tcl_Panic() if a particular sequence is used to browse to C:\ .

  Steps to reproduce:
  * Running on Win32 (confirmed on WinXP SP3 with latest patches)
  * Using Tcl 8.6b1.2 (from CVS 2010/08/31)
  * Built with OPTS=threads (debug build uses OPTS=threads,symbols STATS=memdbg)
  * In tclsh or wish execute the following script:
    package require Tk
    wm de .
    tk_getSaveFile -parent . -initialfile "SomeFile"
  * Using the "Look in" dropdown or the navigation bar on the left, select "Desktop".  Then (double-)click to select "My Computer", then "Local Disk (C:)"
  * Select "Save"
  * Interp will panic.

  Cause:
  * In GetFileNameW() (win\tkWinDialog.c) the call to ckfree(ofnData.dynFileBuffer) at the end of the proc detects a memory corruption and crashes / panics.
  * The corruption occurs in OFNHookProcW() (win\tkWinDialog.c) where "dirsize = SendMessageW(hdlg, CDM_GETFOLDERPATH, 0, 0)" may set dirsize to < 0 on failure.  Walking through the buffer manipulation logic one sees that the terminating NULL of the directory is replaced with a backslash, but with dirsize==-1 this corrupts the guard bytes on the buffer.
  * CDM_GETFOLDERPATH appears to return an error (< 0) when selecting an item in the "My Computer" context (since "My Computer" does not correspond to a folder in the filesystem).

  Solution:
  Apply the following patch to empty the buffer when dirsize < 0 :

  Index: tkWinDialog.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/tkWinDialog.c,v
  retrieving revision 1.77
  diff -r1.77 tkWinDialog.c
  1032c1032,1036
  <           if (selsize > 1) {
  ---
  >           /*
  >            * Just empty the buffer if dirsize indicates an error [Bug XXXXXX]
  >            *
  >            */
  >           if ((selsize > 1) && (dirsize > 0)) {


tkt_uuid: 3073331fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Out of Date
title: Namespace error on "::1:1.0" for XVNC DISPLAY variable
comment:
  I ran into an old namespace bug, which, according to the following email thread: https://sourceforge.net/mailarchive/message.php?msg_name=268895540912061058l60228248u483940a5c2737cca@mail.gmail.com and https://sourceforge.net/tracker/?func=detail&aid=2912473&group_id=12997&atid=112997, should be solved from 8.4. Was the patch taken out again? It works fine when I work from the local ":0.0" display.

  I run TCL/TK 8.5.5 from the Suse SLES 11 SP1 enterprise distro, so I can't upgrade to the latest TCL version unpunished... 

  Please let me know if you need extra information. Did I choose the right category?


tkt_uuid: 3077303fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Set background and opacity of Tk-Cocoa textured windows
comment:
  The attached patch allows you to set the background and opacity of textured ("metal") windows with Tk-Cocoa using the tk::unsupported::MacWindowStyle command. The current configuration of metal/textured windows does not integrate well with Tk widgets because the non-opacity of the window's background color causes the color to flicker through or "flash" during redraws of Tk widgets; it also does not allow Tk widgets to blend in seamlessly with the background because it is a gradient. This patch allows one to set the textured background to opaque, to set it to a standard NSColor, and then set the Tk widget to a corresponding hex color. 

  Here is an example:

  toplevel .f
  tk::unsupported::MacWindowStyle style .f document {metal light opaque closeBox collapseBox resizable standardDocument }

  pack [label .f.f -bg  #ababab -text "This is a textured window\nwith opacity and a gray background\nsimilar to other Mac applications"] -fill both -expand yes

  The patch updates both tkOSXWm.c and the README file, with documentation. 


tkt_uuid: 3077329fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Set background and opacity of Tk-Cocoa textured windows
comment:
  The attached patch allows you to set the background and opacity of textured ("metal") windows with Tk-Cocoa using the tk::unsupported::MacWindowStyle command. The current configuration of metal/textured windows does not integrate well with Tk widgets because the non-opacity of the window's background color causes the color to flicker through or "flash" severely during redraws of Tk widgets; it also does not allow Tk widgets to blend in seamlessly with the background because it is a gradient. This patch allows one to set the textured background to opaque, to set it to a standard NSColor, and then set the Tk widget to a corresponding hex color; this reduces the "flash" and allows the Tk widgets to blend in.

  Here is an example:

  toplevel .f
  tk::unsupported::MacWindowStyle style .f document {metal light opacity closeBox collapseBox resizable standardDocument }

  pack [label .f.f -bg #ababab -text "This is a textured window\nwith opacity and a gray background\nsimilar to other Mac applications"] -fill both -expand yes

  The patch updates both tkOSXWm.c and the README file, with documentation.


tkt_uuid: 3077986fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Win configure: tclsh path with spaces
comment:
  tclsh85.exe is in "c:\program files\tcl8.5\bin" which is in the path variable.
  msys: sh tk8.5.9/win/configure outputs: No tclsh found on PATH

  Supposed reason:
  tk8.5.9/win/configure row 4173 replaces the path separator ":" with space.
  If there are spaces in a path component, it is also separated there by the following for loop

  Workaround: use the 8 char "PROGRA~1" version of the path.


tkt_uuid: 3078902fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: TK library goes into an infinite loop
comment:
  The tk library goes into an infinite loop in the file generic/tkImgPhoto.c in function Tk_PhotoPutBlock in the following code:
       /*
       * Copy and merge pixels according to the compositing rule.
       */
      for (hLeft = height; hLeft > 0;) {
          int pixelSize = blockPtr->pixelSize;
          int compRuleSet = (compRule == TK_PHOTO_COMPOSITE_SET);

          srcLinePtr = blockPtr->pixelPtr + blockPtr->offset[0];
          hCopy = MIN(hLeft, blockPtr->height);

          hLeft -= hCopy;
          for (; hCopy > 0; --hCopy) {
            .....
          }
       }

  The problem shows up when (for some yet unknown reason, the blockPtr->height is 0.
  In that case, hCopy becomes 0 and the loop counter hLeft never gets decremented.

  I have fixed this problem in the library I use by placing the following code after the line
   hCopy = MIN(hLeft, blockPtr->height);

  if(hCopy < 1) {
         break;
   }


tkt_uuid: 3082049fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Fixed
title: Bracket typo in Makefile.in
comment:
  In file win/Makefile.in, line 706, there is opening parenthesis and closing brace.

  genstubs:
   $(TCL_EXE) "$(TCL_TOOL_DIR}\genStubs.tcl" \ 


tkt_uuid: 3086887fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Accepted
title: Aqua <Expose> events redraw whole subwindow
comment:
  Run the attached script in Cocoa 8.6 Wish.  It creates 2 toplevels titled "OK" and "FAIL" with a text widget and scrollbar in each toplevel.
  The "FAIL" window has an additional frame widget around the text and scrollbar.

  If you scroll the text widgets you can see <Expose> messages in the console showing the %h and %w fields of the <Expose> events.

  For the "OK" window the height %h is what you'd expect, 15 pixels when one line is scrolled.
  For the "FAIL" window the height %h is the height of the entire text widget, meaning the whole text widget gets redrawn during scrolling.

  When I comment out the lines below in tkMacOSXWindowEvent.c GenerateUpdates() the problem goes away:

      if (!Tk_IsTopLevel(winPtr)) {
  ChkErr(TkMacOSHIShapeUnion, boundsRgn, updateRgn, updateRgn);
  HIShapeGetBounds(updateRgn, updateBounds);
      }


tkt_uuid: 3089640fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Improve squeezing of notebook tabs
comment:
  The current squeezing algorithm for ttk::notebook tabs adjusts each tab by the same number of pixels. As a result, the smaller tabs disappear quickly, There is also a -mintabwidth style option, but this doesn't work well either: first all tabs are reduced to the minimum width, but if there is still not enough place, the rightmost tabs will disappear again.
  The fact that tabs can disappear has been reported as a problem numerous times on comp.lang.tcl. An ideal solution would allow the tabs to be scrolled, but this seems to be quite hard. A different squeezing algorithm, which squeezes each tab relative to its width, can however also improve the current behavior.
  Attached is a patch with this modified squeezing algorithm. Note that it ignores -mintabwidth completely, as this does not make much sense anymore in the new algorithm. (The mintabwidth did not work well anyway, because it was already ignored in TabRowSize().)


tkt_uuid: 3091872fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Invalid
title: grid size&rowconfigure memory after destroying all children
comment:
  Issues:
  - grid size does not report "0 0" when all children are destroyed
  - there is a row without widgets occupying space

  Demo:
  newly started wish 8.5.9 on windows vista 32 bit:
  % grid size .
  0 0
  % grid [frame .f1 -bg yellow -width 10 -height 10] -sticky news
  % grid [frame .f2 -bg red -width 10 -height 10] -sticky news
  % grid rowconfigure . all -weight 1
  Resize the window to test
  % destroy {*}[winfo children .]
  % grid size .
  0 2
  This should say "0 0"
  % grid rowconfigure . 1 -weight
  1
  Should this be forgottn ?
  % grid [frame .f1 -bg yellow -width 10 -height 10] -sticky news
  If you resize the window now, the yellow bar does not go to the end.
  A cell without a widget is placed there.


tkt_uuid: 3095112fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.9
resolution: Fixed
title: crash when selecting file from Win7 Library
comment:
  tk_OpenFile crashes when I select file from Windows 7 virtual folders called "Libraries". sometime it display error message saying: "alloc: "invalid block: 0812C188: ef ef 0". ", sometime crashed silenly.
  It reproduces both with latest ActiveTcl 8.5.9 distribution and with self-compiled tcl/tk 8.5.9.


tkt_uuid: 30ce26f48d3c2d9513186c998885369636a8395e
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: 8.6.0
private_contact: b161dbf142556f12a9a6289ffc2a489dd98cabae
resolution: None
title: Key-Event bindings corrupt on Mac (Tcl 8.6.0)
comment:
  When porting my applications to 8.6.0, I encountered the following 
  problem with key events on Darwin:
  When pressing a key, you can also get the position of the mouse pointer 
  with the %X and %Y specifiers. I use this typically in combination with 
  "winfo containing".
  This used to work with previous versions of Tcl/Tk and still works on 
  Windows and Linux, but does not work with 8.6.0 on Mac (SnowLeopard, 
  Lion, MountainLion).


  Test script:

  package require Tk

  puts "Tcl [info patchlevel] on $tcl_platform(os) $tcl_platform(osVersion)"

  proc Print { eventType X Y x y } {
       set w [winfo containing $X $Y]
       puts "$eventType ($X $Y) ($x $y) Widget: $w"
  }

  set tw .
  set fr .fr

  frame $fr
  pack $fr

  listbox $fr.l1
  listbox $fr.l2
  pack $fr.l1 $fr.l2 -side top

  bind $tw <1> "Print ButtonPress %X %Y %x %y"
  bind $tw <Key-p> "Print KeyPress %X %Y %x %y"
  bind $tw <Escape> "exit"

  Here are some example outputs from my tests
  (note the zeros and negative values for 8.6.0 on Darwin):

  Tcl 8.6.0 on Windows NT 6.1
  ButtonPress (554 258) (49 62) Widget: .fr.l1
  KeyPress    (554 258) (49 62) Widget: .fr.l1

  Tcl 8.6.0 on Linux 2.6.34.10-0.2-desktop
  ButtonPress (51 470) (47 42) Widget: .fr.l1
  KeyPress    (51 470) (47 42) Widget: .fr.l1

  Tcl 8.6.0 on Darwin 11.4.2
  ButtonPress (184 477) (91 102) Widget: .fr.l1
  KeyPress    (0 0) (-93 -375) Widget:

  Tcl 8.4.18 on Darwin 11.4.2
  ButtonPress (100 185) (95 88) Widget: .fr.l1
  KeyPress    (100 185) (95 88) Widget: .fr.l1

  Tcl 8.5.8 on Darwin 11.4.2
  ButtonPress (64 190) (54 85) Widget: .fr.l1
  KeyPress    (64 190) (54 85) Widget: .fr.l1


tkt_uuid: 3101805fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Ugly buttons for tk_messageBox and tk_chooseColor
comment:
  I discovered this problem while working with the Tk Python binding. If you create a MessageBox or ColorChooser, it uses old-style Windows 98 buttons rather than sleek new Windows 7, VIsta or XP buttons. I've heard that the same problem exists on other desktops (Gnome specifically) as well. I initially reported the issue to the Python bug tracker, and after delving into the Python source I began to see that the problem was in the underlying Tk rather than Tkinter. See the original Python issue at http://bugs.python.org/issue10171.

  This problem can be reproduced in the most recent version of Tcl (I think, I know nothing of Tcl but I downloaded the Windows ActiveTcl 8.5 binary to test this) with the following 3 lines of code:

  package require Tk
  tk_chooseColor
  tk_messageBox

  I don't know what might be causing this problem, and I can't really fix it since I don't know Tcl. However, I'm pointing out this issue so that someone who can fix it can perhaps make a patch.

  Attached is a screenshot of the ugly button behavior.


tkt_uuid: 3102228fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: <<ListboxSelect>> Doesn't fire when selection lost
comment:
  Assuming that the selection state of a listbox reflects the physical state of a system, then <<ListboxSelect>> should fire whenever the selection state of the listbox changes. This happens for mouse clicks in the listbox, but not when the listbox loses the selection. Consider the following script. If one or more entries in the listbox are selected, then clicking "take" removes the selection (the entries are no longer highlighted). However, the bound "puts" doesn't fire to indicate this change in state.

  listbox .l
  .l insert 0 1 2 3
  pack .l
  button .b -text "take" -command {selection own .b}
  pack .b
  bind .l <<ListboxSelect>> {puts [selection get]}


tkt_uuid: 3105495fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 22. Style Engine
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Notebook Tabs on Mac Drawn in Center
comment:
  On the Mac, the tabs in a Notebook are drawn centered instead of aligned on the left (like PC and Linux).

  Here is an example script:

  ttk::notebook .n
  pack .n -side top -fill both -expand true
  frame .f1
  frame .f2
  .n add .f1 -text "Frame1"
  .n add .f2 -text "Frame2"


tkt_uuid: 3106893fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Notebook Tabs on Mac Drawn in Center
comment:
  Since 3105495 was closed, I cannot make comments. So I have opened a new case.

  Joe English stated that Tabs in the center is the OSX standard. We cannot think of any apps where this is true. Some examples of tabs on the left are:

  Excel, Safari, Adium. What apps under OSX have tabs centered?


tkt_uuid: 3107485fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: ttk::treeview heading height calculation bug
comment:
  Setting multiline text headings in the ttk::treeview widget shows a wrong calculation in heading height. This effect appears after the first time a treeview widget is destroyed. Any newly created treeview will have a heading height corresponding to a single line text.

  Demo script:

  package require Tk

  proc buildtree {tv} {
      catch {destroy $tv}
      ttk::treeview $tv -columns {hello bye} -show headings
      $tv column hello -width 120 -stretch 0
      $tv column bye   -width 120 -stretch 0
      $tv heading hello -text "Hello\n$tv"
      $tv heading bye   -text "Bye\n$tv"
      # this ought to work
      $tv heading #0 -text "H\nj"
      pack $tv
  }

  buildtree .tv1
  buildtree .tv2
  after 3000 buildtree .tv1


tkt_uuid: 3109856fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 6
foundin: obsolete: 8.5.9
resolution: None
title: canvas itemconfigure memory leak - Tk_Uid
comment:
  The attached script indicates a memory leak with canvas itemconfigure (possibly with just color handling).  Memory leak seen on both Windows and Linux.  This was first reported via Tkinter-discuss list.


tkt_uuid: 3110361fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: None
title: More visible indicator for radiobutton menu entries on X11
comment:
  The default indicator for radiobutton menu entries on X11 is too small and hard to see on modern displays. Attached  patch makes them a bit more visible


tkt_uuid: 3116922fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Duplicate
title: memory error in tk_get*File on Windows
comment:
  In tkWinDialog.c, OFNHookProcW, when browsing in the "Recent Places" directory, this call:

      dirsize = SendMessageW(hdlg, CDM_GETFOLDERPATH, 0, 0);

  results in dirsize == -1.  Then:

      buffer += dirsize
      SendMessageW(hdlg, CDM_GETSPEC, selsize, (int) buffer);

  writes before the start of the buffer. Then:

      buffer[selsize] = '\0';/* Second NULL terminator. */
      buffer--;
      *buffer = '\\';

  again writes before the start, all causing ckrealloc() to later fail
  due to the ofnData->dynFileBuffer getting messed up.


tkt_uuid: 3117468fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.5.9
resolution: Works For Me
title: Malformed %A substition under solaris.
comment:
  %A substitution in bind scripts is broken.
  For example, character å becomes å5þpNþ(converted to hex: E5 35 FE 70 06 4E FE 01).
  In Unicode å is denoted by U+00E5.
  The garbage is different depending on the previously entered character (å is substituted correctly when it is the first character sent to the wish process).

  This behavior can be seen in Tcl/Tk 8.5.9, but not in 8.5.8.

  This is similar to 3080953, but this is seen under solaris as well.

  System information:
  $ uname -a
  SunOS simx 5.10 Generic_137138-09 i86pc i386 i86pc Solaris
  $ locale
  LANG=en_US.ISO8859-1
  LC_CTYPE="en_US.ISO8859-1"
  LC_NUMERIC="en_US.ISO8859-1"
  LC_TIME="en_US.ISO8859-1"
  LC_COLLATE=sv_SE.ISO8859-1
  LC_MONETARY="en_US.ISO8859-1"
  LC_MESSAGES="en_US.ISO8859-1"
  LC_ALL=


tkt_uuid: 3119824fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.16
resolution: None
title: Enter doesn't work in text input box
comment:
  Sorry if this is in the wrong place: I'm assuming that it's your responsibility as a toolkit, but it might just be something stupid that client programs are doing.

  git gui's Commit Message text input widget doesn't respond to the Enter key (on the keypad) but it responds to the Return key (on the main keboard area) fine.

  I wonder whether this is a regression caused by fixing bugs 1233009 1327482 and 787402.

  If this is in fact a git-gui bug (them failing to bind enter properly or something) or is fixed in the latest version of tk, I'm sorry for wasting your time.


tkt_uuid: 3122271fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: Selecting in a ttk::combobox listbox can remove focus
comment:
  On Linux systems, hitting enter on a listbox item of a ttk::combobox causes the combobox to lose focus if the combobox's parent window has the overrideredirect flag set. No such problems on Windows. All is well if the overrideredirect setting is removed.


tkt_uuid: 3126428fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::button does not show image change
comment:
  A ttk::button displays an image.
  If the image changes in a) contents or b) size, this is not correctly displayed.
  A contents change is updated if the widget is redrawn.
  A size change is only updated if the image is configured again to the button.
  Within a non-themed button widget, an image change is directly displayed.

  Sample procedure on an interactive wish8.5.9 and Windows Vista 32 bit Aero Theme:
  % image create photo i -height 30 -width 30
  % i put red -to 0 0 29 29
  % pack [button .b1 -image i] [ttk::button .b2 -image i] [ttk::button .b3 -image i] -side left
  #-> 3 red buttons

  % i put black -to 0 0 29 29
  #-> Only button 1 changes color

  % .b2 configure -image i
  #-> Button 2 changes color

  # minimize and maximize window -> all button black

  % i configure -width 100 -height 100
  #-> only button 1 changes size

  % .b2 configure -image i
  #-> Button 2 changes size

  # minimize and maximize window -> no change 


tkt_uuid: 3130038fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: -dash crash in canvas lines
comment:
  The canvas -dash option regularly causes X_CreateGC X errors when running on Mac OS X in X11 mode over ssh to a debian etch (linux) desktop. I don't have console access to a Mac to test this locally so I cannot say if it's reproducable when using a local X11 server or when using the aqua native interface.

  The example code:

  set c [canvas .c -bg black]
  pack .c -fill both -expand 1
  bind .c <Any-Motion> {xhair_move .c %x %y}
  bind .c <Any-Leave> {.c delete withtag xhair}

  proc xhair_move {c x y} {
      $c delete withtag xhair
      $c create line $x 0 $x 1000 -tags xhair -fill green -dash {6 4 2 4 2 4}
      $c create line 0 $y 1000 $y -tags xhair -fill green -dash {6 4 2 4 2 4}
  }

  On linux this works fine. On Mac OS (darwin 9.8.0) with a local build of tk 8.5.9 it sometimes draws a line and sometimes fails with:

  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  55 (X_CreateGC)
    Value in failed request:  0x340000a
    Serial number of failed request:  316
    Current serial number in output stream:  324

  This is inside the X libraries:

  #0  0x945b8c75 in exit ()
  #1  0x0014e0ea in _XDefaultError ()
  #2  0x0b01a2c6 in ErrorProc (display=0x80da00, errEventPtr=0xbfffe020) at /nfs/sam_scratch/jkb/src/tk8.5.9/unix/../generic/tkError.c:285
  #3  0x0014e1ef in _XError ()
  #4  0x0014e7d3 in _XReply ()
  #5  0x0014877a in XSync ()
  #6  0x00148819 in _XSyncFunction ()
  #7  0x0012aa49 in XCreateGC ()
  #8  0x0b0238a7 in Tk_GetGC (tkwin=0x4323b0, valueMask=3145972, valuePtr=0xbfffe268) at /nfs/sam_scratch/jkb/src/tk8.5.9/unix/../generic/tkGC.c:256
  #9  0x0b0795fc in ConfigureLine (interp=0x806a00, canvas=0x4264e0, itemPtr=0x48a650, objc=6, objv=0xe53a4, flags=0) at /nfs/sam_scratch/jkb/src/tk8.5.9/unix/../generic/tkCanvLine.c:524
  #10 0x0b079087 in CreateLine (interp=0x806a00, canvas=0x4264e0, itemPtr=0x48a650, objc=10, objv=0xe5394) at /nfs/sam_scratch/jkb/src/tk8.5.9/unix/../generic/tkCanvLine.c:334
  #11 0x0b069688 in CanvasWidgetCmd (clientData=0x4264e0, interp=0x806a00, objc=13, objv=0xe5388) at /nfs/sam_scratch/jkb/src/tk8.5.9/unix/../generic/tkCanvas.c:977

  Bizarrely, using "-dash -.." works, despite this in theory being identical to {6 4 2 4 2 4}. Also {6 4 2 4} works. Experimentally it just seems to be any dash pattern longer than that, so maybe it's a corruption in the dash parsing code.


tkt_uuid: 3137232fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: spinbox error after destroying toplevel from widget
comment:
  #!/bin/sh
  #\
  exec vmwish "$0" ${1+"$@"}

  ################################################################################
  # Fehlerbeschreibung:
  #   1. <Button-1> auf dem "Pfeil oben"-Knopf gedrückt halten bis Spinbox automatisch hochgezählt wird. 
  #   2. Dann mit gedrückter Maustaste den Knopf verlassen. (Endlosschleife in ::tk::spinbox::Invoke)
  #   3. dann die Maustaste ausserhalb los lassen und dann den Knopf "Zerstöre Toplevel" drücken.
  #   4 . nach Abschluss der for-Schleife => Applikationsfehler da Spinbox in der Schleife ::Invoke 
  #       nicht mehr existiert.
  ################################################################################

  ################################################################################
  # Bug in spinbox.tcl
  #1. Hold mouse button over the "buttonup arrow" till the spinner automatically increment the value. 
  #2. Then move the mouse cursor while hold Button-1 pressed away from the "buttonup arrow" and now button release.
  #3. Then TK enter a loop ::tk::spinbox::Invoke in /usr/lib/tcl/tk8.5/spinbox.tcl
  #4. Now press the button "Destroy Toplevel" while -command "todo" proc is computing.
  #5  After finishing the -command todo proc a Application Error occurs.
  #
  #6. Sorry for my english...
  #invalid command name ".t.sp"
  #invalid command name ".t.sp"
  #    while executing
  #"$w cget -repeatinterval"
  #    (procedure "::tk::spinbox::Invoke" line 8)
  #    invoked from within
  #"::tk::spinbox::Invoke .t.sp buttonup"
  #    ("after" script)
  #


  ################################################################################
  # use this example-code to test the error.

  wm withdraw .
  toplevel .t
  set sp [spinbox .t.sp \
               -validate key \
               -command todo \
               -width 2 \
               -from 1 \
               -to 99 \
               -increment 1]
  pack $sp
  pack [button .t.b -text "Destroy Toplevel" -command beenden]

  ################################################################################ 
  proc todo {} {
     for {set i 0 } {$i < 2500} {incr i} {
        puts "$i Datum: >>[exec date]<<"
     }
     return
  }
  ################################################################################
  proc beenden {} {
     destroy .t
     return
  }


tkt_uuid: 3138512fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: None
resolution: None
title: Tk applicatications after grab command (both local/global mo
comment:
  XP SP2,XP SP3,..,Win7 32-64bit
  Tk 8.5.9 ,8.6.0 (but not 8.4.*)

  1) start any application, for example: notepad.exe
  2) start ..>Demos>TK 
       Miscellaneous > 2. A dialog box with a local grab. 
  3) click on Task_Manager/Show_Desktop button
  4) click on Task_Manager/notepad.exe icon (or any others Task_Manager icons)

  Oops.. (Tk application minimized forever)

  Bug #3009450 ?


tkt_uuid: 3146418fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: tk_getSaveFile: alloc invalid block ... crash
comment:
  Use the following line to crash Tk:
  tk_getSaveFile -initialdir c:/users -defaultextension .xyz -filetypes {{{Curve} .curve}} -initialfile myfile -parent .

  In the dialog you have to click on "Computer" and then back on a drive e.g. D: ... then click on save - Tk crashes.
  Happens in W7.

  thx


tkt_uuid: 3147952fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: Out of Date
title: smarter updating of ttk::treeview display
comment:
  I propose some combination of visible set determination, a better search structure, and throttled GUI updates be implemented for a reasonable balance between keeping the GUI responsive and inserting a large data set into a ttk::treeview widget (and perhaps other data display widgets).

  The cost of updating the display for a ttk::treeview appears to be proportional to the number of non-detached items.  This is a problem if you want to load a large data set (hundreds of thousands or millions of items) and start seeing things right away.  Maybe the treeview is not designed for this purpose, but I didn't find the multicolumn widget that is.  So far I have found the following options, all at least somewhat unsatisfactory:

  1. Don't update.  This gets everything inserted in the minimum amount of time, but locking up the GUI for several seconds is not really acceptable.
  2. Update after every insertion.  This keeps the GUI responsive but it takes orders of magnitude too long to insert all the items, even for a very moderate number of items (tens of thousands).
  3. Update only after some time elapsed or number of insertions, or some adaptive scheme involving both.  A huge improvement over (2) but still way too slow for large data sets.  Also, I don't think "post redisplay" is something I should have to implement myself.
  4. Insert everything as a child of a detached item and make them the children of {} only at the very end.  The GUI remains responsive and the insertions complete in a reasonable amount of time as long as you implement (3), but nothing is displayed until all the items are inserted.
  5. Insert and update normally until the visible area is full and then switch to (4).  But what if the user changes the viewport before everything is inserted?

  If we could maintain the visible set of items and insert items and compute their geometry without actually realizing them, then updates could basically take constant time as long as the viewport remains constant.  If we maintained better search structures, then inserting at arbitrary locations and viewport changes could be handled nicely as well.  That would also address the (undocumented?) quadratic running time of inserting all items at the end.  And if GUI updates were throttled in general then I maybe would simply be able to use plain old update instead of workaround (3)?


tkt_uuid: 3152603fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Cascade entry stops working if reconfigured with same -menu
comment:
  When a cascade menu entry is reconfigured with its current value for -menu, the
  submenu is no longer responsive to mouse actions. The problems seems to be that
  the -menu option on the cloned menu gets updated to the non-cloned submenu. The
  following code demonstrates the problem:

  . configure -menu [menu .menu]
  .menu add cascade -label Sub -menu [menu .menu.sub]
  .menu.sub add command -label Foo
  .menu.sub add command -label Bar
  # At this point the submenu works as expected
  puts [.#menu entrycget end -menu]
  # -> .#menu.#menu#sub
  .menu entryconfigure end -menu .menu.sub
  puts [.#menu entrycget end -menu]
  # -> .menu.sub
  # The submenu does not respond to mouse actions.

  Linux 2.6.34.7 x86_64 with Tcl/Tk compiled from sources. 
  I found the problem on Tk 8.5.9, but could reproduce on a fairly recent 8.6b1.2.

  This is a different issue from bug #1723059


tkt_uuid: 3160086fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: invalid command name "SpinBox::config"
comment:
  Reproduce the error:

  package re cursor
  cursor::propagate . watch

  ... you need to have a SpinBox in your app ...

  thx


tkt_uuid: 3164879fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: error dialog during test suite
comment:
  During a `make test` on the Tk HEAD,
  while "select.test" is running, an error reporting
  dialog box pops up.  Requesting the stack
  trace produces:

  wrong # args: should be "errIncrHandler type offset count"
  wrong # args: should be "errIncrHandler type offset count"
      while executing
  "errIncrHandler STRI>on 0 4000"
      (command handling selection)


tkt_uuid: 3166688fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: Wont Fix
title: Cocoa: using pack/forget to switch pages doesnt refresh
comment:
  Using Cocoa on OSX and grid or pack and grid/pack forget to switch between pages (similar to notebook widget) causes switching between pages not to refresh correctly.

  Refresh happens partially and rest occurs after some time.

  Noticed on Wish 8.5.7 Cocoa from OSX 10.6.2, ActiveTcl 8.6 beta 3 (beta 4 is compiled against Carbon) and Tcl/Tk Head.


tkt_uuid: 3170714fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Works For Me
title: Menubutton and -direction flush does not work properly with
comment:
  When running attached code item selection works fine for first time, subsequently it seems to be hanging in OSX system call - probably due to Tk not passing mouse movement events.

  Clicking on menubutton multiple times causes the program to occasionally hang - doe snot change selected item and releasing mouse button does not cause item to be selected.

  Changing -direction or disabling -indicatoron still works - only this combination fails. When enabling Carbon events tracing, first click causes both button up/down events and move events to be received. Subsequent clicks only cause information on mouse up/down to be printed - and this might be the root of the problem.

  Sample Tcl code works fine with Tk up to 8.5.6 - 8.5.7 is the first release where this code does not work. Since CVS is down (at least as of now) I have not been able to determine more exact date when it broke.

  It can also be reproduced by doing [$menu post] on top of menubutton manually.


tkt_uuid: 3175610fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Modifying canvas line item forgets to refresh
comment:
  Using "insert" to modify a line item, as in

    $canvas insert $line $position {$coords}

  misses the refresh, as can be seen in

       #!/usr/bin/wish
       pack [canvas .c]
       set line [.c create line 10 10  210 10 -fill blue]
      update
      after 2000
      .c insert $line 2 {110 110}

  Partially obscuring the canvas with another window and exposing it again fixes the display.
  Tested on Debian Gnu/Linux squeeze with Tk 8.4, 8.5 and 8.6 (the first two are standard distro packages).

  Alexandre Ferrieux kindly provided a patch in cmp.lang.tcl, which I attach (I haven't had the time to test it yet, though).

  References: comp.lang.tcl:<87fws1v827.fsf@floh.bas23>, comp.lang.tcl:<dc596818-a0d4-4e3a-99a5-55446de6e574@s3g2000vbf.googlegroups.com>


tkt_uuid: 3181181fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Torn-off sub menus no longer show on XP !
comment:
  Regression is in Tk HEAD as of Feb 13, 2011.
  Regression also appeared between 8.5.8 and 8.5.9.
  Code to reproduce : http://paste.tclers.tk/2356

  It appears that 
    1. Cascaded torn-off menus will not show up anymore when selected with the ------ line;
    2. Non cascaded torn-off menus will not show up if their "parent" toplevel is withdrawn.

  Looks OK with Linux. XP issue.


tkt_uuid: 3184834fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: xft detection script should directly link with freetype
comment:
  The xft detection script should directly link with the freetype, otherwise the xft is not detected on systems with disabled indirect linking (e.g. Fedora). This bug originates from: https://bugzilla.redhat.com/show_bug.cgi?id=677692


tkt_uuid: 3192483fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Invalid
title: undo/redo not properly working
comment:
  Try the following script:

  -------------------------------------------------------------------------------------
  set bold [list [font configure TkTextFont -family] [font configure TkTextFont -size] bold]
  pack [text .t -font TkTextFont -undo yes]
  .t tag configure bold -font $bold
  .t insert insert "the last word is "
  .t insert insert "bold" bold
  .t insert insert "."
  -------------------------------------------------------------------------------------

  Now do the following:
  1. Select the word "bold"
  2. Delete this word (press DEL)
  3. Undo the change (press Ctrl-z)

  After the undo the word "bold" has the wrong font. The undo/redo mechanism should regard the tags, otherwise the result is wrong. E.g in my application I'm using special fonts with the use of tags. If I enter a special symbol "\u0001" of this font (with the appropriate tag), after delete & undo this symbol will be shown with the wrong font, that means it is the wrong text (garbage in this case).


tkt_uuid: 3196296fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
severity: Minor
foundin: None
resolution: Invalid
title: TkAqua Cocoa port merge breaks backwards compatability
comment:
  After merge of TkAqua Cocoa port struct TkWindowPrivate lacks CGrafPtr grafPtr that was used in Togl. This change breaks MacOS users ability to use legacy Togl applications wit Tk 8.5.9.
  http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/macosx/tkMacOSXInt.h?r1=1.32&r2=1.33

  http://comments.gmane.org/gmane.comp.lang.tcl.mac/6828
  http://lists.osgeo.org/pipermail/grass-user/2011-February/059680.html
  http://lists.osgeo.org/pipermail/grass-user/2011-February/059626.html


tkt_uuid: 3202950fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Duplicate
title: ttk::menubutton dropdown arrow cut off on Windows 7
comment:
  toplevel .t
  ttk::menubutton .t.test -text "Foo"
  pack .t.test

  The right third of the drop-down arrow indicator is cut off.
  When moving the mouse over the item, highlighting shows a very narrow vertical slice being allocated for the dropdown half.
  Only happens with XP and Vista themes on Windows 7.  Does not occur under XP, have not tried Vista.
  Tried playing with layout and padding in both TCL and C (ttkWinXPTheme.c) without any effect.


tkt_uuid: 3205153fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: None
resolution: None
title: Tk does not handle input-manager input on Mac OS X
comment:
  OS X allows the user to enter accented and CJK characters through system-provided input methods, similarly to IME on Windows and XIM on X11.  While the latter two are supported in Tk, the former is not.

  Currently on the Carbon Tk implementation there is limited support for entering accented characters, however the "working" text (usually an underlined form of the accent component itself) is not shown.  The Cocoa version does not even support this, and neither supports CJK entry at all.


tkt_uuid: 3205260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: [wm manage] crash
comment:
  Under windows, using [wm manage] on a frame containing a Tkhtml3 widget crashes.
  In fact, RemapWindows() in win/tkWinWm.c checks that the class of window is not "Menu".
  Since Tkhtml3 creates a child window without setting the class, this check crashes.
  Checking that the class is not NULL before calling strcmp will fix it.
  The unix and macosx implementations of RemapWindows() don't check the class (tk8.5.9).


tkt_uuid: 3205464fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: [wm forget] lose window
comment:
  Under Windows XP, Tk 8.5.9.
  If [wm forget $w] is called when $w original parent is not mapped, the window is "lost".
  The attached script demonstrates the problem: it creates a notebook with 5 tabs.
  Right click on a tab detach the content with [wm manage] in a toplevel.
  Close the toplevel, the content get back into tab page, but only if original tab page is raised.
  If you raise another page or iconify the application and then close the toplevel, the content is not visible anymore.
  Calling again [wm manage] on the same tab displays a toplevel without redraw.
  Looks like a flag is not well reset in [wm forget], although [wm ismapped] and [wm viewable] return 1.


tkt_uuid: 3217462fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: Tri-state buttons not working for non-native themes
comment:
  ttk::checkbutton and ttk::radiobutton are supposed to show an undetermined state, when the associated variable is unset. For native themes under windows and macosx, this works fine. For non-native themes, the buttons  switch to the alternate state, but there is no visual difference. On X11, every possible theme is affected (all are non-native). 

  The attached script shows the problem


tkt_uuid: 3223850fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Button remains stuck when disabled as depressed on XP
comment:
  Problem reproduced on Win XP SP3, unable to reproduce on Ubutnu 8.04. Activestate 8.5.7.
  The problem arises when left mouse button is depressed over a ttk::button (setting the button in the 'depressed' state), and then an event disables this button, while the mouse button is still depressed. Then the mouse button is released.When the button is re enabled later, it remains visually depressed. Another std click on this button set it back to normal state.
  Unsure fact (to be verified) : It seems that not moving the mouse pointer during these operations makes it more reproducible.


tkt_uuid: 3234167fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Image and font problems on Tk Cocoa Buttons
comment:
  Last-CVS Tk.

  Image button displays the image off-center and if border width 0 will obscure one pixel around the image.
  Text buttons, if the font is set, seem to be setting their size based on the point size rather than querying the font's metrics.
  These problems are specific to Tk Cocoa and do not occur under Tk Carbon.
  The following script reproduces, and the attached zip contains the image and screenshots of the results.


  #!/usr/bin/wish

  # Reproduce Tk-Cocoa button issues
  # Last-CVS version as of 2011-03-22

  set searchButtonImg [image create photo -file "searchButton.gif"]

  toplevel .l
  wm title .l [expr { $tcl_platform(pointerSize) == 8 ? "Cocoa" : "Carbon" }]

  frame .l.i
  frame .l.t

  button .l.i.b1 -image $searchButtonImg -borderwidth 0
  button .l.i.b2 -image $searchButtonImg -borderwidth 1

  set cfont [font create -family 华文楷体 -size 24]
  set tfont [font create -family Courier -size 24]
  button .l.t.b1 -font $cfont -text "华文楷体"
  button .l.t.b2 -font $tfont -text "Courier"

  pack .l.i.b1 -padx 10
  pack .l.i.b2 -padx 10

  pack .l.t.b1 -padx 10
  pack .l.t.b2 -padx 10

  pack .l.i -pady 10
  pack .l.t -pady 10


tkt_uuid: 3235256fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Menus stop working (Windows only)
comment:
  Source the attached file into wish (any version from 8.4.13+). It will create a lot of menus (but will not error). Now all menus on all toplevels will fail to show cascade menus (they select other menus instead). This only happens on Windows (XP64 tested).


tkt_uuid: 3239768fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk8.4.19 (and later) WIN32 menu font support
comment:
  Enclosed is a patch which allows tk8.4.19 when built with newer Microsoft
  compilers (MSVC 2008)  to correctly get the menu font information.  The
  problem is that the size of ncMetrics is larger when using the newer compilers
  causing the SystemParametersInfo call to fail on win2k/win2k3/winxp.  This
  results in the menu font being ill defined (e.g. Arial 396 which is huge).

  Changes:

    1) In SetDefaults adjust the size of ncMetrics when running on older
       operating systems as describe in the remarks section of:

         http://msdn.microsoft.com/en-us/library/ff729175(v=VS.85).aspx

  Notes:

    1) It appears from looking at the tk8.5.9 and tk8.6b1 source code that
       the problem is also present in those releases.

    2) This may require work to support older compilers which are missing
       iPaddedBorderWidth.


tkt_uuid: 3259766fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 7 High
foundin: obsolete: 8.5.9
resolution: Duplicate
title: Doubleclick events lost in Korean Windows
comment:
  If you install and select the Korean language on Windows, then binding an event for doubleclick (any button) does not work.

  I found this discussed at http://wiki.tcl.tk/12731 but without any solution so far. I can add some more details.

  You do not need a Korean version of Windows to reproduce the bug. I took an ordinary Windows XP SP3 and added the Korean language by going Control Panel -> Date, Time, Language and Regional Options -> Add Other Languages -> Language tab -> Details. Then in the Installed Services pane, hit Add and select Korean from the 'Input language' pulldown menu in the popup box. The 'Keyboard layout/IME' pulldown will also show 'Korean' -- leave this there and keep hitting OK till all dialogues are gone. You can now click on the language selector in the toolbar that normally says 'EN" (or whatever your default language is) and select 'KO' -- you will then see the bug. Note that it sporadically reverts to the default language.

  The other interesting thing is that the bug does not apply to canvas items. It seems to apply to all widgets, but try this:
  pack [canvas .c]
  .c create rectangle 100 100 300 200 -fill orange
  bind .c <Double-1> {puts PING}
  .c bind 1 <Double-1> {puts PONG}

  Now with your language set to EN you get PING if you doubleclick on the canvas background, and PONG PING if you doubleclick on the rectangle. But set the language to KO and you get nothing for a doubleclick on the background, and PONG for a doubleclick on the rectangle.

  Please fix this quickly, it is annoying our Korean resellers!


tkt_uuid: 3281130fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 7 High
foundin: obsolete: 8.5.7
resolution: None
title: tk segfaulting due to Xft fonts
comment:
  Please take a look at 
  http://stackoverflow.com/questions/5488429/tk-segfaults-when-i-use-widget-button-text


tkt_uuid: 3285355fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 7 High
foundin: obsolete: 8.6b1
resolution: Fixed
title: Active Tcl/Tk 8.6b5 hangs for simple example
comment:
  When selecting Open in the attached Tcl/Tk script an error message should appear and report that procWhichDoesNotExist does not exist. However, Tcl/Tk seems to hand, displaying a white rectangle (where the error message should be) in front of all other windows. Even switching to other Mac applications does not make the rectangle disappear; only killing Wish works (using Force Quite for example).

  The bug appears on a MacPro Intel Xeon 6-core processor using the latest Active Tcl/Tk 8.6b5. 
  This bug is an example for a variety of similar issues which currently make Tcl/Tk unusable on the Mac (at least for our application). I believe that 8.5.9.2 has the same problem (Active Tcl 8.5.9.0 works perfectly).

  This bug was previously posted as bug #89715 to http://bugs.activestate.com.


tkt_uuid: 3291543fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk crash with polygon dchars
comment:
  This short snippet causes a crash:
  =====
   canvas .a
   pack .a
   .a create polygon 0 0 0 10 10 0
   .a dchars 1 2 end
   .a coords
  =====
  When I run it I get "alloc: invalid block: 0x595020: b0 0".  Interactively it does not crash immediately, but does a few commands later.


tkt_uuid: 3294450fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.5.9
resolution: Fixed
title: Ttk label does not show multiline text if widget clipped
comment:
  Given a ttk label widget with two text lines like:
  "ABCDEF
  ABC"
  The widget is packed in such a way, theat the x space is not sufficient and the last character of the first line is not shown.
  In this case, the output is:
  "ABCDE
  "
  thus the second row is empty.
  IMHO it should be:
  "ABCDE
  ABC"

  Test code:
  % pack [ttk::label .l -text [string repeat 1234567890 10]\nrow2\nrow3]
  % wm resizable . 1 1
  Resize the window in x direction until the first text line is clipped.

  Platform: Windows Vista Pro 32 bit
  wish 8.5.9 self compiled with MSVC6


tkt_uuid: 3294593fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Submenus not unposting at all expected times after tip #360
comment:
  After the implementation of tip #360 cascade entries behave inconsistently. Sometimes the submenu is unposted when moving the mouse to another entry, but most of the time the submenu stays up. Pat Thoyts indicated on the Tcl chat that the intended behaviour is that the menu gets unposted. The attached patch accomplishes that.


tkt_uuid: 3295436fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: console doesn't handle <<PasteSelection>>
comment:
  The <<PasteSelection>> event isn't properly handled by console.  It just inserts the text wherever the mouse pointer is, even though this can corrupt the displayed history.  Or, pasting to the "right" location by pointing at the insertion cursor, sometimes fails to put the text into the input buffer.  This handler is inherited from the text widget.

  <<PasteSelection>> is generated by middle-clicking (<ButtonRelease-2>), according to tk.tcl.

  One possible approach is to handle <<PasteSelection>> in the same way as <Insert>, disregarding mouse pointer position.  Another is to attempt to position the insertion cursor to the pointer position but to constrain it to the input line before inserting, the same as clicking and typing.


tkt_uuid: 3295446fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Should [.console see end] in [ConsoleHistory]
comment:
  When using the up and down arrow keys to browse through the console history, the console frequently gets in a situation where the insertion cursor and all but the first line of historical input are offscreen, making it difficult to see which old command is currently selected.  The solution is simple: add [.console see end] to the end of the prev and next blocks of [::tk::ConsoleHistory] in console.c.


tkt_uuid: 3301481fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::spinbox on windows doesnt handle -width 0
comment:
  Setting -width to 0 on a ttk::spinbox (Windows version) sets its entry field to only show 1 character, instead of allowing as many characters as possible in the available space (as in the ttk::entry/spinbox case). Linux handles this correctly.


tkt_uuid: 3301552fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 1 Zero
foundin: obsolete: 8.5.9
resolution: None
title: ttk::spinbox -font does not resize buttons
comment:
  tk8.5.9 on Windows Vista with native theme.
  ttk::spinbox with a custom large font.
  There apears space between the spinbuttons.
  See http://wiki.tcl.tk/22156 for an example and a screenshot

  This is not a bug, but the graphical presentation might be nicer.

  Thank you for all the work making Ttk so great !


tkt_uuid: 3305175fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Duplicate
title: tk_popup incorrectly placement on Windows
comment:
  I have encountered an issue propably similar to closed bug 2548722.

  <Code>
  pack [ttk::menubutton .t -text abc -direction right]
  menu .t.s -tearoff 0
  for {set m 0} {$m < 20} {incr m} {
  .t.s add command -label m$m
  }
  .t configure -menu .t.s
  </Code>
  Environment:
  Wish 8.5.9 on Windows Vista with screen size: 1600x1024
  Reproduce:
  When I place the wish window at the lower border of the screen and press the button, the menu appears in the center of the screen (in y axis) far away from the menubutton.

  When I trace the called functions and do it manually, I get the same effect.
  % ttk::menubutton::PostPosition
  95 1005
  % tk_popup .t.s 95 1005

  So, there seams to be an issue of the "post menu above anchor point".

  Thank you,
  Harald


tkt_uuid: 3306909fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::menubutton -dir right wrong menu placement
comment:
  Bug report 3305175 descibes, that the menu is placed in screen center far away from the menu button, if the menu is posted with a widget at the lower screen border:
  ttk::menubutton .b -direction right

  IMHO, a good menu placement strategy is:

  Given a Menubutton with y borders at by0, by1.

  The menu to post with y borders my0,my1
  and the menu height: dmy=my1-my0

  If by0+dmy fits onto the screen, post the menu with: my0 = by0
  If by0+dmy do not fit on the screen:
  - current solution (I suppose): my1 = by0
  - proposed solution: my1 = by1
  E.g. allign the lower widget end if menu is posted upwards.

  The following modification:
  - implements that for directions left and right
  - does hide bug 3305175

  - File tcl8.5\lib\tk8.5\ttk\menubutton.tcl -
    - Procedure ttk::menubutton::PostPosition
      - insert below switch -- $dir {...}
        (Line 101)
  <code>
  # Align the lower ends of button and menu, if no place to show menu
  # downwards
      if { $dir in {"left" "right"} && $y >= $sh } {
          set y [expr {$y-$mh+$bh}] }
      }
  </code>


tkt_uuid: 3307625fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: scroll region of text limited to 32767 pixels
comment:
  Attached script adds a [text] item of 5000 lines
  to a canvas.  Attempts to scroll to the end get 
  stuck as they try to pass 32767 pixels.


tkt_uuid: 3310586fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Doubleclicks generated at any speed
comment:
  If you use 'event generate' to send mouse button events to a widget, all but the first come out as doubleclicks, no matter what the time interval between them. You only get another single click after a real click. e.g.,
  % pack [canvas .c]
  % bind .c <Button-1> {puts aah}
  % bind .c <Double-1> {puts ooh}
  % event generate .c <Button-1>
  aah
  % # now wait a bit
  % event generate .c <Button-1>
  ooh
  % # now wait a bit
  % event generate .c <Button-1>
  ooh
  % # now actually click in .c
  % aah
  # now doubleckick in .c
  % aah
  ooh
  event generate .c <Button-1>
  aah


tkt_uuid: 3313032fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::spinbox doesn't expand its height on Linux
comment:
  The height of the entry field in a spinbox widget remains constant even when it should grow to fill its available space.

  ttk::frame .fm
  ttk::spinbox .fm.sb
  pack .fm.sb -fill both -expand 1
  pack .fm -fill both -expand 1

  #Other widgets, entry, spinbox, ttk::entry expand to fill the available vertical space. (Noticed on Linux)


tkt_uuid: 3315643fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: allow to disable hidden files in Unix/Linux
comment:
  Tweaking the file tkfbox.tcl allows to make displaying hidden files in Linux/Unix optional by changing lines:
    set ::tk::dialog::file::showHiddenVar 0
    set ::tk::dialog::file::showHiddenBtn 1
  It should be set like this for Linux/Unix by default. It would give much better experience to the user.


tkt_uuid: 3315731fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: entry validation bug in Tk 8.6
comment:
  The entry widget validation doesn't work if the -invalidcommand option was set.  Example:

  entry .e -invalidcommand bell -validate key -validatecommand {regexp {^[0-9]*$} %S}
  grid .e

  Pressing a non-numeric key will ring the bell, but the character will be inserted into the widget.

  This behavior is absolutely not acceptable.  The bug seems to have been introduced in Tk 8.6.


tkt_uuid: 3341056fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.10
resolution: Fixed
title: Usage of recreated ttk::checkbutton causes crash
comment:
  - Since version 8.5.10 of Tcl and Tk only, it's not happening in 8.5.9. Not tested in other versions. Reproduced on Linux and a Virtualbox Windows installation.
  - The issue: if a ttk::checkbutton is destroyed and recreated - meaning another checkbutton with the same path is created - , activating the button causes a crash. The problem seems to be the widget's variable, if the widget's <Destroy> event is bound to unset its variable, the crash doesn't occur.
  - To reproduce: in case the description is not sufficient to reproduce from scratch, run the attached Tcl script with tclsh or wish, then press the button labeled "Button" for two times, then press the checkbutton labeled "Enabled   ".
  - Operating system: Arch Linux 64bit, kernel version 2.6.39.1.
  - Tcl built with:
  ./configure --prefix=/usr --mandir=/usr/share/man --enable-threads --enable-64bit (--enable-symbols)
  - Tk built with:
   ./configure --prefix=/usr --mandir=/usr/share/man --enable-threads --enable-64bit (--enable-symbols)
  - The Valgrind output after the error:
  ==10686== Invalid read of size 8
  ==10686==    at 0x4ED55A1: Tcl_GetString (tclObj.c:1579)
  ==10686==    by 0x6D92C98: CheckbuttonVariableChanged (ttkButton.c:450)
  ==10686==    by 0x6DAA9F5: VarTraceProc (ttkTrace.c:69)
  ==10686==    by 0x4EF584C: TclCallVarTraces (tclTrace.c:2639)
  ==10686==    by 0x4EFD45C: TclPtrSetVar (tclVar.c:1904)
  ==10686==    by 0x4EFF672: Tcl_ObjSetVar2 (tclVar.c:1718)
  ==10686==    by 0x6D92A35: CheckbuttonInvokeCommand (ttkButton.c:543)
  ==10686==    by 0x6DAA782: Ttk_InvokeEnsemble (ttkTheme.c:1679)
  ==10686==    by 0x6DB0A2F: WidgetInstanceObjCmd (ttkWidget.c:161)
  ==10686==    by 0x4E5F137: TclEvalObjvInternal (tclBasic.c:3699)
  ==10686==    by 0x4EA1EB1: TclExecuteByteCode (tclExecute.c:2416)
  ==10686==    by 0x4EA930F: TclCompEvalObj (tclExecute.c:1538)
  ==10686==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
  ==10686== 
  ==10686== 
  ==10686== Process terminating with default action of signal 11 (SIGSEGV)
  ==10686==  Access not within mapped region at address 0x8
  ==10686==    at 0x4ED55A1: Tcl_GetString (tclObj.c:1579)
  ==10686==    by 0x6D92C98: CheckbuttonVariableChanged (ttkButton.c:450)
  ==10686==    by 0x6DAA9F5: VarTraceProc (ttkTrace.c:69)
  ==10686==    by 0x4EF584C: TclCallVarTraces (tclTrace.c:2639)
  ==10686==    by 0x4EFD45C: TclPtrSetVar (tclVar.c:1904)
  ==10686==    by 0x4EFF672: Tcl_ObjSetVar2 (tclVar.c:1718)
  ==10686==    by 0x6D92A35: CheckbuttonInvokeCommand (ttkButton.c:543)
  ==10686==    by 0x6DAA782: Ttk_InvokeEnsemble (ttkTheme.c:1679)
  ==10686==    by 0x6DB0A2F: WidgetInstanceObjCmd (ttkWidget.c:161)
  ==10686==    by 0x4E5F137: TclEvalObjvInternal (tclBasic.c:3699)
  ==10686==    by 0x4EA1EB1: TclExecuteByteCode (tclExecute.c:2416)
  ==10686==    by 0x4EA930F: TclCompEvalObj (tclExecute.c:1538)
  ==10686==  If you believe this happened as a result of a stack
  ==10686==  overflow in your program's main thread (unlikely but
  ==10686==  possible), you can try to increase the size of the
  ==10686==  main thread stack using the --main-stacksize= flag.
  ==10686==  The main thread stack size used in this run was 8388608.
  ==10686== 
  ==10686== HEAP SUMMARY:
  ==10686==     in use at exit: 2,977,557 bytes in 2,224 blocks
  ==10686==   total heap usage: 15,288 allocs, 13,064 frees, 6,539,778 bytes allocated
  ==10686== 
  ==10686== LEAK SUMMARY:
  ==10686==    definitely lost: 1,280 bytes in 2 blocks
  ==10686==    indirectly lost: 4,688 bytes in 146 blocks
  ==10686==      possibly lost: 2,138,713 bytes in 134 blocks
  ==10686==    still reachable: 832,876 bytes in 1,942 blocks
  ==10686==         suppressed: 0 bytes in 0 blocks
  ==10686== Rerun with --leak-check=full to see details of leaked memory
  ==10686== 
  ==10686== For counts of detected and suppressed errors, rerun with: -v
  ==10686== ERROR SUMMARY: 3327 errors from 26 contexts (suppressed: 46 from 10)
  Killed


tkt_uuid: 3348994fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 7 High
foundin: obsolete: 8.6b1.1
resolution: None
title: Freeze for Dialogs Created from Shortcut
comment:
  When creating a dialog box from a command key shortcut Tcl/Tk Aqua freezes up.
  This issue appears in the latest Active Tcl/Tk version for Mac; I think it also happens in the latest 8.5.9.2 build available.

  This is related to the bug "https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3285355&group_id=12997" (this bug appears when an error message has to be displayed, with very similar consequences: a freeze and a white rectangle on the screen where the dialog should be).

  I have cut down the example as much as possible. It works flawlessly on other platforms and on Mac using Active Tcl 8.4 and the older 8.5 builds.

  (Basically this issue means that currently there is *no* Active Tcl build for Mac that works with our application; almost every command-key shortcut causes Tcl/Tk to freeze.)


tkt_uuid: 3363577fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Invalid
title: Font in entry widget works at command line, fails in script
comment:
  The following script results in a MS sans Serif font being displayed -- however if I run the configure command on the widget in the console the font changes.  I cant attach the font but you can find it here: http://www2.i-love-epson.co.jp/download/printer/driver/win/page/ttf30.exe.  The font is epgyobld.ttf.  I realize the font maybe non standard (i\'m not sure how to tell) since it doesn't a have a name according to the windows font reader application, but I got the font name via the \"font families\" command, so assume tk knows how to find it.  If you know a font I can use that will display a very brushy japanese script, I am happy to change, or to upgrade tk if this is already fixed.    

  catch {console show} 
  # script 

  global currentKanji 

  set character [entry .entry -text \\u6F22\\u5B57 -font {{EPSON 太行書体Ｂ} 125} -relief flat -textvariable currentKanji]
  set currentKanji \\u6F22\\u5B57

  pack $character 

  # Run this at the command line. 
  $character configure -font {{EPSON 太行書体Ｂ} 125}   


tkt_uuid: 3371384fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: Crash with Ttk on Win7-64bit
comment:
  Hello,

  I have just installed the latest 8.5.10 -Win64bit- Tcl distribution from Active State on a new Win7-64bit PC and I am experimenting crashes with the GUI (Tk/Ttk) of an application running without pb on WinXP.

  Narrowing the source of the crash on Win7 seems to point to Ttk being involved.

  I attach a small script wich reproduce the crash on my machine : execute it, then click on the button -> crash (I need to wait 2-3 seconds to see the crash icon in the Win7 task bar...)

  Thanks

  Jean-Marie


tkt_uuid: 3381288fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: winWm-9.2 bg error during test
comment:
  When testing an RC for Tk 8.6b2 on a Centos
  Linux system on x86_64, I get an "Application Error"
  popup window with the message:

  Error: bad window path name ".t.f.x"

  bad window path name ".t.f.x"
  bad window path name ".t.f.x"
      while executing
  "winfo rooty .t.f.x"
      ("after" script)

  Examining the test suite, this is
  apparently coming from test winWm-9.2.


tkt_uuid: 3382423fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: wm forget / manage crash and zombie windows
comment:
  I stumbled across an issue with wm forget/wm manage on Aqua. One of the symptoms also appears on Windows. 
  Issue 1:
  "wm forget" doesn't work correctly, when the toplevel has never been mapped so far:
  package require Tk
  toplevel .t
  # update
  wm forget .t

  WIthout the update, on Windows I get a "zombie" frame .t - it is possible to pack anythng inside, but it never updates. If it is undocked using wm manage, the toplevel doesn't repaint. WIth an "update" in between, it works on Windows. Only on X11, it works correctly. On Aqua, it crashes in Tk_WmDeadWindow. 

  Issue 2: On Aqua, repeatedly docking/undocking a frame irregularly crashes in Tk_WmDeadWIndow at "wm forget". Code:
  package require Tk
  toplevel .dock
  pack [ttk::label .dock.text -text "This is a toplevel\nwhich can be docked"]
  pack [ttk::button .dock.d -text "(un)dock" -command dock]
  pack [ttk::label .p -text "Place your \nwindow here"] -side left

  set docked false
  proc dock {} {
    if {$::docked} {
      pack forget .dock
      wm manage .dock
      set ::docked false
    } else {
      wm forget .dock
      pack .dock -side left
      set ::docked true
    }
  }

  Tracking this issue with valgrind, I noticed an error message already when a toplevel is created and then mapped to the screen:
  Valgrind says, after toplevel .t triggers the mapping:

  ==29387==  Address 0x11a246818 is 40 bytes inside a block of size 480 alloc'd
     ==29387==    at 0x10001150E: calloc (vg_replace_malloc.c:467)
     ==29387==    by 0x1039DAD1F: CGSNewWindowWithOpaqueShape (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.   framework/Versions/A/CoreGraphics)
     ==29387==    by 0x1016BAF03: _NSCreateWindowWithOpaqueShape2 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x10164F690: -[NSWindow _commonAwake] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x10166D1C8: -[NSWindow _makeKeyRegardlessOfVisibility] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x10166D13D: -[NSWindow makeKeyAndOrderFront:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x1010C975E: XMapWindow (tkMacOSXSubwindows.c:153)
     ==29387==    by 0x10103238E: Tk_MapWindow (tkWindow.c:1658)
     ==29387==    by 0x10103B239: MapFrame (tkFrame.c:1782)
     ==29387==    by 0x1000CFC02: TclServiceIdle (in /Users/chris/Programmieren/lib/libtcl8.6.dylib)
     ==29387==    by 0x1000B340A: Tcl_DoOneEvent (in /Users/chris/Programmieren/lib/libtcl8.6.dylib)
     ==29387==    by 0x1010176CB: Tk_MainLoop (tkEvent.c:2131)
     ==29387==


  It is strange that Tk_MapWindow calls XMapWindow instead of TkWmMapWindow, because there is the following code:


     if (winPtr->flags & TK_WIN_MANAGED) {
             /*
              * Lots of special processing has to be done for top-level windows.
              * Let tkWm.c handle everything itself.
              */

             TkWmMapWindow(winPtr);
             return;
         }


  Can it be, that toplevel does not set TK_WIN_MANAGED correctly?


tkt_uuid: 3382424fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: OS X error/warning from `make test`
comment:
  Running `make test` on Tk 8.6b2 on Snow Leopard,
  I see this message go by:

  2011-07-29 15:47:57.150 tktest[29686:903] tkMacOSXInit.c:255: TkpInit(): Tcl_MacOSXOpenVersionedBundleResources failed


tkt_uuid: 3391905fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: New themed range widget
comment:
  A TTK widget based on scale that contains two sliders defining a range between two numbers.

  Attached patch is a diff from trunk today.

  Can't find any details on pushing a branch for review or the like...


tkt_uuid: 3393315fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Invalid
title: Aqua Tk mishandles menus with Dvorak Qwerty Cmd input method
comment:
  See discussion here http://comments.gmane.org/gmane.comp.lang.tcl.mac/6977 and here http://bugs.python.org/issue12748

  When the OS X Dvorak - Qwerty Cmd Input Method is enabled (tested on OS X 10.6.8), Aqua Tk does not properly handle menu keyboard accelerators.  It appears that the Cocoa Tk backport for 8.5.10 incorrectly accepts either the Dvorak or Qwerty key equivalent for a menu accelerator rather than just the Qwerty one.  This is particularly bad for the common Edit -> Cut menu shortcut (Cmd-X) since Dvorak X is Qwerty Q and causes the app to terminate immediately.


tkt_uuid: 3394337fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: ttk::notebook slider not correct
comment:
  In ttk::notebook the last slider wasn't correctly displayed. In 8.5.9 it runs perfect. 

  The behavior can be seen at:
  8.5.9  http://www.ets.uni-due.de/~honerla/tcl/8.5.png
  8.6.b2 http://www.ets.uni-due.de/~honerla/tcl/8.6.png

  System Linux/Xorg x86_64
  Tcl/Tk 8.6.b2  build from source code
  Tcl/Tk 8.5.9 from distribution DVD (Opensuse 11.4)


tkt_uuid: 3403387fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Canvas Text Clipping
comment:
  I have a specific rectangle that I want text to appear in, with any excess text being clipped ("overflow: hidden" in CSS/HTML terms); I'm told that I can either not limit width, and the text overflows left and right, or I can limit width, and the text overflows top and bottom.

  A screenshot of the problem that I'm trying to solve is attached.

  It would be really nice if I could limit the width *and* the height -- if the height limit was "number of lines of wrapped text" rather than pixels then that would be easy to use and probably easier to implement (I would imagine incrementing a counter with each line wrap, then breaking out of the loop when the number of lines reaches the limit)

  If the bounding box could be specified in a way that scales when canvas.scale() gets called, that would be even better.

  For the moment I'm manually storing a second copy of all the bits of text on screen, then manually calculating the width and truncating the text on every rescale -- but this seems like I'm duplicating a lot work that Tk has already done (it is already storing a copy of the full text, calculating the width, and then truncating in order to wrap the text -- all I want on top of that is for it to stop rendering after one line)


tkt_uuid: 3404541fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: Config option repeats
comment:
  In ttk::button and ttk::notebook -takefocus appears twice in the configuration options:

  % ttk::notebook .nb
  .nb
  % .nb configure
  {-takefocus takeFocus TakeFocus ttk::takefocus ttk::takefocus} {-width width Width 0 0} {-height height Height 0 0} {-padding padding Padding {} {}} {-takefocus takeFocus TakeFocus {} ttk::takefocus} {-cursor cursor Cursor {} {}} {-style style Style {} {}} {-class {} {} {} {}}

  % ttk::button .b
  .b
  % .b configure
  {-takefocus takeFocus TakeFocus ttk::takefocus ttk::takefocus} {-command command Command {} {}} {-default default Default normal normal} {-text text Text {} {}} {-textvariable textVariable Variable {} {}} {-underline underline Underline -1 -1} {-width width Width {} {}} {-image image Image {} {}} {-compound compound Compound none none} {-padding padding Pad {} {}} {-state state State normal normal} {-takefocus takeFocus TakeFocus {} ttk::takefocus} {-cursor cursor Cursor {} {}} {-style style Style {} {}} {-class {} {} {} {}}

  % info patch
  8.6b1.2


tkt_uuid: 3404622fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: None
resolution: None
title: bordercolor - option for entry
comment:
  A "-relief solid" - entry has always a black border.
  I would like to have a command-line-option / option-database-option to configure the color.


tkt_uuid: 3405839fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.6b2
resolution: Fixed
title: Writing PNG images sometimes generates wrong sBIT chunk
comment:
  When writing PNG images, the sBIT chunk is always written with a length of 4. This should actually vary depending on the color type.

  Script to reproduce the problem:
  image create photo foo -width 20 -height 20
  foo write foo.png -format png

  This writes a PNG file with color type 4, which should have an sBIT chunk of 2 bytes.


tkt_uuid: 3406785fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: Incorrect coords rounding --- pixel jump in drawing items
comment:
  Look at result of this script:
  -----
  canvas .c -bg white
  grid .c
  set x1 20
  set x2 22
  set y2 105
  for {set f 0} {$f<50} {incr f} {
      set y1 [expr {$y2-0.05*$f}]
      .c create rectangle $x1 $y1 $x2 $y2 -fill black
      incr x1 2
      incr x2 2
      }
  -----

  On Windows XP I see that at left side of figure bottom margin is one pixel lower than at right side. But it shouldn't happen as y2 is the same
  (105) for all rectangles. Also, DKF confirmed the bug on OSX, and with both 8.5 and 8.6. 


tkt_uuid: 3410536fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: None
title: -install_name badly set because of LIB_RUNTIME_DIR badly set
comment:
  As this bug is really similar to bug ID: 2965133, I copy most of it here.

  I try to build Tk 8.6 X11 version on Mac OSX 10.5.8
  I build it with the current Tk HEAD (just cd tk/unix; configure --prefix=/usr/local/TclTk8.6 ; make ; make install, and it compiles without complaining. But launching wish8.6 gives : 

  dyld: Library not loaded: /usr/local/TclTk8.6/lib:/usr/X11/lib

  As far as I can tell, the problem is that LIB_RUNTIME_DIR is being set up as a colon-separated list of directories, which is then copied to DYLIB_INSTALL_DIR, which in turn is treated as just one directory. Makefile.in sets it up thus:

  DYLIB_INSTALL_DIR = ${LIB_RUNTIME_DIR}

  and this variable is only used in configure.in, thus:

  TK_SHLIB_LD_EXTRAS="${TK_SHLIB_LD_EXTRAS}"' -install_name "${DYLIB_INSTALL_DIR}"/${TK_LIB_FILE}'

  FWIW, manually editing the build/tk/*/Makefile to remove the second components from the definition of LIB_RUNTIME_DIR made wish running again.


tkt_uuid: 3410609fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: Keys with AltGr (ISO_Level3_Shift) on Swiss layout => ??
comment:
  Execute:
  setxkbmap ch # or any other method to switch your layout to Swiss
  wish
  % bind . <KeyPress> {puts %K}

  Hit AltGr (likely the key right next to your spacebar, not really sure) + ' = } (or {)

  Output:
  ISO_Level3_Shift
  ?? # should be braceright


tkt_uuid: 3411525fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Out of Date
title: entry validatecommand and namespace code error
comment:
  We noticed that substitution of %P for an entry's validate command can create a command with an unmatched brace, which throws a tk error box onto the screen when the validate command is created with the "namespace code" method. The test script was executed with wish. The root cause appears to be how Tcl_ScanCountedElement does not return the correct flags for combinations of baskslash and braces. I believe that a command to validate a string should be able to execute without error on any string.


tkt_uuid: 3414673fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: Improper look of ttk::checkbutton -style Toolbutton
comment:
  Currently it has improperly arranged borders: it doesn't look by now as "pressed", but rather still like raised - with the difference, that the light comes from "bottom right". IMHO the white "border" (bottom and right) should be removed completely, then it would look as "pressed" (checked on Linux, Tk8.6b2, all themes). Making bottom and right sides "lit" is wrong; either they should be as gray, as the background (or in any other bg colour), or they should be 1-pixel thick black line. How does it look presently: http://postimage.org/image/c68zo0xw/ (Upper: "untouched" (sets the associated variable to 0), the lower one: "depressed" - which, in fact, doesn't look as "pushed in". The "default" style - but the same problem is using all the other styles).


tkt_uuid: 3414693fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: None
title: tk_dialog: (mis)placement
comment:
  tk_dialog is centered in relation to "physical" screen - and, unfortunately, not to "root window", like e.g. tk_messageBox is.


tkt_uuid: 3414695fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: None
title: Error when "parent" destroyed first
comment:
  I think, there is a need for a fix in tk_chooseDirectory, tk_getOpenFile, tk_getSaveFile. Consider the situation, when toplevel dialog has been brought, and there is an entry for file (or directory) name, and associated button, which allows selection using mouse, instead of typing. Below is much simplified example, which will show the problem:

  #v+
    package require Tk
    toplevel .foo
    pack [button .foo.button -command [list tk_getOpenFile -parent .foo] \
         -text "Pick file"]
  #v-

  Now, if you click "Pick file" to select the wanted file with mouse, then you'll change your mind, and decide to abort the whole operation just by closing .foo (and _not_ by closing selection window first, then .foo), an error will be raised:

  #v+
  bad window path name ".foo.__tk_filedialog"
  bad window path name ".foo.__tk_filedialog"
      while executing
  "wm withdraw $grab"
      (procedure "::tk::RestoreFocusGrab" line 13)
      invoked from within
  "::tk::RestoreFocusGrab $w $data(ent) withdraw"
      (procedure "::tk::dialog::file::" line 122)
      invoked from within
  "::tk::dialog::file:: open -parent .foo"
      invoked from within
  ".foo.button invoke"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list $w invoke]"
      (procedure "tk::ButtonUp" line 22)
      invoked from within
  "tk::ButtonUp .foo.button"
      (command bound to event)
  #v-

  Of course, I made this "not quite elegant" way, not closing selection window first - but pay attention, that only in this example the parent toplevel was smaller than its child; in real applications usually it'll be much larger, and we can expect such action from the side of the (lazy) user. IMHO there should be such (mis)use foreseen and silently handled.

  Tested on Linux using TCL/Tk 8.6b2.


tkt_uuid: 3416492fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Crash in open/save file dialog in Windows 7 libraries
comment:
  Open (and presumably Save) file dialogs crash in Windows 7 when attempting to open a file located in a Library (e.g. Documents, Pictures, Videos, Music). Opening the same file through its actual path works fine (i.e., clicking on Libraries, then Documents, then whatever.txt, then Open will crash; actually clicking through the folders C:\Users\bob\Documents, clicking whatever.txt, and clicking Open will work fine). I haven't actually run the code through a debugger to verify 100%, but I believe this is a bug in OFNHookProcA/W in tkWinDialog.c. Since Libraries are collections of folders, they're not represented by one single path, so calling SendMessage() with CDM_GETFOLDERPATH fails (returns < 0) when the user navigates to a Library in the dialog; this would cause the buffer size in OFNHookProc to be calculated incorrectly, which is what I believe is causing the crash.

  I noticed this bug when trying to use tkinter.filedialog.askopenfilename() in Python 3.2.2 (Python 3.2 actually uses Tk 8.5.9, but the problematic SendMessage() code appears to be unchanged in 8.5.10, so I've filed this under the current version). I've attached a zip file containing a Python script to replicate the bug and C++ code to demonstrate how CDM_GETFOLDERPATH fails inside Libraries. Note that the dialog won't crash if you go into a folder inside a Library, as once you're inside that folder, there's a real, logical path for CDM_GETFOLDERPATH to return; it only fails if you select a file immediately inside the Library itself.


tkt_uuid: 3421183fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Last filetype sometimes selected as default on Windows
comment:
  I'm using Tcl/Tk on Linux, Windows and Mac OS, and the file type that is selected by default changes depending on the platform. On Linux, the first file type is selected, while the last one is on the other platforms. I think the behavior on Linux is wrong, since examples of code I could find on the Web all use the last type for most generic filters. Anyway, the behavior should be consistent across platforms.

  I'm using Tk 8.5.9 on Fedora 15.

  Steps to reproduce:
  $ wish
  % tk_getOpenFile -filetypes "{First {*.a}} {Last {*.b}}" 


tkt_uuid: 3421715fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: ttk::sizegrip too small on Win7
comment:
  Probably related to previous issues with sawn-off menubutton indicators and perhaps scrollbar widths being too narrow. 
  The sizegrip is so small its barely visible on Win7. Thanks!


tkt_uuid: 3425285fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: ttk::scale "-variable" core dump
comment:
  If I use "ttk::scale -variable VAR" with wish 8.5.10, i have core dumps when the toplevel is destroyed and then created again in *some* manners.

  Sorry for not providing a succinct test case, but it was hard tracking this down.
  To see this bug:

  svn co https://scidvspc.svn.sourceforge.net/svnroot/scidvspc -r 851
  cd scidvspc
  configure TCL_VERSION="8.5"
  make install
  scid

  Press <Control-l> (lowercase L) three times, leaving the gamelist open.
  (If it hasn't already crashed) Try to move Y scrollbar (actually a ttk::scale).
  Program crashes with a gdb backtrace to ScaleVariableChanged.
  Note, removing "-variable glstart" from the ttk::scale declaration (source file: tcl/windows/gamelist.tcl)
  averts program crash.

  Revision 852 has a workaround for 8.5.10 which uses tk::scale instead.
  I have not seen this bug before 8.5.10.
  A friend tells me that early version of 8.6 also had buggy ttk::scale, but 8.6b2 seems fine in my testing.

  Cheers.


tkt_uuid: 3426824fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: fonts ignore tk scaling
comment:
  Fonts appear to ignore the value of tk scaling:

  Code:

  puts "tk_patchLevel = $tk_patchLevel"
  tk scaling 1
  font create f -family helvetica -size 12
  label .l -text "Hello World" -font f
  update idletasks
  puts "tk scaling = [tk scaling]"
  puts "linespace (1) = [font metrics f -linespace]"
  puts "winfo reqheight .l = [winfo reqheight .l]"
  tk scaling 2
  update idletasks
  puts "tk scaling = [tk scaling]"
  puts "linespace (2) = [font metrics f -linespace]"
  puts "winfo reqheight .l = [winfo reqheight .l]"
  font configure f -size 12
  update idletasks
  puts "linespace (3) = [font metrics f -linespace]"
  puts "winfo reqheight .l = [winfo reqheight .l]"
  exit 0

  Output with 8.5.10/8.6b2:

  tk_patchLevel = 8.6b2
  tk scaling = 1.00028129395218
  linespace (1) = 18
  winfo reqheight .l = 22
  tk scaling = 2.00056258790436
  linespace (2) = 18
  winfo reqheight .l = 22
  linespace (3) = 18
  winfo reqheight .l = 22

  Output with 8.4.19:


  tk_patchLevel = 8.4.19
  tk scaling = 1.00028129395
  linespace (1) = 12
  winfo reqheight .l = 18
  tk scaling = 2.0005625879
  linespace (2) = 12
  winfo reqheight .l = 18
  linespace (3) = 27
  winfo reqheight .l = 33

  Tested on Linux (Ubuntu 11.10)  with 8.5.10 and 8.6b2. Works as expected with 8.4.19 on Linux and with 8.6b2 on Windows XP. Not tested on Mac.

  See also: http://wiki.tcl.tk/8488


tkt_uuid: 3427984fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Cocoa support for TIP 382
comment:
  Cocoa doesn't seem to offer a simple flag
  interface to support the -confirmoverwrite
  option to [tk_getSaveFile], but a possible
  implementation approach is outlined here:

  http://stackoverflow.com/questions/1930352/nssavepanel-squelching-the-confirm-replace-dialog/2390780#2390780

  Leaving the RFE here for someone interested to
  react to.


tkt_uuid: 3431491fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 27. Objects
priority: 7 High
foundin: obsolete: 8.5.10
resolution: Fixed
title: canvas create line slow for pure lists of double coordinates
comment:
  In our application, we noticed that "canvas create line" takes a considerable amount of time when the list of coordinates is not pre-shimmered before it enters the canvas. It looks like the list itself does not gain a string representation, but every double inside does gain a string representation and a type conversion to "pixel". A list of doubles with string representations appears to go around 25x faster than a list of pure doubles, at least with our particular systems and usage of the canvas. After some examination of Tk, I believe the string conversion happens in the conversion to the pixel type. I only tested this on 8.5.9.


tkt_uuid: 3437816fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.6b2
resolution: Fixed
title: canvas lower tagOrId ?belowThis?
comment:
  Example:
  pack [canvas .c]
  if { [catch {.c raise A B} err] } {
     puts "TCL_ERROR >>$err<<"
  } else { 
     puts "TCL_OK >>$err<<" 
  }
  RESULT: a TCL_ERROR occurs  an this is ok. see:
  TCL_ERROR >>tagOrId "B" doesn't match any items<<

  the same with the lower command:
   
  if { [catch {.c lower A B} err] } {
     puts "TCL_ERROR >>$err<<"
  } else {
      puts "TCL_OK >>$err<<" 
  }
  RESULT: TCL_OK occurs instead of an TCL_ERROR !!! see:
  TCL_OK >>tag "B" doesn't match any items<<

  the lower command should also return an TCL_ERROR when tag "B" doesn't match any item.
  Or is the behavior well known?

  Thanks
  Hirner U.


tkt_uuid: 3439581fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: ttk::style element image auto-adjusts width
comment:
  The ttk element image should recalculate it's width each time the image changes.

  ************
      set inull [image create bitmap]
      set ierror [image create photo -file ".../14x14/error.png"]
      set iwarning [image create photo -file ".../14x14/warning.png"]

      toplevel .tt
      ttk::entry .tt.e1
      pack .tt.e1 -fill x -expand yes

      ttk::style element create Warning image [list $iwarning user1
  $inull]
      ttk::style element create Error image [list $ierror user2 $inull]

      ttk::style layout TEntry {Entry.field -sticky nswe -children
  {Entry.padding -sticky nswe -children {Error -side right -sticky w
  Warning -side right -sticky e Entry.textarea}}}

      .tt.e1 state user2 
  ***************

  Details see here: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/f397b04c019aed9e/9dd04232b096556b?hl=en#9dd04232b096556b

  thx


tkt_uuid: 3439777fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Allow custom ttk states
comment:
  Currently the widgets states are limited to "focus", "disabled", "pressed", "readonly" ... and some free states "user1", "user2" and "user3" (see ttkState.c const stateNames);
  In order to build custom widgets I propose extending the state list during runtime operation, such that states like "warning" and "error" could be defined.

  This feature request is raised because of the following:
  http://sourceforge.net/tracker/?func=detail&aid=3439581&group_id=12997&atid=362997
  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/f397b04c019aed9e?hl=en

  thx


tkt_uuid: 3441086fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: ttk::style layout with empty -children silently disappears
comment:
  Environment Window XP, MinSys compiled TclTk 8.5.11, Theme winnative;

  proc childerr {} {
      toplevel .t
      ttk::style layout Test.Tentry {Entry.field -sticky nswe -border 0 -children {Entry.padding -sticky nswe -children {Entry.textarea -sticky nswe}}}
      ttk::entry .t.e -style Test.TEntry
      pack .t.e -fill x -expand yes
      puts a
      ttk::style layout Test.Tentry {Entry.field -sticky nswe -border 0 -children {Entry.padding -sticky nswe -children {}}}
      puts b
  }

  The procedure gets executed without error but "b" is not printed and the widgets appearance does not update. At least it looks like the interpreter stays healthy as there are no symptoms of high cpu load etc....
  The more major problem is that the code after the ttk:style never gets executed.

  thx


tkt_uuid: 3460403fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 3 Low
foundin: obsolete: 8.5.8
resolution: Invalid
title: Ttk async proc resets result of a command in main script
comment:
  I found that in the middle of execution the result of [info library] was empty.  To localize the problem, I called info library many times and at some call the result was empty, then back to normal.  After setting a watch point on object result, I found that Ttk's procedure ThemeChangedProc called Tcl_GlobalEval without preserving Tcl result.  Here's an example of stack where the result of [info library] is nullified:

    [1] libtcl.so:ResetObjResult(iPtr = 0x85b03b8), line 968 in "tclResult.c"
    [2] libtcl.so:Tcl_ResetResult(interp = (nil)), line 896 in "tclResult.c"
    [3] libtcl.so:TclEvalEx(interp = 0x85b03b8, script = 0xf697895c "ttk::ThemeChanged", numBytes = 17, flags = 0, line = 1), line 4089 in "tclBasic.c"
    [4] libtcl.so:Tcl_EvalEx(interp = 0x85b03b8, script = 0xf697895c "ttk::ThemeChanged", numBytes = -1, flags = 0), line 4043 in "tclBasic.c"
    [5] libtcl.so:Tcl_Eval(interp = 0x85b03b8, script = 0xf697895c "ttk::ThemeChanged"), line 4823 in "tclBasic.c"
    [6] libtcl.so:Tcl_GlobalEval(interp = 0x85b03b8, command = 0xf697895c "ttk::ThemeChanged"), line 5836 in "tclBasic.c"
    [7] libtk.so:ThemeChangedProc(clientData = 0x860e818), line 519 in "ttkTheme.c"
    [8] libtcl.so:TclServiceIdle(), line 738 in "tclTimer.c"
    [9] libtcl.so:Tcl_DoOneEvent(flags = 34), line 991 in "tclNotify.c"
    [10] libtk.so:MapFrame(clientData = 0x85d2c80), line 1751 in "tkFrame.c"
    [11] libtcl.so:TclServiceIdle(), line 738 in "tclTimer.c"
    [12] libtcl.so:Tcl_DoOneEvent(flags = -1), line 991 in "tclNotify.c"
    [13] libeclutil.so:EventHandlerProc( = (nil), interp = 0x85b03b8, code = 0), line 367 in "gnm.C"
    [14] libtcl.so:Tcl_AsyncInvoke(interp = 0x85b03b8, code = 0), line 240 in "tclAsync.c"
    [15] libtcl.so:TclEvalObjvInternal(interp = 0x85b03b8, objc = 1, objv = 0x86723e0, command = (nil), length = 0, flags = 524288), line 3697 in "tclBasic.c"
    [16] libtcl.so:Tcl_EvalObjv(interp = 0x85b03b8, objc = 1, objv = 0x86723e0, flags = 524288), line 3886 in "tclBasic.c"
    [17] libtcl.so:NsEnsembleImplementationCmd(clientData = 0x85bf0e0, interp = 0x85b03b8, objc = 2, objv = 0x86722d8), line 6233 in "tclNamesp.c"
    [18] libtcl.so:TclEvalObjvInternal(interp = 0x85b03b8, objc = 2, objv = 0x86722d8, command = 0x8088722 "info library] / $tcl_library"", length = 12, flags = 0), line 3690 in "tclBasic.c"
    [19] libtcl.so:TclEvalEx(interp = 0x85b03b8, script = 0x8088722 "info library] / $tcl_library"", numBytes = 12, flags = 0, line = 1), line 4338 in "tclBasic.c"
    [20] libtcl.so:TclSubstTokens(interp = 0x85b03b8, tokenPtr = 0x8671ee8, count = 4, tokensLeftPtr = (nil), line = 1), line 2254 in "tclParse.c"
    [21] libtcl.so:TclEvalEx(interp = 0x85b03b8, script = 0x8088714 "puts "lib4 = [info library] / $tcl_library"", numBytes = 43, flags = 0, line = 1), line 4232 in "tclBasic.c"
    [22] libtcl.so:Tcl_EvalEx(interp = 0x85b03b8, script = 0x8088714 "puts "lib4 = [info library] / $tcl_library"", numBytes = -1, flags = 0), line 4043 in "tclBasic.c"
    [23] libtcl.so:Tcl_Eval(interp = 0x85b03b8, script = 0x8088714 "puts "lib4 = [info library] / $tcl_library""), line 4823 in "tclBasic.c"

  I checked the latest Tk sources, 8.6b2, and the code of the function is the same.
  After I added Tcl_SaveResult and Tcl_RestoreResult to the function, the problem is gone.
  This change fixes the problem for me:

     % cleartool diff -diff -pre ttkTheme.c
     518c518,519
     <
     ---
     >     Tcl_SavedResult state;
     >     Tcl_SaveResult (pkgPtr->interp, &state);
     521a523
     >     Tcl_RestoreResult (pkgPtr->interp, &state);

  You may want to preserve the whole state, not only result.
  Good luck!


tkt_uuid: 3460976fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Fix for menus stopping working
comment:
  This is a patch to fix priority 9 bug #3235256.

  For long-running applications which over time create &
  destroy many windows with menubars, eventually the menus
  stop working, leaving the application in an unusable state.

  The problem was that menu item ids were being created
  which conflicted with the predefined identifiers used by the
  window system menu & the WM_SYSCOMMAND message.  The
  MSDN pages on WM_SYSCOMMAND & GetSystemMenu() have
  some info.

  The patch is for the released 8.5.11 version of tkWinMenu.c


tkt_uuid: 3462273fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: Changing image data in ttk does not work
comment:
  Using [$img configure -data $newdata] to change an image already used in a ttk label doesn't change the displayed image.

  The following code show the issue:

  package require Tk
  set icon1 {R0lGODlhEAAQAJEAANnZ2QAAAISEAP///yH5BAEAAAAALAAAAAAQABAAAAJ
      WhI9pFB8RIIRC+BYQFqQQvkWEBSmEbyFhQQrhW0hYkEL4FhIWpBC+hYQFSYxvIgF
      AoXy0AAiSGP8kAIIkxgcICSBEQvEBQgIIkVB8gJAAAhgfj+BjWgEAOw==}
  set icon2 {R0lGODlhEAAQAKIAANnZ2QAAAP///4SEhP//AP///////////yH5BAEAAAA
      ALAAAAAAQABAAAANZCLrcjqG7CLqBoquBoBuCoSqBoBsouhoIuiEYqrKBoIGiqwE
      YEIChyxAIEYGgywEYgKHLDAgRCLozgwABARgIukSEABEBGLq8gAEQCLobgAEAgKH
      LgaDLzZgAOw==}
  set im [image create photo -data $icon1]
  pack [label .l1 -image $im -text Tk -compound left] -padx 100 -pady 50
  pack [ttk::label .l2 -image $im -text ttk -compound left] -padx 100 -pady 50
  set current 1
  proc swapimage {} {
      global current im icon1 icon2
      if {$current == 1} {
         $im configure -data $icon2
         set current 2
      } else {
         $im configure -data $icon1
         set current 1
      }
      after 1000 swapimage
  }
  after 1000 swapimage


tkt_uuid: 3462883fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: tearoff iconifys on loss of focus
comment:
  When a popup menu is torn off, the resultant menu is iconified if the parent loses focus.  This is a problem particularly if the tearoff is moved outside of the parent window, in which case it is very hard to get focus back to the menu.  A simple case:
  menu .foo -tearoff 1
  .foo add command -label "foov"
  bind . <3> "tk_popup .foo %X %Y

  The right click in the window and do the tear off.  When the mouse leaves the main window the tearoff will iconify.

  By the way, this does not happen on Windows systems.


tkt_uuid: 3464070fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: MenuNewEntry() return NULL -> no error msg
comment:
  Noticed when reviewing 3235356, 3460976.

  In the rare case when a new menu entry cannot
  be created, the TCL_ERROR returned by various
  menu commands is not accompanied by any error
  message, code, etc.


tkt_uuid: 3466588fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: panedwindow resize problem with text -setgrid 1
comment:
  A panedwindow contains two frames, of which one is a text widget created with "-setgrid 1". When the top-level window is resized by more than about 20 pixel at a time, dragging the sash of the panedwindow also resizes the top-level window. Seen on Windows XP SP3 with Tcl/Tk 8.5.9 and 8.5.11. Omit the option "-setgrid 1" from the text widget command, and the problem is gone. That's ok for me. But I would like to have the problem documented, at least. The problem seems related to ID 1161543, where listboxes were used instead of a text.


tkt_uuid: 3476090fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: None
resolution: None
title: -help does not work in tk 8.5.11 on MacOs
comment:
  When one uses the "-help" option win tk 8.5.11 on MacOs, the program crashes with a Segmentation Fault  11 

  On Linux with Tcl 8.4 it works fine.

  An example is included:

  On Mac, tk 8.5.11:

  $.> ./a.out -help
  Segmentation fault: 11


  On Linux, tk 8.4:

  $.> ./a.out -help
  Command-specific options:
   -myoption1: Explain myoption1
   -myint2:    Explain myint2
  Generic options for all commands:
   -help:      Print summary of command-line options and abort


tkt_uuid: 3485342fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: Add -confirmonwrite option to tk_get*File on nt
comment:
  We should, when possible, use the same interface to get saveasfilename, etc.
  On nt, the -confirmonwrite option is neither known or used (whereas on aix/linux, this option is supported).

  I added a small patch to this request, that allow to switch on/off the OFN_OVERWRITEPROMPT switch used in tkWinDialogs.c

  Regards,
  Eloi


tkt_uuid: 3487136fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Accepted
title: TkpMeasureCharsInContext bugs in Tk Cocoa
comment:
  For Chinese and other text where a UTF character is more than one byte, TkpMeasureCharsInContext returns "1" when called by the text widget to determine tag-under-mouse whether mouse is in fact over first or second character.  (The attached script demonstates.)  Tracing revealed this was because CTTypesetterSuggestClusterBreak() refuses to return a zero, even if the cluster break goes past the max.  Added code to detect and correct this.  While debugging a couple of other apparent errors were found and fixed.

  Finally, some special code to ignore user-specified threshold and disable antialiasing for fixed-width fonts below 10-point was disabled.  If this is going to be present, it should be exposed through a ::tk::mac variable so the user or application can turn it off, since this behavior is nonstandard.


tkt_uuid: 3487138fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Let GetThemeColor() use screen-specific colorspace
comment:
  In GetThemeColor() there is code to use the colorspace of the main display when creating a color from RGBA, however it is commented out in favor of one that uses a generic RGB colorspace.  On a Macbook Pro the generic looks fine, but on a desktop with calibrated color monitors it results in significant distortion.  Allocating for X name "blue" for example would produce something purplish.  Switching to the code that uses main display cured this, and did not make things look any worse on the Macbook Pro.  This patch makes the change, though as it says a further improvement should be made to detect which display the color is being requested for.  I'm also a little fuzzy on how the system remaps colors when dragging a window onto another display (whether it results in a new request to GetThemeColor() or not).


tkt_uuid: 3495198fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Fixed
title: color/bitmap mixup in canvas bitmap man page
comment:
  The man page for canvas bitmap says:

  -activebackground bitmap
  -disabledbackground bitmap
  -activeforeground bitmap
  -disabledforeground bitmap

  In each of these cases, "bitmap" should be "color".


tkt_uuid: 3497848fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 27. Objects
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: GetPixelsFromObjEx error for doubleObjs
comment:
      % info patchlevel
      8.5.11
      % canvas .c
      .c
      % set x 573.8
      573.8
      % .c canvasx $x
      574.0
      % set x [expr $x+0.0]
      573.8
      % .c canvasx $x
      573.0

  Note how the first result 574 differs from the second 573.

  this is due to the code in tkObj.c which converts numbers to pixels
  and does a rounding in one case and none in the other:

  tk/generic/tkObj.c, static int GetPixelsFromObjEx(...), 

     #206ff
      if (objPtr->typePtr != &pixelObjType) {
  ThreadSpecificData *tsdPtr = GetTypeCache();

  if (objPtr->typePtr == tsdPtr->doubleTypePtr) {
      (void) Tcl_GetDoubleFromObj(interp, objPtr, &d);
      if (dblPtr != NULL) {
  *dblPtr = d;
      }
      *intPtr = (int) d;
      return TCL_OK;
              
  Note this simply casts the double to int, no rounding.

  However, in the same routine, if the obj is not double or int:

      if (objPtr->typePtr != &pixelObjType) {
  result = SetPixelFromAny(interp, objPtr);
       ...
       if ((pixelPtr->tkwin != tkwin)||dblPtr) {
      d = pixelPtr->value;
       --<snip-snip>--
      if (d < 0) {
  pixelPtr->returnValue = (int) (d - 0.5);
      } else {
  pixelPtr->returnValue = (int) (d + 0.5);
      }
      --<snip-snip>--
  }
  *intPtr = pixelPtr->returnValue;

  Note the rounding in this case.

  Proposed patch:

  This seems to be related to
      2011-11-01  Donal K. Fellows  <dkf@users.sf.net>
              * generic/tkObj.c (GetPixelsFromObjEx): [Bug 3431491]: Use a bit of
              type hackery to allow numbers to be interpreted as coordinates (most
              notably on a canvas) without reinterpreting via a string.

  Proposed patch:

  --- tk/generic/tkObj.c2011/11/08 14:59:181.1
  +++ tk/generic/tkObj.c2012/03/06 18:15:36
  @@ -211,7 +211,11 @@
       if (dblPtr != NULL) {
   *dblPtr = d;
       }
  -    *intPtr = (int) d;
  +    if (d < 0) {
  +*intPtr = (int) (d - 0.5);
  +    } else {
  +*intPtr = (int) (d + 0.5);
  +    }
       return TCL_OK;
   } else if (objPtr->typePtr == tsdPtr->intTypePtr) {
       (void) Tcl_GetIntFromObj(interp, objPtr, intPtr);


tkt_uuid: 3500545fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.13
resolution: Fixed
title: tk_getOpenFile -multiple 1 wrong on windows
comment:
  on windows [tk_getOpenFile -multiple 1] returns wrong results, 
  when one or multiple file name, containing a path, are entered maunally.
  The resulting file names get the current path prepended, regardless
  wether they contain already a path or not.

  Since 8.5.9 the code in GetFileNameW() and  OFNHookProcW() do their own buffer/selection handling
  which is somehow buggy ;-(

  Here are the steps to reproduce the bug with tcl/tk 8.5.11 on windows:

  tk_getOpenFile -multiple 1 -initialdir c:/windows
  #(enter c:\autoexec.bat)
  -> C:/WINDOWS/c:/autoexec.bat


tkt_uuid: 3512539fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: None
title: .. is silently accepted in widget paths
comment:
  A child widget of the main application window can be created with a leading ".." in the pathname;  this is silently interpreted as "." and the widget creation command returns the fixed path.

  While I think this behavior is sensible - it simplifies a generic create a child window operation to "set widget_cmd [label $parent.name]" - the behavior is apparently undocumented.  The behavior should either be documented/supported so that it can be relied on, or eliminated so that it does not become entrenched when people accidentally discover it.


tkt_uuid: 3515522fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: Crash when adding system menu to undocked window
comment:
  I have recreated this in a fresh pull from fossil core-8-5-branch yesterday. On a windows build, undocking a window, adding a system menu, and then redocking the window will cause a crash when the menubar is destroyed.

  Here is a testcase:
  toplevel .w
  menu .m
  .w configure -menu .m
  menu .m.system
  .m.system add command -label "sys test"
  .m add cascade -label System -menu .m.system
  wm forget .w
  destroy .w

  Few more details:
  The equivalent in tcl8.4 (replacing wm forget .w w/ wm toplevel .w 0) works fine.
  The crash occurs in TkWinGetWrapperWindow when a null wmInfoPtr is dereferenced.
  I can avoid the crash by re-adding the call to TkFrameReleaseMenu in WmForgetCmd which didn't seem to make the move when WmToplevelCmd became WmForgetCmd, however i don't know if this is the proper solution.


tkt_uuid: 3517228fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: None
title: Endless loop inside Tk library
comment:
  I have the following case:
  1. Mapping a modal window (with local grab)
  2. Mapping a subwindow of the modal window
  3. Mouse click into the subwindow
  The result is a frozen screen. With debugging I discovered that an endless call of function TkPointerEvent() is freezing the screen. I made a patch to this function (see attached file; possibly a better patch is required) and my application is working. Unfortunately I couldn't build a simple test application with the same behavior.


tkt_uuid: 3517803fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: None
resolution: None
title: Modality not properly working
comment:
  I have the following case:

  .help is a help top level window
  .application.fileSelBox is a modal top level window (using local grab).

  Currently I cannot use the .help window if .application.fileSelBox is mapped, because .help is catching all mouse events. I think this is a bug, because if I look at the implementation of TkGrabState() - which is used in TkPointerEvent(), which handles the modality - something is weird:

  int
  TkGrabState(
      TkWindow *winPtr)           /* Window for which grab information is
                                                    * needed. */
  {
      TkWindow *grabWinPtr = winPtr->dispPtr->grabWinPtr;

      if (grabWinPtr == NULL) {
          return TK_GRAB_NONE;
      }
      if ((winPtr->mainPtr != grabWinPtr->mainPtr)
              && !(winPtr->dispPtr->grabFlags & GRAB_GLOBAL)) {
          return TK_GRAB_NONE;
      }

      return TkPositionInTree(winPtr, grabWinPtr);
  }

  The condition "winPtr->mainPtr != grabWinPtr->mainPtr" is always true, because winPtr->mainPtr is "." in every case. I think that this is a bug, and something like "SecondLastToplevel(winPtr) != SecondLastToplevel(grabWinPtr)" was intended. This means that the correct implementation should be:

  int
  TkGrabState(
      TkWindow *winPtr)           /* Window for which grab information is
                                                    * needed. */
  {
      TkWindow *grabWinPtr = winPtr->dispPtr->grabWinPtr;

      if (grabWinPtr == NULL) {
          return TK_GRAB_NONE;
      }
      if (!(winPtr->dispPtr->grabFlags & GRAB_GLOBAL) &&
              winPtr != grabWinPtr && /* this is an often case */
              (SecondLastToplevel(winPtr) != SecondLastToplevel(grabWinPtr))) {
          return TK_GRAB_NONE;
      }

      return TkPositionInTree(winPtr, grabWinPtr);
  }

  /* SecondLastToplevel() returns the toplevel window which is a descendant
   * of ".", or it returns the argument if such a second last toplevel is
   * not exisiting. */
  static TkWindow *
  SecondLastToplevel(
      TkWindow *winPtr)           /* Window for which second last
                                                    * toplevel is needed. */
  {
      TkWindow *prevTopLevelWinPtr = winPtr->mainPtr->winPtr;
      TkWindow *topLevelWinPtr = winPtr->mainPtr->winPtr;

      while (winPtr && !(winPtr->flags & TK_TOP_HIERARCHY)) {
          topLevelWinPtr = prevTopLevelWinPtr;
          prevTopLevelWinPtr = winPtr;
          winPtr = winPtr->parentPtr;
      }

      return topLevelWinPtr;
  }

  In my case SecondLastToplevel() will return .help and .application, respectively, which do not match.  Now the application will work as expected, I can use the .help window although the modal window .application.fsbox is mapped, but I cannot use the ancestor .application. The fixed implementation of TkGrabState() takes the tree hierarchy into account, the current implementation in the Tk library is ignoring the tree hierarchy.


tkt_uuid: 3519160fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Problem with horizontal scroll of treeview
comment:
  The horizontal scrollbar for a ttk::treeview does not work as expected (and as it does for a text widget). While initially the scrollbar appears fine and a corresponding fraction of the tree is displayed, this changes after the tree has been displayed once in its full width. Afterwards the scrollbar is and remains forever at 100%, no matter how small a tree width is chosen.
  The scroll command specified with the –xscrollcommand option is then always called with additional arguments 0.0 and 1.0.

  Problem occurs with Tcl/Tk 8.5.11 on Windows 7 and SuSE Linux.

  The following piece of code demonstrates the problem (If you replace ttk::treeview by text everything looks great):

  # purpose: test horizontal treeview scrolling

  wm withdraw .
  toplevel .ft -takefocus 0
  wm geometry .ft =80x300+80+80 
  ttk::frame .ft.lf
  pack .ft.lf -expand yes -fill both
  ttk::scrollbar .ft.lf.hs -orient horiz -command ".ft.tf xview"
  ttk::scrollbar .ft.lf.vs -command ".ft.tf yview"
  ttk::treeview .ft.lf.tf -show tree -xscrollcommand "hscrollf .ft.lf" -yscrollcommand "vscrollf .ft.lf"
  grid .ft.lf.tf -row 0 -column 0 -sticky nsew
  grid .ft.lf.vs -row 0 -column 1 -sticky ns
  grid .ft.lf.hs -row 1 -column 0 -sticky we
  grid rowconfig .ft.lf 0 -weight 1
  grid columnconfig .ft.lf 0 -weight 1

  # populate tree   
  foreach node [list " Entry0 " " Entry111111111111 " " Entry22222222222222222222 " " Entry3333333333333333333333333 "] {
      .ft.lf.tf insert {} end -text $node
  }

  # Vertical scrolling
  proc vscrollf {mw first last} {
      if {[expr {$first > 0.0}] || [expr {$last < 1.0}]} {
          grid $mw.vs -row 0 -column 1 -sticky ns
          $mw.vs set $first $last
      } else {catch {after idle grid remove $mw.vs}}
  }

  # Horizontal scrolling
  proc hscrollf {mw first last} {
      puts "f=$first, l=$last"
      if {[expr {$first > 0.0}] || [expr {$last < 1.0}]} {
          grid $mw.hs -row 1 -column 0 -sticky we
          $mw.hs set $first $last
      } else {catch {after idle grid remove $mw.hs}}
  }


tkt_uuid: 3519896fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Invalid
title: configure font not working properly
comment:
  TLabelframe does not list 'label' as a child, but TLabelframe.label does return a list of elements including -font. ttk.Style().configure('TLabelframe.label', font='fontname') does not change the font used, but using 'TLabelframe.Label' instead does work (note uppercase 'L'). 

  For TButton which lists label as a child, TButton.label (or .Label) does not change the font, while TButton alone does.. TCheckbutton is the same.

  For TEntry, I could not find any value that worked to change the font.  I tried with and without .label/.Label, with .textarea/Textarea, and both in combination.

  I am testing on OSX and Windows using Python 2.7.2, and Tcl/Tk 8.5.11.


tkt_uuid: 3520202fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Cocoa Tk 8.5 generates invalid mouse_wheel invents
comment:
  See details and test case at Python issue http://bugs.python.org/issue10731

  It appears that, for Tcl_CreateCommand at least, mouse_wheel events are being returned with a bogus argument count value of 20, possibly the length of the valid first argument string.  This causes problems in Python 3.x when _tkinter.c attempts to translate the garbage arguments strings, expecting them to be valid Unicode UTF-8 strings.  


tkt_uuid: 3526668fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 28. Utility Functions
priority: 5 Medium
foundin: None
resolution: None
title: Need display boundry info
comment:
  I have an application (filerunner on Sourceforge) that pops up 'tooltips' or balloon help messages.  To do this it needs to know where the display boundries are.  This is especially true of multi head systems.  The code I have written to attempt to determine this is slow, must account for different windowing systems and seems to depend on hidden and unknown (at least to me) timings in the display system and is way too big.

  It seems to me that at some level Tk knows this information and could just put a documented name on it.

  To give an idea of what I needed to do, I have attached the code I wrote.  Just reading the comments should give you an idea of the problem.


tkt_uuid: 3529786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Invalid
title: deadlock between SetFocus and ReadFile
comment:
  My app is a Tcl/Tk front end to a spawned child process. The child is connected to the parent wish process via pipes for stdout and stderr. stdout is fconfigured as nonblocking. fileevents are created to monitor the stdout/err channels and trigger callbacks that read the output and put it in to a scrolling text widgets. The app has one main window and a separate toplevel for a terminal, where the stdout/err output is displayed. The terminal toplevel is transient for the main window and always in front.

  So the deadlock occurs when the child process is writing a lot of output down stdout. Everything works fine until I click on the terminal window or somehow cause the focus to shift to it. This triggers a WM_SETFOCUS and WM_ACTIVATE messages to be sent. I believe it is during the processing of these that the deadlock occurs. When the deadlock happens the main thread is nearly always stuck under a SetFocus call or DispatchMessage. The pipereader thread is  stuck under ReadFile. Both threads stacks end at a call to KeWaitForMultipleObjects, so I'm guessing they are waiting for locks from each other.

  I've attached the full stacks for the main thread in the SetFocus case and DispatchMessage case, and the stack for the pipereader thread.

  I've been trying to spot the cause of the deadlock for days now under the debugger. I can't see what could be shared between the two threads to cause the deadlock. I know I haven't attached enough to reproduce this, but my app is rather large and it would take a while to cut it down. At the moment I'm happy to try to locate and fix this deadlock myself, but i've really run out of places to look. Hopeing someone could point me at a few things that might be behind this.

  I've also reproduced this using a 8.3 build of Tcl/Tk so it looks like it may have been here for a while. 

  It is timing related because if I slow down the output from the child process then I can't trigger the deadlock.

  Thanks
  Mark


tkt_uuid: 3531084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Fixed
title: safe.test failures due to changed Tcl safe command set
comment:
  ==== safe-1.2 Safe Tk loading into an interpreter FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      lsort [interp hidden a]

  ---- Result was:
  bell cd clipboard encoding exec exit fconfigure glob grab load menu open pwd selection send socket source tcl:file:atime tcl:file:attributes tcl:file:copy tcl:file:delete tcl:file:dirname tcl:file:executable tcl:file:exists tcl:file:extension tcl:file:isdirectory tcl:file:isfile tcl:file:link tcl:file:lstat tcl:file:mkdir tcl:file:mtime tcl:file:nativename tcl:file:normalize tcl:file:owned tcl:file:readable tcl:file:readlink tcl:file:rename tcl:file:rootname tcl:file:size tcl:file:stat tcl:file:tail tcl:file:tempfile tcl:file:type tcl:file:volumes tcl:file:writable toplevel unload wm
  ---- Result should have been (exact matching):
  bell cd clipboard encoding exec exit fconfigure file glob grab load menu open pwd selection send socket source tcl:file:atime tcl:file:attributes tcl:file:copy tcl:file:delete tcl:file:dirname tcl:file:executable tcl:file:exists tcl:file:extension tcl:file:isdirectory tcl:file:isfile tcl:file:link tcl:file:lstat tcl:file:mkdir tcl:file:mtime tcl:file:nativename tcl:file:normalize tcl:file:owned tcl:file:readable tcl:file:readlink tcl:file:rename tcl:file:rootname tcl:file:size tcl:file:stat tcl:file:tail tcl:file:tempfile tcl:file:type tcl:file:volumes tcl:file:writable toplevel unload wm
  ==== safe-1.2 FAILED



  ==== safe-1.3 Safe Tk loading into an interpreter FAILED
  ==== Contents of test case:

      safe::interpCreate a
      safe::loadTk a
      lsort [interp aliases a]

  ---- Result was:
  ::tcl::file::atime ::tcl::file::attributes ::tcl::file::copy ::tcl::file::delete ::tcl::file::dirname ::tcl::file::executable ::tcl::file::exists ::tcl::file::extension ::tcl::file::isdirectory ::tcl::file::isfile ::tcl::file::link ::tcl::file::lstat ::tcl::file::mkdir ::tcl::file::mtime ::tcl::file::nativename ::tcl::file::normalize ::tcl::file::owned ::tcl::file::readable ::tcl::file::readlink ::tcl::file::rename ::tcl::file::rootname ::tcl::file::size ::tcl::file::stat ::tcl::file::tail ::tcl::file::tempfile ::tcl::file::type ::tcl::file::volumes ::tcl::file::writable ::tcl::info::nameofexecutable ::ttk::paned clock encoding exit glob load source
  ---- Result should have been (glob matching):
  *encoding*exit*file*load*source*
  ==== safe-1.3 FAILED


tkt_uuid: 3531085fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Invalid
title: safe-5.2 fails with an error
comment:
  ==== safe-5.2 multi-level Tk loading with clearance FAILED
  ==== Contents of test case:

      # No error shall occur in that test and no window shall remain at the end.
      set i [safe::interpCreate]
      set j [list $i x]
      set j [safe::interpCreate $j]
      safe::loadTk $j
      interp eval $j {
          button .b -text Ok -command {destroy .}
          pack .b
  #       tkwait window . ; # for interactive testing/debugging
      }

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: can't source init.tcl into slave interp0 x (script error)
      while executing
  "InterpInit $slave $access_path $staticsok $nestedok $deletehook"
      (procedure "InterpCreate" line 12)
      invoked from within
  "InterpCreate $slave $accessPath  [InterpStatics] [InterpNested] $deleteHook"
      (procedure "safe::interpCreate" line 3)
      invoked from within
  "safe::interpCreate $j"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== safe-5.2 FAILED


tkt_uuid: 3531366fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 6
foundin: obsolete: 8.5.11
resolution: None
title: Cursor blink cannot be switched off in ttk widgets
comment:
  The ttk text entry widgets (e.g., ttk::entry, ttk::combobox) do not support the -insertOffTime option so it is not possible to stop cursor blink.

  Using non-ttk widgets it is possible to stop cursor blink by putting *insertOffTime: 0 in the .Xdefaults file; but there doesn't appear to be any way to do this for the ttk widgets.

  The problem appears in file generic/ttk/ttkBlink.c which has a TODO on this topic.


tkt_uuid: 3531403fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: Wont Fix
title: ttk.Scrollbar in Notebook widget freezes
comment:
  I am working on an iMac running OS 10.7, TK 8.5.11. I built a simple app containing a Notebook widget, and with Listboxes and linked tkk.Scrollbars on each of three tabs. All of the Scrollbars work the first time I manipulate them, but once the Scrollbar on third tab (the last one created by the script) is manipulated, the others become unresponsive to mouse clicks (though the Scrollbars continue to move when the Listboxes are scrolled using the mouse/trackpad. I first found this issue working with Python 3.2.3 (using IDLE), but the same thing happens with Python 3.3. The problem was recreated by someone on the Python Bug Report list using the same system configuration. I asked someone to try this on a PC (Windows 7, Python 3.2.3, Tkinter 8.5), but the problem wasn't recreated.


  After playing around with this a bit more, I've found that if the Scrollbars on the different tabs are not aligned (that is, they don't occupy the same EW position in the frame) the effect disappears. I thought that might mean that the last Scrollbar "persists" when you go back to earlier tabs, but the position of the slider in a frozen Scrollbar isn't necessarily the same as the position the last Scrollbar is left in (that is, after you manipulate the Scrollbar that causes the others to freeze, the frozen sliders are still in the configuration they were left in previously, so we're not just seeing a "ghost" of a scrollbar on another tabs).

  Another data point: Someone from the Python group tried the same test using a Python 3.2.3 linked with an X11 Tk 8.5 (MacPorts) rather than the ActiveState Cocoa Tk 8.5.11 (python.org Python).  I was not able to get the test to fail with X11 Tk so that tends to support the idea that the root cause is somewhere in Aqua Tk.


tkt_uuid: 3535362fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.5.11
resolution: Fixed
title: tk-8.5.8 does not compile with uclibc-nptl-0.9.33
comment:
  OS Platform : Linux (any version)
  Libc : uclibc-nptl-0.9.33

  Problem Behavior :
  ________________

  Building tk-8.5.8 package against uclibc-nptl-0.9.33 fails as follows :
  ---------------------------------------------------------------------------------------------------------------------------------------
  build/packages/tk-sh4_uclibc/BUILD/tk8.5.8/unix/../generic/ttk/ttkTreeview.c:482:17:
  error: conflicting types for 'unshare'
  /sh4_uclibc/target/usr/include/bits/sched.h:85:12:
  note: previous declaration of 'unshare' was here
  make: *** [ttkTreeview.o] Error 1
  ---------------------------------------------------------------------------------------------------------------------------------------
  Indeed uclibc commit w/ git id 19dd090a0f68765db87990ef8eda9bf77bb29581
  exported the unshare libc function to invoke the unshare kernel syscall.
  Unfortunately, tk8.5.8/generic/ttk/ttkTreeview.c got a static function called 'unshare' which
  clashes with libc one during compilation because definition of the latter gets loaded in.
  This issue is not appearing when compiling against glibc as in this case a different headers
  inclusion chain is generated vs uclibc so the libc unshare definition doesn't get loaded.

  Expected Behavior :
  ________________

  tk8.5.8/unix/../generic/ttk/ttkTreeview.c shall compile fine.

  Solution :
  ________

  Shall be to rename the unshare function inside ttkTreeview.c .


tkt_uuid: 3537673fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.5.11
resolution: Wont Fix
title: erroneous png-image on MAC OSX
comment:
  Hello,

  if I create a button with an transparent png-File,
  the image is displayed erroneous in the button.

  MAC OSX (core); tcl/tk 8.5.11; tkimg 1.4

  On other platforms (windows/Linux) the image is shown correct.

  test_icon.png = the button-Image
  screenshot.png = Screenshot of the erroneous image

  Here the test-script:

  toplevel .a
  image create photo bild1 -file test_icon.png
  button .a.b -image bild1
  grid .a.b


  Am i doing something wrong or is there a bug in tkimg on MAC-Platform?

  Thanks for any help!
  Matthias


tkt_uuid: 3538401fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: Documentation: winfo/wm geometry
comment:
  winfo geometry and wm geometry return different values, yet the differences are not documented.

  I see, it is in the FAQ, but not the main documentation.

  5.7. What is the difference between wm and winfo?
  wm (short for window manager) is used for managing or finding information about toplevels, while winfo (short for widget info) is for querying info about all types of widgets.

  For example, wm geometry . will give you the size of the main toplevel, including window manager decoration, as perceived by the window manager. However, winfo geometry . returns only the size of . as perceived by Tk.


tkt_uuid: 3543420fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Toggle.TButton style doesn't work on Windows
comment:
  I need a toggle button for an expansion dialog (i.e., you click the button and it stays down and the dialog expands to show more widgets; you click the button again and it comes up and the dialog contracts to show fewer widgets). See the OpenOffice Find dialog for an example.

  This is easy to achieve by creating a custom style. However, it only seems to work on Linux, it does not work on Windows. Attatched is some code that illustrates the point (in Python 3/tkinter).


tkt_uuid: 3546073fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 3 Low
foundin: obsolete: 8.5.11
resolution: Fixed
title: crashing on exit when /tmp is cleaned (unix socket deleted)
comment:
  The easiest way to reproduce the problem is using wish application supplied by tktoolkit. The setup is the following. 
  1. We need to start vncserver on linux machine.
  2. Delete files under /tmp, more precisely /tmp/.X11-unix/* which stores the unix sockets for VNC servers.
  3. Make sure DISPLAY variable is set to this format: ":port.screen" so that machine name is omitted. For example: "setenv DISPLAY :1". This is important as missing display name forces Tk to use unix sockets.
  4. Start wish and notice long start up time which will be explained later.
  5. Type exit in wish console and tool crashes with the following stack:

  =============================================
  #0  0x00000000004c7026 in TkWmDeadWindow (winPtr=0xa03fb0) at tcltk/tk8.5.11/unix/../unix/tkUnixWm.c:904
  #1  0x0000000000419325 in Tk_DestroyWindow (tkwin=0xa03fb0) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:1441
  #2  0x00000000004c5290 in TkSendCleanup (dispPtr=0x8d2e50) at tcltk/tk8.5.11/unix/../unix/tkUnixSend.c:1316
  #3  0x00000000004b8875 in TkpCloseDisplay (dispPtr=0x8d2e50) at tcltk/tk8.5.11/unix/../unix/tkUnixEvent.c:155
  #4  0x0000000000417b9b in TkCloseDisplay (dispPtr=0x8d2e50) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:300
  #5  0x000000000041aaa8 in DeleteWindowsExitProc (clientData=0x8cc270) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:2818
  #6  0x00000000004e6cb9 in TkFinalizeThread (clientData=0x0) at tcltk/tk8.5.11/unix/../generic/tkEvent.c:2112
  #7  0x000000000057dd64 in Tcl_FinalizeThread () at tcltk/tcl8.5.11/unix/../generic/tclEvent.c:1235
  #8  0x000000000057dc3a in Tcl_Finalize () at tcltk/tcl8.5.11/unix/../generic/tclEvent.c:1054
  #9  0x000000000057db1c in Tcl_Exit (status=0) at tcltk/tcl8.5.11/unix/../generic/tclEvent.c:906
  #10 0x0000000000526938 in Tcl_ExitObjCmd (dummy=0x0, interp=0x8a8250, objc=1, objv=0x8aa128) at tcltk/tcl8.5.11/unix/../generic/tclCmdAH.c:726
  #11 0x000000000051ad6d in TclEvalObjvInternal (interp=0x8a8250, objc=1, objv=0x8aa128, command=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, length=-1, flags=0) at tcltk/tcl8.5.11/unix/../generic/tclBasic.c:3703
  #12 0x0000000000581385 in TclExecuteByteCode (interp=0x8a8250, codePtr=0xb5d940) at tcltk/tcl8.5.11/unix/../generic/tclExecute.c:2416
  #13 0x000000000057f4a0 in TclCompEvalObj (interp=0x8a8250, objPtr=0xb2adb0, invoker=0x0, word=0) at tcltk/tcl8.5.11/unix/../generic/tclExecute.c:1538
  #14 0x000000000051d22b in TclEvalObjEx (interp=0x8a8250, objPtr=0xb2adb0, flags=131072, invoker=0x0, word=0) at tcltk/tcl8.5.11/unix/../generic/tclBasic.c:5272
  #15 0x000000000051cdbf in Tcl_EvalObjEx (interp=0x8a8250, objPtr=0x190, flags=131072) at tcltk/tcl8.5.11/unix/../generic/tclBasic.c:5054
  #16 0x0000000000596575 in Tcl_RecordAndEvalObj (interp=0x8a8250, cmdPtr=0xb2adb0, flags=131072) at tcltk/tcl8.5.11/unix/../generic/tclHistory.c:159
  #17 0x00000000005962e6 in Tcl_RecordAndEval (interp=0x8a8250, cmd=0x8c7978 "exit\n", flags=131072) at tcltk/tcl8.5.11/unix/../generic/tclHistory.c:57
  #18 0x0000000000417864 in StdinProc (clientData=0xb34c00, mask=2) at tcltk/tk8.5.11/unix/../generic/tkMain.c:380
  #19 0x00000000005a6cb5 in Tcl_NotifyChannel (channel=0xb34c00, mask=2) at tcltk/tcl8.5.11/unix/../generic/tclIO.c:7836
  #20 0x000000000060a38e in FileHandlerEventProc (evPtr=0xb543c0, flags=-3) at tcltk/tcl8.5.11/unix/../unix/tclUnixNotfy.c:637
  #21 0x00000000005c6218 in Tcl_ServiceEvent (flags=-3) at tcltk/tcl8.5.11/unix/../generic/tclNotify.c:675
  #22 0x00000000005c665f in Tcl_DoOneEvent (flags=-3) at tcltk/tcl8.5.11/unix/../generic/tclNotify.c:978
  #23 0x00000000004e6cea in Tk_MainLoop () at tcltk/tk8.5.11/unix/../generic/tkEvent.c:2139
  #24 0x00000000004176d1 in Tk_MainEx (argc=-1, argv=0x7fbfffed50, appInitProc=0x417043 <Tcl_AppInit>, interp=0x8a8250) at tcltk/tk8.5.11/unix/../generic/tkMain.c:311
  #25 0x0000000000417037 in main (argc=1, argv=0x7fbfffed48) at tcltk/tk8.5.11/unix/../unix/tkAppInit.c:66
  =============================================


  The reason for the crash is some reference counter messed up on application start up. Due to missing socket file deleted from /tmo/.X11-unix directory the tktoolkit tries to open display twice. First time it happens here. Please notice display name ":8.0".

  =============================================
  #0  TkpOpenDisplay (displayNameStr=0x8d9620 ":8.0") at tcltk/tk8.5.11/unix/../unix/tkUnixEvent.c:119
  #1  0x0000000000417e4e in GetScreen (interp=0x8a8250, screenName=0x8d9620 ":8.0", screenPtr=0x7fbfffe4e4) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:494
  #2  0x0000000000417c77 in CreateTopLevelWindow (interp=0x8a8250, parent=0x0, name=0x7fbfffe7f8 "wish8.5", screenName=0x623f5a "", flags=0) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:380
  #3  0x00000000004186fa in TkCreateMainWindow (interp=0x8a8250, screenName=0x623f5a "", baseName=0x7fbfffe7f8 "wish8.5") at tcltk/tk8.5.11/unix/../generic/tkWindow.c:883
  #4  0x0000000000424fe6 in CreateFrame (clientData=0x0, interp=0x8a8250, objc=4, objv=0x8c9d90, type=TYPE_TOPLEVEL, appName=0x7fbfffe7f8 "wish8.5") at tcltk/tk8.5.11/unix/../generic/tkFrame.c:556
  #5  0x0000000000424bcf in TkCreateFrame (clientData=0x0, interp=0x8a8250, argc=4, argv=0x7fbfffe8c0, toplevel=1, appName=0x7fbfffe7f8 "wish8.5") at tcltk/tk8.5.11/unix/../generic/tkFrame.c:439
  #6  0x000000000041b13d in Initialize (interp=0x8a8250) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:3163
  #7  0x000000000041ab05 in Tk_Init (interp=0x8a8250) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:2854
  #8  0x0000000000417073 in Tcl_AppInit (interp=0x8a8250) at tcltk/tk8.5.11/unix/../unix/tkAppInit.c:96
  #9  0x000000000041753d in Tk_MainEx (argc=-1, argv=0x7fbfffed50, appInitProc=0x417043 <Tcl_AppInit>, interp=0x8a8250) at tcltk/tk8.5.11/unix/../generic/tkMain.c:249
  #10 0x0000000000417037 in main (argc=1, argv=0x7fbfffed48) at tcltk/tk8.5.11/unix/../unix/tkAppInit.c:66
  =============================================

  Second attempt to open display happens here. Please notice display name "localhost:8.0" which would force to use tcpip sockets instead of unix sockets to opening display.

  =============================================
  #0  0x00000000004c7026 in TkWmDeadWindow (winPtr=0xa03fb0) at tcltk/tk8.5.11/unix/../unix/tkUnixWm.c:904
  #1  0x0000000000419325 in Tk_DestroyWindow (tkwin=0xa03fb0) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:1441
  #2  0x00000000004c5290 in TkSendCleanup (dispPtr=0x8d2e50) at tcltk/tk8.5.11/unix/../unix/tkUnixSend.c:1316
  #3  0x00000000004b8875 in TkpCloseDisplay (dispPtr=0x8d2e50) at tcltk/tk8.5.11/unix/../unix/tkUnixEvent.c:155
  #4  0x0000000000417b9b in TkCloseDisplay (dispPtr=0x8d2e50) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:300
  #5  0x000000000041aaa8 in DeleteWindowsExitProc (clientData=0x8cc270) at tcltk/tk8.5.11/unix/../generic/tkWindow.c:2818
  #6  0x00000000004e6cb9 in TkFinalizeThread (clientData=0x0) at tcltk/tk8.5.11/unix/../generic/tkEvent.c:2112
  #7  0x000000000057dd64 in Tcl_FinalizeThread () at tcltk/tcl8.5.11/unix/../generic/tclEvent.c:1235
  #8  0x000000000057dc3a in Tcl_Finalize () at tcltk/tcl8.5.11/unix/../generic/tclEvent.c:1054
  #9  0x000000000057db1c in Tcl_Exit (status=0) at tcltk/tcl8.5.11/unix/../generic/tclEvent.c:906
  #10 0x0000000000526938 in Tcl_ExitObjCmd (dummy=0x0, interp=0x8a8250, objc=1, objv=0x8aa128) at tcltk/tcl8.5.11/unix/../generic/tclCmdAH.c:726
  #11 0x000000000051ad6d in TclEvalObjvInternal (interp=0x8a8250, objc=1, objv=0x8aa128, command=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>, length=-1, flags=0) at tcltk/tcl8.5.11/unix/../generic/tclBasic.c:3703
  #12 0x0000000000581385 in TclExecuteByteCode (interp=0x8a8250, codePtr=0xb5d940) at tcltk/tcl8.5.11/unix/../generic/tclExecute.c:2416
  #13 0x000000000057f4a0 in TclCompEvalObj (interp=0x8a8250, objPtr=0xb2adb0, invoker=0x0, word=0) at tcltk/tcl8.5.11/unix/../generic/tclExecute.c:1538
  #14 0x000000000051d22b in TclEvalObjEx (interp=0x8a8250, objPtr=0xb2adb0, flags=131072, invoker=0x0, word=0) at tcltk/tcl8.5.11/unix/../generic/tclBasic.c:5272
  #15 0x000000000051cdbf in Tcl_EvalObjEx (interp=0x8a8250, objPtr=0x190, flags=131072) at tcltk/tcl8.5.11/unix/../generic/tclBasic.c:5054
  #16 0x0000000000596575 in Tcl_RecordAndEvalObj (interp=0x8a8250, cmdPtr=0xb2adb0, flags=131072) at tcltk/tcl8.5.11/unix/../generic/tclHistory.c:159
  #17 0x00000000005962e6 in Tcl_RecordAndEval (interp=0x8a8250, cmd=0x8c7978 "exit\n", flags=131072) at tcltk/tcl8.5.11/unix/../generic/tclHistory.c:57
  #18 0x0000000000417864 in StdinProc (clientData=0xb34c00, mask=2) at tcltk/tk8.5.11/unix/../generic/tkMain.c:380
  #19 0x00000000005a6cb5 in Tcl_NotifyChannel (channel=0xb34c00, mask=2) at tcltk/tcl8.5.11/unix/../generic/tclIO.c:7836
  #20 0x000000000060a38e in FileHandlerEventProc (evPtr=0xb543c0, flags=-3) at tcltk/tcl8.5.11/unix/../unix/tclUnixNotfy.c:637
  #21 0x00000000005c6218 in Tcl_ServiceEvent (flags=-3) at tcltk/tcl8.5.11/unix/../generic/tclNotify.c:675
  #22 0x00000000005c665f in Tcl_DoOneEvent (flags=-3) at tcltk/tcl8.5.11/unix/../generic/tclNotify.c:978
  #23 0x00000000004e6cea in Tk_MainLoop () at tcltk/tk8.5.11/unix/../generic/tkEvent.c:2139
  #24 0x00000000004176d1 in Tk_MainEx (argc=-1, argv=0x7fbfffed50, appInitProc=0x417043 <Tcl_AppInit>, interp=0x8a8250) at tcltk/tk8.5.11/unix/../generic/tkMain.c:311
  #25 0x0000000000417037 in main (argc=1, argv=0x7fbfffed48) at tcltk/tk8.5.11/unix/../unix/tkAppInit.c:66
  =============================================


tkt_uuid: 3547229fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Tk crashes when drawing many dashed objects
comment:
  When drawing many dashed lines (problably arcs, ...) wish crashes.
  Problem found on Linux only.
  Error messsage:
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  55 (X_CreateGC)
    Value in failed request:  0x0
    Serial number of failed request:  1481
    Current serial number in output stream:  1485

  Attached example:
  Unpack (tar -xzvf view_dxf-8.5-0.3_bugrep.tgz)
    ./view_dxf-8.5-0.3.tk Scheibenkupplunhshaelfte1.dxf

  wish crashes almost all time on Tk 8.5
  wish crashes less often on Tk 8.6 (try reloading by double click icon "*" entry in the listbox if no crash)  
  effect not found on Tk 8.4 or Windows
  example requires BWidget.


tkt_uuid: 354c19b3ef2fb18b1f81f60fa35ae75762ac020e
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
severity: Important
foundin: 8.6.0
private_contact: d4bbf66f445929e627fc15cea06ac36f09044260
resolution: Duplicate
title: [$png write foo.png -background red] produces bad image
comment:
  I downloaded an image (http://media.firebox.com/i/2013/newlogo.png) and was trying to add a background color to it. For some reason, when I opened the original in Photoshop, the semi-transparent shadow came up as solid black, so I decided to do it through ActiveTcl 8.6.0 instead. The image loaded into Tcl without any problem, and displayed perfectly in a label widget. I then tried to save it ($image write $filename -format png -background $color), but the image created was garbled - Photostop won't open it, and neither will Tcl. It opens in Windows Picture Viewer but it's totally garbled.

  As a quick test, I made a new image in Photoshop - a png with a transparent background and a simple coloured line - and repeated the process, loading into Tcl and writing with a background. This image was similarly garbled, so I guess it's a general Tk issue, and not related to the actual image I was using.

  % set src [image create photo -file newlogo.png]
  % pack [label .l -image $src]
  % $src write "dest.png" -format png -background red
  % set dst [image create photo -file dest.png]
  invalid filter type 255


tkt_uuid: 3550691fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: None
title: Default font settings don't work well with high DPI
comment:
  Hi!

  As far as I can see the default font sizes on Unix are specified in pixels:

  % font configure TkDefaultFont
  -family sans-serif -size -12 -weight normal -slant roman -underline 0 -overstrike 0

  As a result, they look too small on a high resolution screen (tried on a laptop with 165DPI display).


tkt_uuid: 3551632fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: None
resolution: Accepted
title: Implement fullscreen on Tk-Cocoa
comment:
  Full-screen worked on Tk-Carbon but failed on Tk-Cocoa.  On inspection of the code, it appeared that the implementation from Carbon was just left in the code, but it does not work under Cocoa.  The attached patch removes this and substitutes appropriate Cocoa code so that wm attributes <win> -fullscreen 1/0 works.


tkt_uuid: 3551777fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: Fix bug that ignored initial menu item disablement
comment:
  Creating menu items under the main menu with -state disabled would result in enabled menu items.  The reason was some code present in TkpConfigureMenuEntry which overzealously tried to rectify situations when an entire menu or submenu is disabled and then reenabled.


tkt_uuid: 3551802fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: None
resolution: None
title: Use the Xkb API to simply Tk's keyboard event handling
comment:
  Building Tk 8.5.12 results in a handful of compiler warnings stating that XKeycodeToKeysym is deprecated, all in unix/tkUnixKey.c.
  Here's a naive patch that passes the tests.
  I have no idea what is the correct thing to do here.


tkt_uuid: 3552404fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Fixed
title: ttk::entry - overzealous clipping
comment:
  Symptom (observed on Tk trunk under X11)

  pack [ttk::entry .e -width 10] -expand true -fill x

  Type in .e until it needs to scroll. Rightmost characters are not displayed, neither is insert cursor.

  Selection rectangle however is displayed.

  Suspected cause of problem: dkf's latest change.


tkt_uuid: 3552805fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Make ".canvas lower" work with non-existent belowThis tag
comment:
  This is new behaviour, and i ~think~ is probably a bug.

  If the "belowThis" tag is not defined, wish throws an error.
  All previous version os wish this does not happen.

  pack [canvas .c]
  .c create line 0 0 10 10 -tags aline
  .c lower aline noline

  > tag "noline" doesn't match any items


tkt_uuid: 3553180fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk::treeview can't be disabled
comment:
  ... or, rather, disabling it doesn't do anything, at least as of Tk 8.5.9. It still responds to all events, allowing the selection to be changed, columns to be resized, etc. In my app I do:

    foreach x [bind Treeview] {
       bind Treeview $x [format {if { ![%%W instate disabled] } { %s }} [bind Treeview $x]]
    }

  to make a disabled treeview totally disabled, but I think something like this should be the default.


tkt_uuid: 3553547fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: tk_getOpenFile -multiple 1 on linux, selection behaviour
comment:
  Activestate Tk 8.5.11, also the just released 8.5.12, OpenSuse 11.4 (if it matters)

  While tk_getOpenFile -multiple 1 on windows opens a file dialog which
  behaves as other dialogs allowing multiple selections of items (dragging
  the mouse selects multiple items, Control-mouse adds a single item to
  the selection, Shift-keyboard traversal also selects multiple items),

  on Linux the behaviour is strange IMHO:
  - in order to select multiple items I have to Shift-Drag the mouse
    (would have expected simple drag)
  - multiple selection via keyboard using shfit-up/down is not possible at all
    (would have expected to Shift-Arrow-Up/Down-select files)

  This comes unexpected, since:
  - Control-mouse selects a single item as expected
  - Shift-Mouse also extends the selection as expected

  Even if -multiple 0 is specified, Shift-Mouse-Motion draws a selection
  where it shouldn't.  While it actually selects only a single item, it
  shows multiple as selected.

  Also if the mouse leaves the window, the selected items are no longer
  shown as selected (though the selection still exists and is re-shown if
  changed).


tkt_uuid: 3554026fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 9 Immediate
foundin: obsolete: 8.6b3
resolution: Fixed
title: tearing off menu with embedded parent -> crash (X11)
comment:
  Tearing off menus which are children of embedded windows makes Tk crash on X11.
  The problem is in unix/tkUnixWm.c, function TkSetTransientFor().
  This function checks for the nearest toplevel parent with Tk_IsTopLevel.
  For embedded windows this function returns true, but their wmInfoPtr->wrapperPtr
  member is NULL.
  Easy to repro using tkchat+tktray, trying to torn off the tray menu.
  Attached patch solves the issue by checking for wmInfoPtr->wrapperPtr being non NULL.


tkt_uuid: 3555211fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Fixed
title: Cocoa 8.5.12 backport crashes when using clipboard copy
comment:
  With the OS X Cocoa backport of Tcl/Tk 8.5.12 (as seen in ActiveTcl 8.5.12 for OS X), attempting to use clipboard Copy with a text widget causes an immediate crash in the interpreter.  This is a serious regression from 8.5.11.

  See discussion on tcl-mac list beginning here:
  https://sourceforge.net/mailarchive/message.php?msg_id=29646437


tkt_uuid: 3556238fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: None
title: Documentation of tk_getOpenFile wrong
comment:
  The doucmentation for tk_getOpenFile states:
      -initialfile filename
          Specifies a filename to be displayed in the dialog when it pops up. This option is ignored on the Macintosh platform.

  Tk bug #829003 clearly states this option is not ignored, in fact the tk_getOpenFile call fails if the file does not exists.


tkt_uuid: 3558535fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Fixed
title: Error when entering file pattern containing special chars
comment:
  In wish, execute
   tk_getOpenFile

  In "File name" type a pattern like "*.j[g" and hit enter.

  Expected behavior: Only files matching "*.j[g" are shown (if any such files exist)
  Actual behavior: "Application Error" "Error: missing close-bracket" and the contents of the file dialog are corrupted

  Note that this is also an opportunity to enter arbitrary Tcl code, like "*[exit]", which will be evaluated on hitting enter.


tkt_uuid: 3561016fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Fixed
title: -type tearoff segfault
comment:
  ---a.tcl------8<---------
  menu .mb -type tearoff
  ------------8<---------

  $ wish a.tcl
  Segmentation fault (core dumped)


tkt_uuid: 3564189fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: None
title: configure gives inconsistent result for aliased option
comment:
  Example:
  1 % info patchlevel
  8.5.12
  2 % canvas .c
  .c
  3 % join [.c configure] \n
  -background background Background SystemButtonFace SystemButtonFace
  -bd borderWidth
  -bg background
  -borderwidth borderWidth BorderWidth 0 0
  ...
  % frame .f
  .f
  5 % join [.f configure] \n
  -bd -borderwidth
  -borderwidth borderWidth BorderWidth 0 0
  ...
  -background background Background SystemButtonFace SystemButtonFace
  -bg -background
  ...
  Expected:
  dbName without dash in all cases. This is what the manual says for Tk_ConfigureInfo.


tkt_uuid: 3565268fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: None
title: bind<ButtonRelease-1> doesnt have same behavior on windows
comment:
  Copied over from
  http://sf.net/tracker/?func=detail&aid=3565164&group_id=10894&atid=110894
  see that ticket for the attachment.

  I write a xml layout feature for my work, recently. And I want bind a radiobutton or checkbutton click event on a method, but do not affect "command" configure option.
  so I use the Events and Bindings, I write it like this widget.bind("<ButtonRelease-1>", lambda event: self.enable_toggle(data))
  and
  def enable_toggle(self, widget):
  print widget_value_map[widget].get() # this will get the widget's variable and get it value.

  on linux platform, the <ButtonRelease-1> event will be called after variable change, so I get the correct value in enable_toggle
  but on windows platform, the event will be called before variable change, so I get the wrong value.

  version:(python version 2.7.3)
  Linux:
  >>> Tkinter.TkVersion
  8.5
  >>> Tkinter.TclVersion
  8.5
  Windows:
  >>> Tkinter.TkVersion
  8.5
  >>> Tkinter.TclVersion
  8.5


  I wrte a simple code(attachment) to show this bug. I want the code have same result on linux and windows, but it doesnt.

  BTW: Is there a way to bind multiple method to an button click event? If a better one please tell me. Thank you. mailto: zy.netsec@gmail.com


tkt_uuid: 3565533fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 7 High
foundin: obsolete: 8.6b3
resolution: Fixed
title: uninitialized variable "written"
comment:
  Got a compiler warning:

  tkCanvPs.c: In function ‘TkCanvPostscriptCmd’:
  tkCanvPs.c:173: warning: ‘written’ may be used uninitialized in this function

  Looking at lines 614-619, I think the warning is in
  fact pointing out a programming error.  Shouldn't
  "written" be storing the value returned by the
  Tcl_WriteObj() call?


tkt_uuid: 3566106fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Accepted
title: Tk 8.5.12 fails to build on Solaris 9/x86
comment:
  In working with the OpenCSW people about updating Tcl/Tk in OpenCSW (package distribution for Solaris) they ran into an issue with building Tk on Solaris 9/x86.

  They provided this patch:
        http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/tcl85/trunk/files/0002-Fix-linking-issues-and-enable-building-on-Solaris-9-.patch

  They indicate that "amd64" isn't part of the platform specification on Solaris 9 (Solaris 10+ only) and so the check should also include a check for "i386" only.

  Additionally there were some places where a single digit minor version wasn't checked for.


tkt_uuid: 3566594fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Fixed
title: ttkLabel does not reset clip mask
comment:
  We encountered strangely clipped text in ttk::buttons and treeviews under AIX and Solaris. On Linux and Windows the problem did not occur. Presumably the difference is related to the presence or absence of the HAVE_XFT macro.

  Inspection revealed that the function TextDraw in ttkLabel.c sets a clipping mask without resetting it at the end. The attached patch seems to fix the problem. 


tkt_uuid: 3567037fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Duplicate
title: compiler warning
comment:
  Twylite reports on TCLCORE:

  C:\User\Tcl_BUILD\tcl86b3rc\tcl8.6b3\pkgs\tk8.6b3\win\..\win\tkWinWm.c(5529) 
  : warning C4133: 'function' : incompatible types - from 'TkWindow *' to 
  'Tk_Window'


tkt_uuid: 3567283fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Fixed
title: Incompatible pointer cast in tkWinWm.c
comment:
  While building 32-bit Tk from checkout [42c5de9b] (= core-8-6-b3-rc 2012/09/13) with MSVC2010 on Windows 7:

  tk\win\..\win\tkWinWm.c(5529) : warning C4133: 'function' : incompatible types - from 'TkWindow *' to 'Tk_Window'


tkt_uuid: 3567778fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 8
foundin: obsolete: 8.6b3
resolution: Fixed
title: unixfont-5.11 hang
comment:
  In an --enable-aqua build of Tk8.6b3, the test suite
  hangs up in test unixfont-5.11 when building and
  testing on Snow Leopard. Spinning rainbow ball.

  At least once when I left it hang long enough, I got
  printed to the console terminal a series messages
  like this:

  tktest(30053,0x7fff70636cc0) malloc: *** auto malloc[30053]: agc error: Can not allocate new region


tkt_uuid: 3567779fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.6b3
resolution: Fixed
title: winWm-9.2 segfault
comment:
  In an --enable-aqua build of Tk8.6b3, running the test suite
  on Snow Leopard segfaults on test winWm-9.2 .

  If I use -match to run only that test, there is no
  segfault.

  It may be that this test isn't appropriate to run
  on Mac OSX, I don't know, but even so a
  segfault triggered by script eval is a bug needing
  a fix.


tkt_uuid: 3567786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 9 Immediate
foundin: obsolete: 8.6b3
resolution: Fixed
title: wm.test segfaults
comment:
  An --enable-aqua build on Snow Leopard
  produces segfaults in the tests
  wm-manage-* and wm-forget-* in wm.test.


tkt_uuid: 3567812fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 8
foundin: obsolete: 8.6b3
resolution: Fixed
title: [clipboard clear] segfaults
comment:
  On a --enable-aqua build on a Snow Leopard system,
  the simple command [clipboard clear] immediately segfaults.


tkt_uuid: 3567838fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: None
title: unixMenu.test noise
comment:
  With --enable-aqua build on Snow Leopard all
  tests in unixMenu.test pass.  However, a lot of
  noisy lines get spilled onto the console like this:

  Fri Sep 14 20:53:44 Donald-Porters-MacBook-Pro.local tktest[56070] <Error>: kCGErrorIllegalArgument: CGSClearWindowTags: Invalid window 0x0

  Seems something not right is going on somewhere.


tkt_uuid: 3569637fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.12
resolution: Works For Me
title: Crash under Mac OS X
comment:
  I'm getting crash of the application while a call to [update idletasks] under Mac OS X 10.6.
  I've compiled Tcl and Tk by myself from sources - version 8.5.12. Itcl and Itk got from ActiveTcl.
  Note, that the application is quiet big and it's hard to tell what's in the events queue that causes the crash.

  To reproduce the problem you can download MacOSX boundle from: http://sqlitestudio.one.pl/files/free/unstable/osx/sqlitestudio-2.0.902.zip
  To invoke an error create sample database, then create table and then double-click on the table to open it. Then the app crashes.

  Here's a crash stack:
  Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
  0   Tk                            0x0b0cbb2d TkpSetMainMenubar + 2715
  1   Tk                            0x0b04228c TkCreateFrame + 21118
  2   Tk                            0x0b0179b9 TkFontPkgFree + 245
  3   Tk                            0x0b0179c5 TkFontPkgFree + 257
  4   Tcl                           0x0a09f2d8 TclServiceIdle + 61
  5   Tcl                           0x0a081233 Tcl_DoOneEvent + 342
  6   Tk                            0x0b00dd3a TkGetDisplayOf + 424
  7   Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  8   Tcl                           0x0a04e66d TclStackAlloc + 7349
  9   Tcl                           0x0a057b42 TclStackAlloc + 45450
  10  Tcl                           0x0a0133ed TclEvalObjEx + 877
  11  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  12  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  13  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  14  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  15  Tcl                           0x0a04e66d TclStackAlloc + 7349
  16  Tcl                           0x0a057b42 TclStackAlloc + 45450
  17  Tcl                           0x0a0133ed TclEvalObjEx + 877
  18  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  19  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  20  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  21  libitcl3.4.dylib              0x000eaae2 Itcl_EvalArgs + 425
  22  libitcl3.4.dylib              0x000e7b1d Itcl_HandleInstance + 553
  23  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  24  Tcl                           0x0a04e66d TclStackAlloc + 7349
  25  Tcl                           0x0a057b42 TclStackAlloc + 45450
  26  Tcl                           0x0a0133ed TclEvalObjEx + 877
  27  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  28  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  29  libitcl3.4.dylib              0x000e5420 Itcl_InvokeMethodIfExists + 187
  30  libitcl3.4.dylib              0x000e871e Itcl_CreateObject + 1430
  31  libitcl3.4.dylib              0x000dd69e Itcl_HandleClass + 1101
  32  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  33  Tcl                           0x0a04e66d TclStackAlloc + 7349
  34  Tcl                           0x0a057b42 TclStackAlloc + 45450
  35  Tcl                           0x0a0133ed TclEvalObjEx + 877
  36  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  37  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  38  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  39  libitcl3.4.dylib              0x000eaae2 Itcl_EvalArgs + 425
  40  libitcl3.4.dylib              0x000e7b1d Itcl_HandleInstance + 553
  41  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  42  Tcl                           0x0a04e66d TclStackAlloc + 7349
  43  Tcl                           0x0a057b42 TclStackAlloc + 45450
  44  Tcl                           0x0a0133ed TclEvalObjEx + 877
  45  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  46  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  47  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  48  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  49  Tcl                           0x0a04e66d TclStackAlloc + 7349
  50  Tcl                           0x0a057b42 TclStackAlloc + 45450
  51  Tcl                           0x0a0133ed TclEvalObjEx + 877
  52  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  53  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  54  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  55  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  56  Tcl                           0x0a04e66d TclStackAlloc + 7349
  57  Tcl                           0x0a057b42 TclStackAlloc + 45450
  58  Tcl                           0x0a0133ed TclEvalObjEx + 877
  59  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  60  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  61  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  62  libitcl3.4.dylib              0x000eaae2 Itcl_EvalArgs + 425
  63  libitcl3.4.dylib              0x000e7b1d Itcl_HandleInstance + 553
  64  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  65  Tcl                           0x0a012b22 Tcl_CreateInterp + 8033
  66  Tcl                           0x0a012e5a Tcl_EvalEx + 58
  67  Tk                            0x0b00bb24 Tk_BindEvent + 4972
  68  Tk                            0x0b00f20b TkBindEventProc + 295
  69  Tk                            0x0b016638 Tk_HandleEvent + 1523
  70  Tk                            0x0b016707 Tk_HandleEvent + 1730
  71  Tcl                           0x0a080f2f Tcl_ServiceEvent + 160
  72  Tcl                           0x0a081222 Tcl_DoOneEvent + 325
  73  Tk                            0x0b015e20 Tk_MainLoop + 37
  74  Tk                            0x0b023f56 Tk_MainEx + 2041
  75  Wish                          0x00004610 0x1000 + 13840
  76  Wish                          0x0000456d 0x1000 + 13677


tkt_uuid: 3572016fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Fixed
title: Aqua menus do not get re-enabled
comment:
  Try the following using Tk 8.6b3 (Tk-Cocoa) on OS X (happens in OS X 10.7 and 10.8 at least). This works with any of the wish menus apart from the "Wish" menu itself:

  1. Launch wish
  2. Select one of the wish menus and see that the items are enabled
  3. type into the console: "tk_chooseColor"
  3. while the dialog is open: select one of the wish menus and see that the items are disabled
  4. dismiss the color dialog
  5. select one of the wish menus and see that the items are still disabled

  At step 5, the menus should be enabled again, but they are not. If you do the same sequence but skip step 3, then everything is OK. So it seems that choosing a menu while a modal dialog is open will correctly show disabled menu items but the menu will never be re-enabled afterwards.

  This happens not only in plain wish but also with custom menus from [. configure -menu]


tkt_uuid: 3572437fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Support of setAccessoryView on OS X for -filetypes
comment:
  The OS X versions of tk_get*File (Tk-Cocoa) do not display -filetypes comboboxes/menubuttons when the -filetypes option is specified. The list of possible files is merely filtered. On Linux and Windows a combobox/menubutton is shown and the user can choose a filetype.

  On OSX, the setAccessoryView task of the NSSavePanel and NSOpenPanel do support this kind of feature:

  http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSavePanel_Class/Reference/Reference.html#//apple_ref/occ/cl/NSSavePanel

  http://www.cocoabuilder.com/archive/cocoa/295153-custom-nssavepanel.html

  It looks as if this is relatively simple to implement and it would bring the OS X file dialogs to the same level as for the other platforms. If no -filetypes are specified, the accessory view could be hidden.

  In the future, this accessory view culd even be used to display more options like checkboxes, text and other stuff.


tkt_uuid: 3572695fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: None
title: Tk-Cocoa crashes on copy operation in text widget
comment:
  Make a text widget in a fresh Wish 8.6b3 in Tk-Cocoa on a Mac (I used OS X 10.8.2 here):

  text .t
  pack .t

  Then do the following:
  1. type some text into the text widget
  2. mark some text and do either cm+c to copy it or cmd+x to cut it out

  Tk will then crash with the following info:

  0   Tk                            0x000cbb6d TkpMakeWindow + 271
  1   Tk                            0x0003a27b Tk_MakeWindowExist + 135
  2   Tk                            0x0001515d TkClipInit + 152
  3   Tk                            0x00014f8e Tk_ClipboardClear + 54
  4   Tk                            0x000159f0 0x8000 + 55792
  5   Tcl                           0x0014c4f0 TclNREvalObjv + 2256
  6   Tcl                           0x001a1cc3 0x13d000 + 412867
  7   Tcl                           0x00149753 TclNRRunCallbacks + 70
  8   Tcl                           0x0014cde0 0x13d000 + 64992
  9   Tcl                           0x0014d266 Tcl_EvalEx + 58
  10  Tk                            0x0001300c Tk_BindEvent + 3740
  11  Tk                            0x00018a65 TkBindEventProc + 306
  12  Tk                            0x0001e0b5 Tk_HandleEvent + 1448
  13  Tk                            0x0001daab 0x8000 + 88747
  14  Tcl                           0x001d5b82 Tcl_ServiceEvent + 268
  15  Tcl                           0x001d5c6e Tcl_ServiceAll + 186
  16  Tcl                           0x002240a6 0x13d000 + 946342
  17  com.apple.CoreFoundation      0x970f1dfe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
  18  com.apple.CoreFoundation      0x970f1d3d __CFRunLoopDoObservers + 381
  19  com.apple.CoreFoundation      0x970cbecf __CFRunLoopRun + 1071
  20  com.apple.CoreFoundation      0x970cb63a CFRunLoopRunSpecific + 378
  21  com.apple.CoreFoundation      0x970cb4ab CFRunLoopRunInMode + 123
  22  com.apple.AppKit              0x93935edc _NSUnhighlightCarbonMenu + 185
  23  com.apple.AppKit              0x93ceae7f -[NSCarbonMenuImpl performMenuAction:withTarget:] + 378
  24  com.apple.AppKit              0x93c62f1b -[NSMenu _performKeyEquivalentWithDelegate:] + 389
  25  com.apple.AppKit              0x93c62fd6 -[NSMenu _performKeyEquivalentWithDelegate:] + 576
  26  com.apple.AppKit              0x93c62abb -[NSMenu performKeyEquivalent:] + 72
  27  com.apple.AppKit              0x93c61f5c -[NSApplication _handleKeyEquivalent:] + 915
  28  com.apple.AppKit              0x93b17ee1 -[NSApplication sendEvent:] + 5512
  29  Tk                            0x000d7823 0x8000 + 849955
  30  Tk                            0x000d7bab 0x8000 + 850859
  31  Tcl                           0x001d5d70 Tcl_DoOneEvent + 180
  32  Tk                            0x0001d89c Tk_MainLoop + 36
  33  Tk                            0x0002bbd2 Tk_MainEx + 1470
  34  wish-aqua8.6                  0x0000453e 0x1000 + 13630
  35  wish-aqua8.6                  0x000044cd 0x1000 + 13517


  Also, when pasting text from other sources into the text widget, nothing happens and the pasted text does not occur in the widget.


tkt_uuid: 3573447fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.6b3
resolution: None
title: [tk busy] causes crash on OS X/Cocoa
comment:
  Per a bug reported on c.l.t by Christian Gollwitzer, the following code eventually causes a lockup and segfault on Tk-Aqua trunk. "The crash is triggered by first pressing the button, after it has  'finished', selecting the entry in the pulldown list of the combobox,  maybe twice. Sometimes, this must be repeated several times."

  package require Tk 
  pack [ttk::combobox .cbx1 -values {"Select to crash"}] 
  pack [ttk::frame .fr -width 200 -height 200] 
  pack [ttk::button .fr.button -text "Press me for processing" -command Doit] 
  pack [ttk::label .fr.prog -textvariable progress] 

  proc Doit {} { 
          tk busy hold . 
          for {set ::progress 0} {$::progress<100} {incr ::progress} { 
                  after 10 
                  update 
          } 
          tk busy forget . 
  } 

  Considering that busy is supposed to be no-op on Aqua, this is very strange indeed. 


tkt_uuid: 3574708fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Accepted
title: Fix for crash in Tk focus handling
comment:
  I have been seeing intermittent crashes in wish, Tcl/Tk
  8.5.12 running on Windows-XP.  The crashes mostly occur
  when I am running some test harness scripts to exercise
  the functionality of my application, which as a side
  affect can rapidly create & destroy some windows. 
  Stress testing Tk a bit, I suppose.

  The problem turns out to be with calls to TkSetFocusWin
  in generic/tkFocus.c.  Not all calls are checking for a
  TK_ALREADY_DEAD window.  So TkSetFocusWin can insert a
  reference to a dead window into the focus-tracking
  DisplayFocusInfo structure.  This results in a
  subsequent crash, usually on the *next* call to
  TkSetFocusWin when it tries to move focus away from that
  window, by which time its window structure has been
  overwritten i.e. a use-after-free error.

  The fix is simple - move the check for a TK_ALREADY_DEAD
  window to within TkSetFocusWin, so that it is performed
  for all calls. I've exercised my application with the
  fix applied, with no more crashes.


  --- ./tkFocus.c-8.5.12  Thu Oct  4 18:00:03 2012
  +++ ./tkFocus.c-8.5.12-fix      Thu Oct  4 18:09:09 2012
  @@ -160,9 +160,7 @@
              if (newPtr == NULL) {
                  return TCL_ERROR;
              }
  -           if (!(newPtr->flags & TK_ALREADY_DEAD)) {
  -               TkSetFocusWin(newPtr, 0);
  -           }
  +           TkSetFocusWin(newPtr, 0);
              return TCL_OK;
          }
       }
  @@ -552,6 +550,14 @@
       TkWindow *topLevelPtr;
       int allMapped, serial;

  +    /*
  +     * Don't set focus if window is already dead.
  +     */
  +
  +    if (winPtr->flags & TK_ALREADY_DEAD) {
  +       return;
  +    }
  +
       displayFocusPtr = FindDisplayFocusInfo(winPtr->mainPtr, winPtr->dispPtr);

       /*
  {


tkt_uuid: 3574854fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: OSX/X11: font panic
comment:
  % font actual {zapfdingbats 12 roman normal} -family 
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  45 (X_OpenFont)
    Value in failed request:  0xc00005
    Serial number of failed request:  73
    Current serial number in output stream:  74

  Same thing works fine in 8.5 .  Some missing backport?

  Also test numbers in font.test have many dups.  Also fixed in 8.5.


tkt_uuid: 3574861fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Fixed
title: X11 fails to build
comment:
  8.5.12 release builds fine, but starting with 
  5b7f946912c4f9360d48c42572784079680f92d2 2012-10-02 00:45:42 UTC

  build attempts against X11 fail:

  tkUnixSend.c
  /Users/dgp/fossil/tk8.5/unix/../unix/tkUnixSend.c: In function ‘SendInit’:
  /Users/dgp/fossil/tk8.5/unix/../unix/tkUnixSend.c:1357: error: ‘TkDisplay’ has no member named ‘commTkWin’


tkt_uuid: 3575664fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 9 Immediate
foundin: obsolete: 8.5.12
resolution: Works For Me
title: Cocoa Tk 8.5: Python IDLE crashes opening Preferences
comment:
  With a current Tcl/Tk built from the tk-cocoa-8-5-backport branch on OS  and a Python that dynamically links with it, attempting to open Python IDLE's Preferences menu causes Tk to crash.  By bisecting changes, it appear that this critical regression was introduced by fossil checkin 5393f608dd on 2012-08-06 ("Fixes for menu and wm fullscreen bugs").  http://core.tcl.tk/tk/info/5393f608dd

  This problem was first noticed with the release of ActiveTcl 8.5.12.1, the current OS X ActiveTcl version; previous versions 8.5.12.0 and 8.5.11.1 do not exhibit this problem with IDLE.

  To reproduce, install either the current OS X ActivePython 2.7.2 (http://www.activestate.com/activepython/downloads) or an OS X 64-bit/32-bit python.org python (http://www.python.org/download/), install Tcl and Cocoa Tk 8.5 in /Library/Frameworks, launch IDLE (for example, type /usr/local/bin/idle2.7 in a shell), then either select Python -> Preferences from the menu bar or press command-, (comma), the keyboard accelerator for the Preferences menu item.
  Using a debug build of Cocoa Tk at current tip (77b3f433c7), the crash occurs at tkMacOSXMenu.c:681.  See the attached crash dump.

  http://bugs.python.org/issue15853


tkt_uuid: 3575681fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Works For Me
title: Cocoa 8.5.12 backport still crashes in IDLE clipboard copy
comment:
  With a current Tcl/Tk built from the tk-cocoa-8-5-backport branch on OS and a Python that dynamically links with it, attempting to use clipboard copy in Python IDLE's causes Tk to crash. A more general problem with clipboard copies in Text widgets was reported in #3555211 (https://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997) which was addressed in Fossil checkin 2fe193d134 on 2012-08-07 (http://core.tcl.tk/tk/info/2fe193d134).  That checkin resolved some of the crashes but crashes with IDLE still remain.   By the way, it appears that the original clipboard copy regression (as reported in #3555211) was introduced by fossil checkin 90d4b8b59c of 2012-07-25 (http://core.tcl.tk/tk/info/90d4b8b59c).

  The orginial problem documented in #3555211 was first noticed with the release of ActiveTcl 8.5.12.0.  ActiveTcl 8.5.12.1 apparently includes checkin 2fe193d134 and exhibits the problem documented in this issue as still seen with current tip.  The previous ActiveTcl version 8.5.11.1 does not exhibit this problem with IDLE.

  To reproduce, install either the current OS X ActivePython 2.7.2 (http://www.activestate.com/activepython/downloads) or an OS X 64-bit/32-bit python.org python (http://www.python.org/download/), install Tcl and Cocoa Tk 8.5 in /Library/Frameworks, launch IDLE (for example, type /usr/local/bin/idle2.7 in a shell).  Then when the IDLE PyShell menu appears, use the mouse to doubleclick on some text in the PyShell window (for example "copyright"), then use the mouse to select Edit -> Copy from the menu bar.  Using a debug build of Cocoa Tk at current tip (77b3f433c7), the crash occurs at TkpMakeWindow + 465 (tkMacOSXEmbed.c:169). See the attached crash dump.  Further observations:  The crash seems to only occur using the ActivePython 2.7.2 when selecting the Edit->Copy menu item (and not by using its keyboard accelerator Command-C) and only occurs if no other clipboard copies have succeeded; that is, if you use Command-C first, then Edit->Copy does not cause a crash.  Behavior with at least some python.org Python 3.3 (tested with 3.3.0rc1) is different in that the crash occurs using either Command-C or Edit->Copy, unlike 2.7 where only Edit->Copy crashes.

  http://bugs.python.org/issue15574


tkt_uuid: 3576114fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: text widget crashes on long lines if -wrap none is set
comment:
  With -wrap none, a sufficiently long line crashes the session.
  Running OpenSuse 11.4
  Crash occurs with tcl/tk 8.5.9 and 8.6b2
  Crash occurs with several different window managers

  Following program exhibits the crash:

  package require Tk
  set log_file /home/ian/tcl/crash_log

  proc main {} {
     text .t -width 80 -height 30 -bg white -font {arial -12} -wrap none
     pack .t -fill both -expand 1
     
     for {set i 0} {$i < 10000} {incr i} {
        update idletasks
        .t insert end "A"
        set fd [open $::log_file w]
        puts $fd $i
        close $fd
     }
  }
  main

  Note that the log file records how many characters were added
  before the crash. Experimenting with different font sizes shows
  that the crash occurs when the line exceeds about 8050 pixels.

  This is slightly similar to bug 624732 - but that is reported as fixed...


tkt_uuid: 3580159fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Wont Fix
title: indicatoron ignored on MacOS X
comment:
  The indicatoron option is ignored for checkbuttons on MacOS X. For example:

  checkbutton .b -text "Foo" -indicatoron 0
  pack .b

  This behaves correctly on linux (showing no checkbox) but on MacOS X the checkbox is displayed regardless of the value of indicatoron.


tkt_uuid: 3580194fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.5.12
resolution: Wont Fix
title: Width too narrow on MacOS X
comment:
  The -width option on tk_optionMenu results in a widget that is far too narrow to display that many characters on MacOS X. If -indicatoron is 1 the result is even worse (even less of the text is displayed). For example:

  tk_optionMenu .om omVar DC1 DC2 DC3
  .om configure -width 3
  pack .om

  this displays as expected on Linux, but the widget is far too narrow on MacOS X.


tkt_uuid: 3582795fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Virtual Bindings incompatible with previous versions of Tk
comment:
  Since 8.6b3, bindings do not appear to work the same way as before in applications. See for example this thread on c.l.t about tkcon - 
  https://groups.google.com/forum/?fromgroups=#!searchin/comp.lang.tcl/tkcon$20bindings/comp.lang.tcl/7ki8-TxMNdk/bn7lr7LTmUwJ

  dkf suggested in that thread this might be a result of the new virtual event definitions added for 8.6b3.

  Is this a temporary state of affairs that will be fixed for 8.6 final? If not, is there any document that describes the changes applications will have to make, and does this not spoil Tcl/Tk's great backward compatibility.

  /Ashok


tkt_uuid: 3584471fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.5.13
resolution: Fixed
title: `make dist` fail
comment:
  Cannot make a Tk 8.5.13 distribution due to failure
  of the `make dist` target:

  mkdir /tmp/dist/tk8.5.13/macosx
  cp -p /home/dgp/fossil/tk8.5/unix/../macosx/GNUmakefile /home/dgp/fossil/tk8.5/unix/../macosx/README \
                  /home/dgp/fossil/tk8.5/unix/../macosx/Tk.* /home/dgp/fossil/tk8.5/unix/../macosx/*.[ch] \
                  /home/dgp/fossil/tk8.5/unix/../macosx/*.in /home/dgp/fossil/tk8.5/unix/../macosx/*.ac \
                  /home/dgp/fossil/tk8.5/unix/../macosx/*.xcconfig /home/dgp/fossil/tk8.5/unix/../macosx/*.sdef \
                  /home/dgp/fossil/tk8.5/unix/../macosx/configure /tmp/dist/tk8.5.13/macosx
  cp: omitting directory `/home/dgp/fossil/tk8.5/unix/../macosx/Tk.xcode'
  cp: omitting directory `/home/dgp/fossil/tk8.5/unix/../macosx/Tk.xcodeproj'

  Looks like some kind of Cocoa backport confusion over
  whether macosx subdirs are named Tk.xcode* or Wish.xcode*.

  I imagine I can eventually puzzle it out, but I assume this is easy
  for those immersed in the xcode machinery.


tkt_uuid: 3584830fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: ttk::entry fails with not-yet-set -textvariable
comment:
  package require Tk
  pack [entry .e -textvariable yourtext] -expand yes -fill x
  pack [button .b -command Doit -text "Press"]
  proc Doit {} {
    variable yourtext
    tk_messageBox -message "You pressed, text is $yourtext"
  }

  Runs as expected, but the same script with ttk (as shown in the 
  example):

  package require Tk
  pack [ttk::entry .e -textvariable yourtext] -expand yes -fill x
  pack [ttk::button .b -command Doit -text "Press"]
  proc Doit {} {
    variable yourtext
    tk_messageBox -message "You pressed, text is $yourtext"
  }

  Throws an error, if there is no text in the entry: 
  can't read "yourtext": no such variable
      while executing
  "tk_messageBox -message "You pressed, text is $yourtext""
      (procedure "Doit" line 3)
      invoked from within
  "Doit"
      invoked from within
  ".b invoke "
      invoked from within
  ".b instate !disabled { .b invoke } "
      invoked from within
  ".b instate pressed { .b state !pressed; .b instate !disabled { .b 
  invoke } } "
      (command bound to event)

  % info patchlevel
  8.5.11
  % parray tcl_platform
  tcl_platform(byteOrder)   = littleEndian
  tcl_platform(machine)     = x86_64
  tcl_platform(os)          = Linux
  ...


tkt_uuid: 3587262fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Width of menubutton too short on aqua with textvariable
comment:
  The attached code shows a bug in menubutton on MacOS (aqua): if I specify the font and use textvariable then the menubutton is displayed in a width that is far too narrow.

  I tried to work around it using update idletasks and had no luck.

  One workaround that does work is to change the font size in the option database and then change it back again. This causes an ugly display glitch but it's better than nothing.


tkt_uuid: 3588158fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 9 Immediate
foundin: obsolete: 8.5.13
resolution: Fixed
title: tk: NSApplicationPresentationAutoHideDock undeclared
comment:
  tk fails to upgrade from version 8.5.12 to 8.5.13 and returns the following errors building object tkMacOSXWm.o:
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: ‘NSApplicationPresentationAutoHideDock’ undeclared (first use in this function)
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: (Each undeclared identifier is reported only once
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: for each function it appears in.)
  .../tk8.5.13/unix/../macosx/tkMacOSXWm.c:6332: error: ‘NSApplicationPresentationAutoHideMenuBar’ undeclared (first use in this function)

  Version Information:

  Mac OS Version:
  ProductName:Mac OS X
  ProductVersion:10.5.8
  BuildVersion:9L31a
  Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

  Xcode Version:
  Xcode 3.1.4
  Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0
  BuildVersion: 9M2809

  See MacPorts ticket #37016 https://trac.macports.org/ticket/37016 for additional information.


tkt_uuid: 3588364fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
severity: Minor
foundin: current: 8.5.14
resolution: Fixed
title: Crash on Tk dll
comment:
  I'm try to build Python with mingw. It mostly all done except 64bit build where I got error on _tkinter module. I use mingw-w64 with gcc-4.7.2. I try various version of tcl/tk 8.5.11, 8.5.12, 8.5.13 but without success. On 32bit builds all fine It crash only on 64bit. I attach gdb backtrace. I find that python crash on module unload. Can you told me is it tcl/tk error or python error?


tkt_uuid: 3588460fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: -typevariable buggy in X11
comment:
  The -typevariable option is buggy in X11. According to TIP 242 the typevariable should hold the type as specified. This script:

  package require tcltest
  package require Tk

  puts [tk_getSaveFile -initialfile foo -typevariable seltype -filetypes {{TEXT *.txt}}]
  puts $seltype

  # behaviour before the patch
  # Win: TEXT
  # Tk/Carbon: TEXT
  # Tk/Cocoa: seltype is undefined
  # X11: TEXT (*.txt)
  #
  # after the patch
  # X11: TEXT

  gives the expected output under Win and Tk/Carbon. The modified result in X11 prevents the use case of switching on the value of typevariable. The attached patch fixes the problem for X11.


tkt_uuid: 3588462fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 2
foundin: None
resolution: None
title: -typevariable ignored in Tk/Cocoa
comment:
  Tk/Cocoa does not implement -typevariable. The UI controls for choosing the type are missing, and the typevariable is not touched. Under Carbon it worked. Native Cocoa applications like Pages demonstrate, that the same functionality is possible in Cocoa. 

  See the attached test script and also bug 3588460


tkt_uuid: 3588636fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: bg change fg sometimes in Aqua menus
comment:
  As of Tcl/Tk 8.5 the background option for menus affects the *foreground* color, not the background. Even stranger, it only affects the foreground color if foreground is not set. Once foreground is set the background is ignored.

  Here is demo code:

  tk_optionMenu .om var One Two Three
  pack .om
  .om.menu configure -bg "green"

  At this point observe that the menu has green foreground text (and the normal white background).

  .om.menu configure -fg "red"

  Now change the foreground and observe that the text takes on the desired foreground color.

  .om.menu configure -bg "green"

  Now change the background and observe that the new color is ignored.

  I doubt that the background color can be set on Aqua. If that is so, then please fix Aqua Tk so that menu ignores the background option. It should never be used to change the foreground color!


tkt_uuid: 3588936fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: tkUnixKey.c is wrong for me since 8.5.11
comment:
  Hi,
  on OSX, using unix like Tcl/TK .dylib, since 8.5.11 I cannot acces binding unless I hit a key first.
  with 8.5.13, if I copy/paste code from 8.5.10 tkUnixKey.c and recompile Tk, everything is fine but I doubt it's a good hack.
  here's the link to the discussion on comp.lang.tcl
  https://groups.google.com/d/msg/comp.lang.tcl/8bHk1QKGjFA/ukrgsAQps2QJ

  Best regards,
  Nicolas


tkt_uuid: 3592454fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: sash for hidden pane still draggable with weird effects
comment:
  As posted on comp.lang.tcl:

  panedwindow .p ; pack .p -expand yes -fill both
  foreach num {1 2 3} { button .$num -text $num }
  .p add .1 .2 .3 -stretch first
  .p paneconf .3 -hide 1

  The sash between buttons 2 and 3 is still one pixel wide. gettign the mouse
  there will show the resize-cursor.  The effect of clicking & dragging it seems
  to depend on the window-manager and on whether the toplevel was manually
  resized by the user.  If the latter, then dragging the sash magically dragged
  the other sash towards the hidden pane. Otherwise it causes the toplevel to
  be resized (but only shrunk, never grown, thus still weird).


tkt_uuid: 3592736fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 29. Colormaps and Visuals
priority: 7 High
foundin: obsolete: 8.5.13
resolution: Fixed
title: color #909090909090 shows pink on win mingw
comment:
  I have two tcl/tk 8.5.13
  a) compiled by msvc6
  b) Starpack kbsvq8.5.13-gui.exe by René Zaumseil
      This is mingw compiled

  I start both and enter in the console:

  pack [label .l -bg #909090909090] -fill both -expand true

  on a) I get a grey box as expected
  on b) I get a red box. The displayed color value is: #ff9090

  I tried it also with 8.5.12:
  http://sourceforge.net/projects/kbskit/files/kbs/0.4.3/WindowsNT_kbsv...
  -> same funny color.

  and with ActiveState 8.5.12 wish, which does not have the bug.

  My box: Windows Vista 32 bit GER

  clt thread:
  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/578ac55c2aebe643#


tkt_uuid: 3593334fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: checkbutton bitmap via config not highlighted on Aqua
comment:
  On Aqua I observe that the behavior of checkbuttons and radiobuttons that use bitmaps is correct if the bitmap is supplied at creation, but not if supplied via config later. Here is test code that demonstrates the issue for checkbutton.

  checkbutton .b
  checkbutton .c -bitmap question
  pack .c
  .b config -bitmap question
  pack .b

  In the test code below observe that the top button changes appearance when checked and the bottom one does not. Also, the bottom button is smaller and appears to be missing its border  (which maybe part of the problem, but does not explain everything, since the top button turns gray all over when pressed).

  Note that on Aqua the indicator is not shown if the button is a bitmap (unlike on unix), so the bitmap needs to change appearance to indicate the state of the button.


tkt_uuid: 3594478fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: HAVE_VSSYM32_H not known in nmake build
comment:
  The define to choose between tmschema.h and vssym32.h in ttkWinXPTheme.c is not working when building with nmake. HAVE_VSSYM32_H is set from the configure script, not from makefile.vc.

  A solution would be to select on compiler version:

  #if defined(HAVE_VSSYM32_H) || _MSC_VER > 1500
  #   include <vssym32.h>
  #else
  #   include <tmschema.h>
  #endif


tkt_uuid: 3595620fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Works For Me
title: tkMacOSXWindowEvent.c and tkMacOSXWm.c compilation
comment:
  tkMacOSXWindowEvent.c  has multiple compile warnings; tkMacOSXWm compile fails.  Trying to build on ppc G5 with osx 10.5.8.


tkt_uuid: 3598564fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: wm maxsize does not take into account task bar on Windows 7
comment:
  On my Windows 7 box with a 768px screen, wm maxsize returns 750. This does not take into account the size of the task bar, which means that natural height of windows can be more than the \"usable\" screen height, making the window appear _behind_ the task bar (see screenshot).

  This problem is visible e.g. when one widget has a fixed height, but the one stacked below it does not. In that case, the window\'s natural size should be limited to the usable screen size so that it stops right above the task bar. What happens at the moment is that the second widget, which has no fixed size, only shrinks when the window would exceed the value of \"wm maxsize\". This example (used in the screenshot) illustrates the problem:
  toplevel .w
  text .w.t1 -height 25
  text .w.t2
  grid .w.t1
  grid .w.t2
  update
  wm geometry .w
  wm maxsize .w

  (Just change \"-height 25\" so that the first text box takes the most part of your screen\'s height.)


  This problem also happened with Tk 8.5. I have not tested this under Windows 7 SP1 (upgrade bug).


tkt_uuid: 3598664fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: OS X: libtk8.6.dylib install_name invalid path in unix build
comment:
  When using the "unix" build (ie, X11, rather than Quartz) on OS X, at least when building with MacPorts, the configure script and Makefile supplied with 8.6.0 results in stamping an invalid search-path like path name for libtk8.6.dylib into the dynamic library as the "install_name" (ie, canonical pathname for the library), which then gets copied into the wish8.6 executable as the location from which to load the library.  Since the search-path style string is not a valid file pathname, the library can't be found and hence the wish8.6 executable cannot be loaded.  This behaviour seems to be new since 8.5.13, although the underlying cause may have been there for quite some time.

  Symptoms:

  When trying to run something that uses wish:

  dyld: Library not loaded: /opt/local/lib:/opt/local/lib/libtk8.6.dylib
    Referenced from: /opt/local/bin/wish
    Reason: image not found

  and inside the files:

  ewen@bethel:~$ otool -D /opt/local/lib/libtk8.6.dylib
  /opt/local/lib/libtk8.6.dylib:
  /opt/local/lib:/opt/local/lib/libtk8.6.dylib
  ewen@bethel:~$

  ewen@bethel:~$ otool -L /opt/local/bin/wish8.6 | grep libtk
          /opt/local/lib:/opt/local/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.0)
  ewen@bethel:~$

  Based on the MacPorts trouble ticket investigation:

  https://trac.macports.org/ticket/37395

  the fundamental problem is that DYLIB_INSTALL_DIR is used directly as part of the "install_name" for the OS X dylib, but the supplied Makefile.in copies that directly from LIB_RUNTIME_DIR which the configure script (now?) assembles into a library search path.  (It seems to me that LIB_RUNTIME_DIR is misnamed, if it is being treated as a RPATH-style search path.)  The most immediate trigger seems to be adding the X11 library location to the existing LIB_RUNTIME_DIR path (containing ${libdir}), but I'm not sure if that's new in the tk configure script or just being triggered now.

  The easiest work around, proven to work in MacPorts, is to set DYLIB_INSTALL_DIR from ${libdir} instead of from ${LIB_RUNTIME_DIR}:

  -DYLIB_INSTALL_DIR       = ${LIB_RUNTIME_DIR} 
  +DYLIB_INSTALL_DIR       = $(libdir) 

  (see patch being carried by Macports: https://trac.macports.org/browser/trunk/dports/x11/tk/files/patch-unix-Makefile.in.diff?rev=100816)

  Ewen

  PS: I'm not sure if this is "Mac OS X Build" or the "Unix Build", since it is the legacy unix/X11 handling on OS X which has the problem not the new Quartz handling.  But OS X is the only platform I'm aware of that uses this "install_name" canonical path stamping approach, so I went with that.  Feel free to change as appropriate.


tkt_uuid: 3598814fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Invalid
title: Invalid kern table error for 'font metrics'
comment:
  Mac OS X 10.7.5 and 10.8.2

  If you have the Microsoft Word 2011 font called "Bauhaus 93" and you execute this script:

       foreach family [lsort -dictionary [font families]] {
       font create TempFont -family ${family}
       if {[font metrics TempFont -fixed]} {
          puts $family
       }
       font delete TempFont
       }

  You will get this error:

       2012-12-28 18:30:53.879 Wish[18563:507] CoreText: Invalid 'kern' Table In CTFont <name: Bauhaus93, size: 13.000000, matrix: 0x0>
       CTFontDescriptor <attributes: <CFBasicHash 0x4001ffca0 [0x7fff7bed1fa0]>{type = mutable dict, count = 1, entries =>
       2 : <CFString 0x7fff7c552b38 [0x7fff7bed1fa0]>{contents = "NSFontNameAttribute"} = <CFString 0x400946f00 [0x7fff7bed1fa0]>
       {contents = "Bauhaus93"}}>

  tk/wish appears to be version 8.5 based on this line in /usr/bin/wish:

       "$(dirname $0)/../../System/Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish" "$@"


tkt_uuid: 3599312fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Fixed
title: First Alt key event is lost - Fix
comment:
  I'm seeing this problem on Solaris 10, but it may apply to other X11
  systems with Input Methods enabled.

  Immediately after starting a wish application, if the first
  keyboard input is an Alt sequence (e.g. to open a menu) then that
  key binding doesn't work.

  The following wish script demonstrates the problem:

      bind . <Alt-KeyPress> {puts "Alt-KeyPress %K"}
      focus -force .

  Start wish with the above script.  Type Alt+f.  The binding is
  not fired.  Enter Alt+f again and the binding works.  Similarily
  if another key is entered before the first Alt sequence, then it
  works.

  The problem is in TkpGetKeySym in unix/tkUnixKey.c. Use of input
  methods short-cuts the code to find a keysym, and prevents
  TkpInitKeymapInfo being called on the first event.
  TkpInitKeymapInfo must be called to setup dispPtr->altModMask for
  the bindings to be matched correctly.

  A minor reorganisation of the code to ensure TkpInitKeymapInfo is
  called fixes the problem, as attached.


tkt_uuid: 3599928fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Fixed
title: Tk 8.5.13 fails to build on Solaris 5
comment:
  Recently Tk switched from using XKeycodeToKeysym to XkbKeycodeToKeysym, defined in X11/XKBlib.h. However, that header file is not available on Solaris 5 and as a result Tk fails to build on this platform.

  The availability of X11/XKBlib.h should be checked by configure, and an appropriate fallback should be used if the header file is not available.


tkt_uuid: 3601604fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: [listbox $path -takefocus 0] steals focus
comment:
  The listbox manpage says it will take focus on <1> if the widget -state is normal and -takefocus is 1. However, it always takes focus, regardless of the -takefocus option.

  The binding for <1> on Listbox should be something like

    bind Listbox <1> {    if {[winfo exists %W]} { tk::ListboxBeginSelect %W [%W index @%x,%y] [string is true [%W cget -takefocus]] }}

  (Currently, where I have [string is true [%W cget -takefocus]] it just has 1.)


tkt_uuid: 3602534fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 4
foundin: None
resolution: Fixed
title: XScreensaver test pollutes XLIBSW variable
comment:
  The XLIBSW variable is used for a few tests and the XScreensave tests might alter it.
  Easiest fix is to do the XScreensaver tests last.
  Ok?


tkt_uuid: 3602901fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: Documentation of ttk::frame -padding
comment:
  If I believe http://www.tkdocs.com/tutorial/widgets.html, the documentation does not specify that it is possible to use multiple values ​​to determine the padding of a ttk::frame widget.

  I propose to add the following details to ttk_frame.n manpage:

   - a single number specifies the same padding all the way around;
   - a list of two numbers lets you specify the horizontal then the vertical padding;
   - a list of three numbers lets you specify the left, vertical, and right padding, in that order;
   - a list of four numbers lets you specify the left, top, right and bottom padding, in that order.


tkt_uuid: 3603077fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: current: 8.6.0
resolution: Fixed
title: ttk::treeview doesn't update display when tags are changed
comment:
  On Windows, a ttk::treeview's display isn't updated when tags are added are removed - you have to move the cursor into (or out of) the treeview for the display to update. Example:

  pack [ttk::treeview .t]
  foreach x [list Foo Bar Baz] {
    .t insert {} end -id $x -text $x
  }
  .t tag configure tagged -foreground yellow -background red
  .t tag add tagged Foo
  .t tag has tagged Foo

  The final command returns 1 as expected, but nothing happens until you move the mouse over the treeview, when suddenly the colors change. Calling [update] doesn't help. 

  Setting an option for the widget does cause it to be automatically redrawn, so in my case I'm doing a no-op like
  .t configure -cursor [.t cget -cursor]
  immediately after changing tags, as a temporary workaround.


tkt_uuid: 3603396fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: ttk::sizegrip doesn't use native bindings
comment:
  The bindings on a [ttk::sizegrip] use Tcl procs which resize the window in real time as the mouse is moved. However, on Windows (depending on OS settings) normal behaviour is usually to show a grey bounding box for the window, which resizes on mouse motion, and only resize the window on button release. (Pressing escape while dragging cancels the operation.) It would be nice if this native behaviour could be included in ttk on Windows to get a truly native look and feel.


tkt_uuid: 3603397fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk::sizegrip should be hidden for maximised windows
comment:
  On MS Windows, the sizegrip should be hidden when the toplevel it's a part of is maximised. This is the default behaviour in all other Windows apps which have a sizegrip. (I can't speak for other OSes/window managers, but it seems more sensible to me in all cases.)

  Failing that, it should at least do nothing (and preferably not change the cursor, either) when the window is maximised - it's very weird that, when the window is maximised, you can drag the sizegrip to alter the size the window will have when deiconified.


tkt_uuid: 3603738fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: menus can't post if application is not in foreground
comment:
  A popup menu causes an error if you try to post it while another application is in the foreground.

  test code:
  menu .pm 
  .pm add command -label test
  bind . <Button-2> "tk_popup .pm %X %Y"

  works fine if Wish is in the foreground.
  If you click on any other application, then right-click on the Wish window (while leaving it in the background) an error is thrown on the .pm post command.


tkt_uuid: 3604758fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: cocoa <Mousewheel> event incorrect %x %y substitutions
comment:
  The cocoa 8.6.0 is returning incorrect %x and %y substitutions.
  It is returning the value relative to the parent of the window, not relative to the window.

  test code:
  grid [label .my -textvariable mousey] -row 1 -column 1
  grid [label .wy -textvariable wheely] -row 1 -column 2
  grid [label .by -textvariable buttony] -row 1 -column 3
  grid [frame .f -width 150 -height 200] -row 2 -column 1 -columnspan 3
  bind .f <Any-MouseWheel> "set wheely %y"
  bind .f <Any-Motion> "set mousey %y"
  bind .f <ButtonPress> "set buttony %y"

  move the mouse in the frame to see the correct %y substitution.
  press the button to see that it is returning the same value.
  move the mouse wheel and see that it's not correct.
  % x substitution has the same problem.


tkt_uuid: 3605283fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: Fixed
title: ttk::entry xview end
comment:
  The Ttk entry widget does not accept the index "end" in its xview command.
  Perhaps this affects all ttk widgets.


tkt_uuid: 3607200fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Cocoa/Carbon/OSX: variant keyboard events
comment:
  It is helpful when building an application for distribution if Tk behavior is the same for all variants of the same platform.  Any reduction of differences is beneficial.

  I am comparing Tk/Aqua/Cocoa 8.6 trunk and core-8-5-branch, with the Tk/Aqua/Carbon 8.5.9 shipped with Mountain Lion, and also with Tk/Aqua/Carbon 8.5.11 built on Tiger and running on either Mountain Lion or Tiger.

  Items (1), (2), (3) are differences between keyboard events in Tk/Aqua/Cocoa and those in Tk/Aqua/Carbon.

  Item (4) is a dependence on the runtime version of OS X.

  Item (5) is a dependence on the build version of OS X.

  Cf. documentation for Aqua/Carbon keyboard modifiers at http://wiki.tcl.tk/28331

  Every platform has small differences, so it is a matter of opinion whether items (2) and (3) below are "bugs" or "features".  I believe they should be considered bugs, because this Tk/Aqua/Cocoa behavior differs from that of Tk/Aqua/Carbon.

  ====

  Differences between keyboard events in Tk/Aqua/Cocoa and those in Tk/Aqua/Carbon.

  (1) BAD REPORTED KEYSYM FOR MODIFIER KEYS
  The value of %K for modifier keys (other than Caps_Lock) is reported as "??", rather than the values "Shift_L" etc used in non-Aqua platforms.  This bug is also found in recent combinations of Tk/Aqua/Carbon and OS X build platform (but not in older combinations, e.g. 8.5.11 built on Tiger and running on Mountain Lion).

  (2) NO REPORTED MODIFIER FOR ALT KEY
  The Option modifier generated by the "alt" key is intercepted by the operating system, which modifies the character (and hence the values of %K and %A).  The event is a <KeyPress>, whereas in Tk/Aqua/Carbon it is an <Option-KeyPress>.

  The "Option" modifier is correctly reported if an event also uses the Command or Control modifier. 

  (3) NO REPORTED MODIFIERS FOR SHIFT AND SHIFT-LOCK
  Holding down the shift key and pressing "s" produces the event <KeyPress> with %K equal to "S".  On other platforms it produces the event <Shift-KeyPress> with %K equal to "S".

  Pressing the "Shift Lock" key and then pressing "s" produces the event <KeyPress> with %K equal to "S".  On other platforms it produces the event <Lock-KeyPress> with %K equal to "S".

  Pressing the "Shift Lock" key, then holding down the shift key and pressing "s" produces the event <KeyPress> with %K equal to "S".  On other platforms it produces the event <Shift-Lock-KeyPress> with %K equal to "s".

  However, the "Shift" and "Lock" modifiers are correctly reported (as they are on other Tk platforms) if an event also uses the Command or Control (but not the Option) modifier. 

  Notes on (3):
  - (a) Conventionally, "Shift Lock" is not reversible by Shift on the Mac.
  - (b) It might be considered a "feature", not a "bug", of Tk on the Mac that the operating system and Tk fully interpret the Shift and Lock keys, and pass the script the appropriate symbol as %K and %A without conveying information about the Shift and Lock modifiers.
  - (c) The opposing arguments, that this is a "bug", not a "feature" are:
  --    (i) non-Mac platforms also do this interpretation of the Shift and Lock modifier keys (though in a different way from the Mac, see (a)) AND ALSO tell the application whether the modifiers Shift and Lock have been applied;
  --    (ii) Tk/Aqua/Carbon does the same as Tk on non-Mac platforms: therefore the change made in Tk/Aqua/Cocoa, even if it is considered desirable, is a change of behavior made at a patch level revision of Tk/Aqua.

  ====

  Dependence on the runtime version of OS X.

  (4) GRATUITOUS MODIFIER FOR NON-PRINTING, NON-NUMERIC-KEYPAD KEYS
  This applies to a Cocoa binary built and executed on Mountain Lion, and to a Carbon binary built on either Tiger or Mountain Lion and executed on Mountain Lion.

  The keys {Next Prior Home End Delete Help Clear}, and F1 to F16 (except when intercepted by the operating system), are reported as <M4-KeyPress>, not as <KeyPress> (which is the behavior for a Carbon binary built and executed on Tiger).

  The keys {Up Down Left Right} are reported as <M4-KeyPress>, not as <M3-KeyPress> (which is the behavior for a Carbon binary built and executed on Tiger).

  (For comparison: all versions of Mac OS X and Tk/Aqua report the modifier M3 for keys in the numeric keypad, except the Clear key).

  ====

  Dependence on the build version of OS X.

  (5) REPORTED UNICODE CHARACTER %A FOR NON-PRINTING KEYS
  The keys {Next Prior Home End Delete Help Up Down Left Right Clear}, and F1 to F16 (except when intercepted by the operating system) generate a non-empty value for %A.  This value is a Unicode character in the private use area U+E000 to U+F8FF.

  This occurs for both Tk/Aqua/Carbon and Tk/Aqua/Cocoa binaries built and executed on Mountain Lion.

  On other platforms, and for Tk/Aqua/Carbon binaries built on Tiger and executed on Tiger or Mountain Lion, the behavior is different: %A is the empty string, or ASCII 127 for the Delete key.


tkt_uuid: 3607248fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Patch for Aqua keyboard/mouse bindings
comment:
  The patch fixes these three bugs:

  1. Removal of duplicate <<ContextMenu>> binding for misconfigured X servers.

  2. Correction of typo - "Control" had been used in place of "Command" in a few places.

  3. Allowance for the perversity of Mac keyboard bindings:

  (a) The following events fire in response to the obvious keystrokes:

    <Control-Key-f>
    <Lock-Control-Key-F>
    <Shift-Control-Key-F>
    <Shift-Lock-Control-Key-F>

    <Command-Key-f>
    <Lock-Command-Key-F>
    <Shift-Command-Key-f>
    <Shift-Lock-Command-Key-f>

  (b) Commands can be bound to the following distinct events, but they never fire:

    <Control-Key-F>
    <Lock-Control-Key-f>
    <Shift-Control-Key-f>
    <Shift-Lock-Control-Key-f>

    <Command-Key-F>
    <Lock-Command-Key-f>
    <Shift-Command-Key-F>
    <Shift-Lock-Command-Key-F>

  The relevant bindings in tk.tcl have been corrected.  Some other bindings have been changed, although this is not strictly necessary: some bindings without "Shift" are sufficiently general to capture the intended event, but by adding "Shift" the intention of the command is clearer.


tkt_uuid: 3607250fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: current: 8.6.0
resolution: Wont Fix
title: Duplicate events associated with Edit menu for Wish
comment:
  (1) The Wish binary has an "Edit" menu with entries for "Undo" and "Redo".  The "Redo" menu entry has a keyboard shortcut "Command-Y".  This should be replaced with the Apple standard shortcut adopted in Tk/Aqua 8.6, "Command-Shift-Z".

  (2) The menu entries for Undo, Redo appear to do something in addition to the bindings and events defined in tk.tcl.

  The keystroke "Lock-Command-Y" causes a <<Redo>> in a text widget, although it is not listed in [event info <<Redo>>], nor is it bound to a command in any of the widget's binding tags.

  The keystroke "Lock-Command-Z" causes a double <<Undo>>.

  If "Caps Lock" is not active, the widget behaves as expected.

  It appears that, when "Caps Lock" is active, the operations defined in the application menu are performed IN ADDITION TO any operations defined by Tk events and bindings.


tkt_uuid: 3607259fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: tag pixel range errors in Aqua/Cocoa
comment:
  The attached archive contains a script and a screenshot that demonstrate the bug.  Sorry about the tarball, Sourceforge only allows one file upload these days.

  The script tries to color a tagged range in a text widget.

  $text tag configure $tagName -foreground red

  For certain fonts, the range of pixels that are colored is about 5 pixels to the left of where it should be.  This is independent of any borders that the widget has.  In the demo script, the borders are set to 0.

  One font that behaves this way is {Courier New}, which is supplied with OS X.

  The screenshot image shows that the glyph positions agree with Tk's [$text bbox] measurements, and are consistent with a fixed-width font with width 11 pixels.

  $ /usr/local/tcl8.6/bin/wish8.6
  % source text-tag-colors2.tcl
  -ascent 15 -descent 5 -linespace 20 -fixed 1
  % font metrics {{Courier New} 18} 
  -ascent 15 -descent 5 -linespace 20 -fixed 1
  % 
  % .f.t bbox 1.0             
  0 0 11 20
  % .f.t bbox 1.1             
  11 0 11 20
  % .f.t bbox 1.2
  22 0 11 20
  % .f.t bbox 1.3
  33 0 11 20


  Most fonts do not exhibit this bug: the Courier, Menlo, and Monaco fonts are fine.  Apart from {Courier New}, I also have trouble with {DejaVu Sans Mono}, which is a TrueType font.

  The bug seems to occur only with Tk/Aqua/Cocoa; I do not see it on the 8.5.11 Carbon version of Tk, or on other platforms.  I don't see it in other applications either - e.g. TextEdit appears to be a Cocoa application, and can correctly color a range of {Courier New} text.


tkt_uuid: 3607262fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: current: 8.6.0
resolution: Duplicate
title: All forms of embedding fail on Cocoa
comment:
  I note bug 3033786 - Cannot embed Tk in a(nother) Cocoa Application.  The present bug is that toplevel embedding also fails when attempted in the same application.

  The following commands all fail in a similar way on Tk/Aqua/Cocoa:

  toplevel $top -use [winfo id [frame $fr -container 1]]

  ::safe::loadTk [safe::interpCreate $int]

  ::safe::loadTk [safe::interpCreate $int] -use [winfo id [frame $fr -container 1]]

  ::safe::loadTk [safe::interpCreate $int] -use [frame $fr -container 1]

  For example,

  $ /usr/local/tcl8.6/bin/wish8.6
  % safe::interpCreate bar
  bar
  % ::safe::loadTk bar
  The window ID 0x6311ff10 does not correspond to a valid Tk Window
  % set errorInfo
  The window ID 0x6311ff10 does not correspond to a valid Tk Window
      invoked from within
  "load {} Tk $slave"
      (procedure "::safe::loadTk" line 61)
      invoked from within
  "::safe::loadTk bar"

  The standard "Untrusted Tcl applet" container is drawn, but the toplevel "." associated with interpreter "bar" never appears.  The interpreter "bar" is left in an inconsistent state where Tk commands exist but cannot be evaluated.

  Combined with bug 3033786, this means that Tk can no longer be loaded into a Safe Base interpreter on the Aqua windowing system.


tkt_uuid: 3607336fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: Tk_Window object is equal to NULL
comment:
  Hello,
  I need some help to compile my project. I use Tcl 8.4.13 and Tk 8.4.13. 
  When I run my programm I have a core file. I read it with gdb and it's crashed at this line :
      Et_Display = Tk_Display(mainWindow);
  and when I print mainWindow :
  >> (gdb) print mainWindow
  $1 = (Tk_Window) 0x0

  Why this variable is equal to NULL ? 
  Thank you for your support.

  Sallem
   


tkt_uuid: 3607787fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: None
title: Expand [event info] to show which event(s) have a keysym
comment:
  Right now, there's no way to tell (short of looping over all event names) which events are bound to a keysym. To get "Select All" behaviour for Control-a, I have

    event add <<SelectAll>> <Control-a> <Control-A>

  in my app. What I didn't realise (as I develop on Windows) is that, on Linux, these keysyms are already added to <<LineStart>>. When someone reported that Control-a wasn't doing 'Select All', we had to guess and poke around to find what was happening. It would be helpful if

  event info <Control-a>

  which is currently invalid and returns an error would, instead, return a list of all events which have the keysym added.


tkt_uuid: 3607830fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 32. Key Symbols
priority: 9 Immediate
foundin: obsolete: 8.5.13
resolution: Fixed
title: XkbKeycodeToKeysym fails sometimes
comment:
  The XkbKeycodeToKeysym call cannot always be used if the X server does not support it.  A run time check is necessary before using this call.  If the X server does not support the extension, this call will return NoSymbol for some keys, depending on the particular server and keyboard setup.

  I have seen this behavior on different configurations, but I have not been able to determine exactly what's different about the setup.  However, in all cases, absence of the extension is true (test `xdpyinfo | grep XKEYBOARD` || echo bad) when the call fails.  Unfortunately, the inverse is not true, i.e., the xkb call does work in some cases where the extension is not present. 

  I'm currently working on a patch that will verify the existence of the extension first, when the Display is opened, and then use the appropriate (old or new) call as required.  If you think about it, this makes sense since the server is not necessarily on the build/installation machine, so this has to be a runtime decision, not a compile time decision.

  Please stay tuned...


tkt_uuid: 3608053fffffffffffffffffffffffffffffffff
type: RFE
status: Pending
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Allow tristate selection for ttk::checkbuttons
comment:
  At the moment, the only way to get a "tristate" appearance for a checkbutton is to manually unset the variable associated with the widget - it's impossible to get it by interacting with the widget. It would be nice if this was altered, either with
  -tristate <bool>
  which toggles whether clicking the checkbutton can put it into tristate mode (by unsetting the associated variable), probably the better way, or
  -tristate <value>
  which will toggle into tristate mode and set the variable to <value>. If -tristate isn't given, it would not be possible to click into tristate mode.

  When -tristate is given, clicking the checkbutton would toggle it from on -> off -> tristate -> on -> ... etc, rather than just on -> off -> on -> ...

  This would be useful for situations where something can be explicitly on, explicitly off, or ignored, for example when no input is given and the value should be checked on a parent instead.


tkt_uuid: 3608074fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: <<Invoke>> binding in lib/ttk/button.tcl
comment:
  In lib/ttk/button.tcl, there are two bindings (which are later copied to TRadiobutton and TCheckbutton as well):

  bind TButton <Key-space>{ ttk::button::activate %W }
  bind TButton <<Invoke>> { ttk::button::activate %W }

  <<Invoke>> is undocumented (it's not on the [event] manpage's list of Pre-Defined Events, or mentioned on the [ttk::button] manpage) - I'm not sure if this is an oversight, or if the binding is only there for backwards compatability or something. But it looks like it should probably either be removed, or should be documented (and the <Key-space> binding changed to [event add <<Invoke>> <Key-space>] so it's used).


tkt_uuid: 3608904fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: current: 8.6.0
resolution: Wont Fix
title: Aqua/Cocoa: deadlock when a menu accelerator posts a dialog
comment:
  On the Mac platform, the Cocoa version of Tk has the following bug.
  (Found on Snow Leopard 10.8.3 with Tk 8.5.13 or 8.6.0.)

  When a menu item is invoked by its keyboard accelerator, and that item posts a dialog, a deadlock ensues.  This appears to have something to do with Cocoa "flashing" the menu to indicate use of the accelerator: if the -accelerator option is not used, but the binding to the keyboard is defined (even with "$menu invoke $item"), there is no problem.  However, as a workaround this is unsatisfactory, because the accelerator is no longer indicated alongside the menu item.

  Another workaround - the menu command can be constructed to post the dialog after a delay.  This is unsatisfactory, because no delay can be guaranteed to be long enough to avoid the bug.

  The file is a script that demonstrates the bug.


tkt_uuid: 3608963fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: current: 8.6.0
resolution: None
title: Crash on MoutainLion with negative offset to wm geometry
comment:
  The following script crashes on MountainLion (10.8.3). It works on SnowLeopard and Lion (and other OS). 
  Used Tcl version is ActiveTcl 8.6.0. Crash report attached.

  package require Tk

  toplevel .top
  label .top.l -text "BallonHelp"
  pack .top.l

  #wm geometry .top [format "+%d+%d" -40 -40] ; # This works
  wm geometry .top [format "+%d+%d" -50 -50] ; # This fails  


tkt_uuid: 3609131fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Minor
foundin: None
resolution: Wont Fix
title: Aqua/Cocoa: deadlock when a menu accelerator posts a dialog
comment:
  Re: 3608904

  The deadlocked process is sometimes unkillable, and although it does not use much CPU or memory it retains a display and hogs the event loop, slowing down all other interactive applications on the machine (e.g. it takes a minute to open a terminal).  It can be terminated only by a reboot.

  I am sorry to create a duplicate bug for this; however comments have been disabled for 3608904 which makes it impossible to add this information there.

  IMHO "Wont Fix" bugs should not be closed or have comments disabled - if we are lucky someone else might provide useful information or even a fix.


tkt_uuid: 3609354fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: current: 8.6.0
resolution: Fixed
title: Tk crashes with zlib-less tcl on init
comment:
  InitPNGImage() calls Tcl_ZlibStreamInit() with a NULL interpreter.

  If Tcl was (accidentially in my case) configured without HAVE_ZLIB, that function does not check for a NULL interpreter when reporting an error and crashes. 


tkt_uuid: 3609608fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: Windows Text hi-lights disappear when text loses focus
comment:
  On Windows the text widget hi-lights will disappear when text widget loses focus.  Linux and Mac OS X Tk behaves appropriately.  This bug is generated from a number of bugs for IDLE (Python's IDE) here http://bugs.python.org/issue14146.  On Windows the IDLE debugger no longer hi-lights the current line in the editor.  On Windows the find/replace functions are not functioning properly because found text is not hi-lighted.  The issue was tested using Tk 8.5.13 and Tk 8.6 both exhibit the same problem.  We created a small test program to reproduce this bug with Python 3.x and tkinter:

  from tkinter import *

  main = Tk()
  text = Text(main, width=40, height=10, wrap="char")
  text.pack()
  text.insert(INSERT, "".join(map(str, range(100))))
  text.tag_add(SEL, "1.0", "end")
  text.focus_set()

  def jump():
      text.after(500, btn.focus_set)
      text.after(1000, text.focus_set)

  btn = Button(main, text="Click me", command=jump)
  btn.pack()
  main.mainloop()

  Thanks for your help!


tkt_uuid: 3609681fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: terminal loss of focus involving shortcuts and gitk/wish
comment:
  I recently reported this to gnome: https://bugzilla.gnome.org/show_bug.cgi?id=695561 . In some circumstances, when wish exits, keyboard events are no longer received/processed in the terminal window from which wish was started. (I described this as a "loss of focus", but I am not sure if window focus is the issue.)

  In gnome-shell, I can only reproduce with the wish application gitk. If I try to simplify gitk, the issue appears only sporadically (e.g. once in 10 times).

  But in fallback mode (gsettings set org.gnome.desktop.session
  session-name 'gnome-fallback') it can be reproduced easily and reliably by doing either one of:

  echo 'after idle { exit }' | wish
  echo 'bind . <Control-q> { exit }' | wish

  I failed to reproduce this with a small program doing XOpenDisplay, XCreateSimpleWIndow, XSelectInput, XMapWindow, XNextEvent, XCloseDisplay. What might Tk be doing differently?


tkt_uuid: 3609727fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 51. [place]
priority: 5 Medium
foundin: current: 8.5.14
resolution: None
title: place-14.1 fail - MEMLEAK!
comment:
  Testing a --enable-symbols=all build of Tk 8.5.14
  revealed that place-14.1 fails:

  ==== place-14.1 memory leak testing FAILED
  ==== Contents of test case:

      # Test all manners of forgetting a slave
      frame .f
      frame .f.f
      stress {
          place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
          place forget .f.f
      } {
          place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
          pack .f.f
      } {
          place .f.f -x [expr {1 + 1}] -y [expr {2 + 2}]
          destroy .f
          frame .f
          frame .f.f
      }

  ---- Result was:
  0 0 104
  ---- Result should have been (exact matching):
  0 0 0
  ==== place-14.1 FAILED

  This failure indicates a memory leak.

  Further testing revealed that 8.5.13 has the same
  leak.  Since this is not a regression, it will not
  block 8.5.14 release, but it's still a serious bug
  we should hunt down and kill.


tkt_uuid: 3609839fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: MouseWheel on Mac : wrong x y
comment:
  I noticed this strange behaviour on Mac (on Win it's OK):
  I'm working with ActiveTcl 8.5.13

  Let's take this simple case
    canvas .c -bg yellow
    pack .c -expand true -fill both -pady 50 -padx 50
    focus .c  ;# this is necessary on Windows ..
    #
    bind .c <Button-1>      { puts "B1 on %W  %x %y" }
    bind .c <MouseWheel> { puts "MW on %W  %x %y" }

  * On Windows
     Acting on B1 and on MouseWheel, you get the same coords (GOOD)
  * On MacOs
   Printed coords are different ! In particular if you click near the top-left corner you'll get something very close to (0,0) (good), but if you act on mousewheel you'll get something close to (50,50) !!


tkt_uuid: 3609871fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 74. Application Embedding
priority: 7 High
foundin: None
resolution: None
title: Tk 8.5.13 shall not complain about non-container widget
comment:
  Under Windows, Tk complains when using an external widget (via -use) and raises a dialog to allow the user to use/abandon the usage. This may be fine for the general case, but it is useless when Tk is used via th eTcl plugin. I am currently working on a massive update of the tcl plugin using TclTk 8.5.13+ in latest firefix/chromium/... browsers and this dialog is annoying. Here is a patch to fix the behaviour in win/tkWinEmbed.c:TkpUseWindow that avoids to open the dialog when Tk is run inside the plugin. The test is simple but works fine. 

      if (id == PTR2INT(hwnd)) {
  if (!SendMessage(hwnd, TK_INFO, TK_CONTAINER_ISAVAILABLE, 0)) {
          Tcl_AppendResult(interp, "The container is already in use", NULL);
      return TCL_ERROR;
  }
      } else if (id == -PTR2INT(hwnd)) {
  Tcl_AppendResult(interp, "the window to use is not a Tk container",
  NULL);
  return TCL_ERROR;
      } else {
  /* wke: perform check only when not in plugin! */
  if(!Tcl_GetVar2(interp,"plugin","patchLevel",TCL_GLOBAL_ONLY)) {
      /*
       * Proceed if the user decide to do so because it can be a legacy
       * container application. However we may have to return a TCL_ERROR in
       * order to avoid bug 1096074 in future.
       */
      
      char msg[256];
      
      sprintf(msg, "Unable to get information of window \"%.80s\".  Attach to this\nwindow may have unpredictable results if it is not a valid container.\n\nPress Ok to proceed or Cancel to abort attaching.", string);
      if (IDCANCEL == MessageBox(hwnd, msg, "Tk Warning",
         MB_OKCANCEL | MB_ICONWARNING)) {
  Tcl_SetResult(interp, "Operation has been canceled", TCL_STATIC);
  return TCL_ERROR;
      }
  }
      }


tkt_uuid: 3609872fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: None
title: Wrong handling of button events 8.5.13
comment:
  tkWinButton.c handles BN_CLICKED message. BN_SLIDER == WM_NULL and some browser (namely chromium) send a WM_NULL message periodically to check if the plugin is still alive. When using Tk via the Tcl plugin, this causes all buttons to fire regularly in a one-second interval. I have added an additional check in the event handler which avoids treatment of WM_NULL with 0 wParam/lParam as a button event in tkWinButton.c:ButtonProc. Without this modification, buttons are unusable in the Tcl/Tk plugin in some browsers since the command fire regularly without user interaction.

      case BN_CLICKED:
        /*
         * OOPS: chromium fires WM_NULL regularly to ping if plugin is still
         * alive. When using an external window (i.e. via th etcl plugin), this
         * causes all buttons to fire once a second, so we need to make sure
         * that we are not dealing with the chromium life check.
         */
        if(!(message == WM_NULL && wParam == 0 && lParam == 0)) {
    int code;
    Tcl_Interp *interp = butPtr->info.interp;
    
    if (butPtr->info.state != STATE_DISABLED) {
        Tcl_Preserve((ClientData)interp);
        code = TkInvokeButton((TkButton*)butPtr);
        if (code != TCL_OK && code != TCL_CONTINUE
    && code != TCL_BREAK) {
    Tcl_AddErrorInfo(interp, "\n    (button invoke)");
    Tcl_BackgroundError(interp);
        }
        Tcl_Release((ClientData)interp);
    }
    Tcl_ServiceAll();
    return 0;
        }


tkt_uuid: 3610491fffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Keyboard is ignored with SCIM
comment:
  This is a continuation of 905830 and, maybe, 1919791.
  If there is environment variable XMODIFIERS is equal to "@im=SCIM" and scim is running, then in quite often Tk ignores keyboard input.
  I am attaching a simple Tk testcase.  It fails with wish 8.4 and 8.5.  OS is Red Hat 5.3, desktop is Gnome.
  We had several ways to reproduce the problem, but I selected a shortest one, using tool tips.  I am attaching a script implementing tool tips that
  I found years ago and modified a little bit for us.
  To reproduce the problem:
  1) Find Gnome on Red Hat or possible other Linux.
  2) copy both files to any place.
  3) setenv XMODIFIERS "@im=SCIM"
  4) wish s.tcl
  5) move mouse to entry or text widget and wait till a tool tip appears
  6) try to type
  7) you may need to move mouse in and out the area to update tool tips.
  That's it.
  Clicking on other window and then back helps to restore input for a while.


tkt_uuid: 3610628fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: Notebook in Paned Window crashes app when closed
comment:
  Scid vs PC uses embeded toplevels inside notebook and panedwidnows.
  All wish-8.5 series code is fine, but 8.6.0 and todays (April 6) trunk
  crash when closing a panedwindow and/or notebook.Via keyboard bindings.

    svn co https://scidvspc.svn.sourceforge.net/svnroot/scidvspc
    cd scidvspc
  ./configure TCL_VERSION=8.6
   make install
   /usr/local/bin/scid
   press f2 twice

   X Error of failed request:  BadWindow (invalid Window parameter)
    Major opcode of failed request:  10 (X_UnmapWindow)
    Resource id in failed request:  0x3e00995
    Serial number of failed request:  34177
    Current serial number in output stream:  34182

  Sorry for the shitty bug report. I'm trying to find a testcase , but so far am unable.


tkt_uuid: 3611174fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 7 High
foundin: current: 8.6.0
resolution: None
title: Empty text items aren't found by "find enclosed"
comment:
  Empty text items aren't found by "find enclosed". Tcl/Tk 8.4.19 and 8.5.2 don't have the bug.
  Script:
  -----
  catch {console show}
  canvas .c
  grid .c
  puts [info patchlevel]
  set item [.c create text 100 100 -text "1"]
  puts "Enclosed: [.c find enclosed 0 0 10000 10000]"
  .c itemconfigure $item -text ""
  puts "Enclosed: [.c find enclosed 0 0 10000 10000]"
  -----
  Result:
  8.6.0
  Enclosed: 1
  Enclosed:


tkt_uuid: 3612022fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: wm_resizable is all or nothing
comment:
  With the Tk (and Python) that ship with Mountain Lion, preventing window resizing only works for both directions, if either with or height are true that call has no effect.


tkt_uuid: 3612814fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: font configure causes crash
comment:
  Using Tcl/Tk 8.5.13 I get a bus error (tested with OSX 10.6.2 and 10.8.3) if I type the following test lines:

  package require Tk
  font configure TkDefaultFont -size 10
  ttk::label .status -relief sunken
  menu .mbar
  menu .mbar.apple
  .mbar add cascade -menu .mbar.apple
  .mbar.apple add command -label hello
  . configure -menu .mbar
  font configure TkDefaultFont -size 12

  The console log shows amongst others:

  Thread 0 Crashed: Dispatch queue: com.apple.main-thread
  0 com.tcltk.tklibrary 0x000d333b TkpConfigureMenuEntry + 2251
  1 com.tcltk.tklibrary 0x00049948 MenuWorldChanged + 69
  2 com.tcltk.tklibrary 0x0001f05d RecomputeWidgets + 42
  3 com.tcltk.tklibrary 0x0001f069 RecomputeWidgets + 54
  4 com.tcltk.tcllibrary 0x001f5605 TclServiceIdle + 61
  5 com.tcltk.tcllibrary 0x001d79a3 Tcl_DoOneEvent + 342
  6 com.tcltk.tklibrary 0x0001d4c0 Tk_MainLoop + 37
  7 com.tcltk.tklibrary 0x0002b612 Tk_MainEx + 2041
  8 wish 0x00004590 main + 41
  9 wish 0x000044b9 start + 53

  The complete log file is attached. Tcl/Tk 8.5.9 worked fine.


tkt_uuid: 3613668fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 9 Immediate
severity: Minor
foundin: current: 8.6.0
resolution: None
title: XFilterEvent() hangs
comment:
  Starting with checkin

  http://core.tcl.tk/tk/info/2a535c6792

  we've started calling XInitThreads() as part of
  opening the first display in a process, which is
  meant to improve multi-threaded access to
  the X server.

  However, since then, the first call to XFilterEvent()
  in tclUnixEvent.c that has a Window argument with
  a value other than None will hang up the application
  hard.  It becomes non-responsive, and has to be
  killed.  Apparently a deadlock inside the Xlib brings
  things to a halt.

  Typically this is the first key press in the application
  that triggers the hang.


tkt_uuid: 3613675fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: canvText-17.1 is font sensitive
comment:
  canvText-17.1 fails on systems where a request
  for a {Courier 12 italic} font does not lead to something
  with the name matching */Courier-Oblique* getting
  put in the Postscript.


tkt_uuid: 3613759fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
severity: Important
foundin: current: 8.6.0
resolution: Fixed
title: ttk::entry and symbolic index names
comment:
  tt::entry .e
  .e xviwe end
  ==> expected integer but got "end"

  Doesn't seem right, because
  - the documentation say (or at least suggests), that should work
  - the tk entry works this way
  - other ttk::entry methods _do_ understand the symoblic index names


tkt_uuid: 3613977fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 3 Low
foundin: current: 8.6.0
resolution: None
title: Tk radiobutton missing an option
comment:
  Hi all,

  When radiobuttons are configured with -indicatoron false, the background color can be configured
  with -selectcolor, but there is no way to configure the foreground color, in the selected case.


tkt_uuid: 403047ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Allow multi-file select on Win9x as well
comment:
  The patch supplied is for tk/win/tkWinDialog.c

  With 8.4, the ability to select multiple files via
  the tk_getOpenFile was supposed to be allowed. I downloaded
  the latest sources and noticed that this was indeed
  done for WinNT but not for Win9x. As far as I can tell,
  the very EXACT changes also apply to the Win9x platform.

  So, I copied the logic from the WinNT side to the Win9x side
  and (made small changes to allow regular TCHAR strings).

  Since we are now allowing multiple files, I also increased
  the buffer size to be twice as big as MAX_PATH.

  I also noticed that in the Win9x side, we save and restore
  the current-working directory whereas on WinNT we do not.
  I do not know the reason for this (and I do not have
  access to a WinNT machine to see why). I did not modify this
  part since there may have been a good reason why the current
  working directory does not have to be saved and restored.

  I personally recommend doing the same thing for both platforms 
  so that the code for the two is as similar as possible.

  Regards,
  Haneef


tkt_uuid: 403327ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 27. Objects
priority: 5 Medium
foundin: None
resolution: Fixed
title: Better Obj-aware screen distances (Tcl Patch #102471)
comment:
  Sorry, I have overlooked something in
  the accepted Tcl Patch #102471 I submitted.

  The invariant of the old behaviour was, that every 
  MMRep had a valid string representation, therefor 
  updateStringProc was not needed. This is with my
  patch not the case any more. You can test this with

  > tclsh8.4
  load libtk8.4.so
  canvas .c
  pack .c
  set qx [expr {1.+1.}]   
  # qx has type double and no string representation
  .c scale all $qx 0 1. 1.
  # qx has now type MMRep and no string representation
  puts "qqq: $qx"

  result is:
  UpdateStringProc should not be invoked for type mm
  Aborted

  Therefor we need the updateStringProc. 

  Second there were build problems under Windows, because
  of the use of "&tclDoubleObj"

  Here is the new patch. Which, hopefully, is right
  now. It is against the original tk8.4a2 source.

  Peter


tkt_uuid: 403328ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Fix for Bug 229358
comment:
  I submitted this patch at the tcl project (#102472),
  but it belongs here. Can somebody please delete it at 
  the tcl project?

  This patch fixes the clipping of embedded canvas
  (see Bug #129358). 

  It works for me, but I'm not a postscript expert. Could someone with more knowledge please look, if this is the 
  right way and place to do it?

  Peter


tkt_uuid: 403660ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: Canvas man page update for coordinate lists
comment:
  A recent (8.3) change to the Tk canvas allows several commands to accepts a [list] of coordinates instead of individual x1,y1,x2,y2... values.  While this is a really great feature, it is not described in the canvas.n man page.  This patch adds a sentence to the COORDINATES section and new function prototypes illustrating the new syntax.


tkt_uuid: 404197ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 8
foundin: obsolete: 8.4a2
resolution: Fixed
title: unix/mkLinks bug: incorrect symlink
comment:
  The Tk_Offset.3 manpage is created twice by the mkLinks
  script.

  First, it is created as a symlink to the ConfigWidg.3
  manpage,
  and later on in the script it is created as a symlink
  to the SetOptions.3
  manpage.

  I'm not sure which of these two is the correct symlink,
  but the
  script should be fixed to only create one of these.


tkt_uuid: 404421ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 4
foundin: obsolete: 8.4a2
resolution: Fixed
title: allocing zero size images
comment:
  Following is a patch to eliminate zero size allocs
  for null images.  Without this patch, there is no-way
  to run BrowseX under the dmalloc memory checker
  as it craps out at these points.  I meant to submit
  these way back in 8.3.2 (same problem with bounds
  checking GCC), but never got around to it.

  Peter


  --- /a/tmp/tk8.4a2/generic/tkImgPhoto.c Mon Aug 21
  15:45:15 2000
  +++ ./tkImgPhoto.c      Sat Feb 17 21:50:07 2001
  @@ -2383,8 +2383,8 @@
          TkClipBox(masterPtr->validRegion, &validBox);
       }
   
  -    if ((width != masterPtr->width) || (height !=
  masterPtr->height)
  -           || (masterPtr->pix24 == NULL)) {
  +    if (((width != masterPtr->width) || (height !=
  masterPtr->height)
  +           || (masterPtr->pix24 == NULL)) &&
  (width*height)) {
   
          /*
           * Reallocate storage for the 24-bit image and
  copy
  @@ -2554,9 +2554,10 @@
          instancePtr->pixels = newPixmap;
       }
   
  -    if ((instancePtr->width != masterPtr->width)
  +    if (((instancePtr->width != masterPtr->width)
              || (instancePtr->height !=
  masterPtr->height)
  -           || (instancePtr->error == NULL)) {
  +           || (instancePtr->error == NULL))
  +           && (masterPtr->height * masterPtr->width))
  {
   
          newError = (schar *) ckalloc((unsigned)
                  (masterPtr->height * masterPtr->width *
  3 * sizeof(schar)));


tkt_uuid: 404703ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 1 Zero
foundin: None
resolution: Works For Me
title: TK_NO_SECURITY doesn't work (for me?)
comment:
  When building tk/8.3.2 I used the following in the
  Makefile.in:

  # To turn off the security checks that disallow
  incoming sends when
  # the X server appears to be insecure, reverse the
  comments on the
  # following lines:
  #SECURITY_FLAGS      =
  SECURITY_FLAGS    = -DTK_NO_SECURITY

  I assume this is supposed to 'shut off' xauth security
  checks when
  running wish scripts on X servers.  However I have
  always gotten the following message no matter what
  version of wish I build and on what platform:

  "Error: X server insecure (must use xauth-style
  authorization); command ignored."

  Is there something else I have to do when using
  -DTK_NO_SECURITY?  Or has this never been
  implemented/tested?  Are there any special instructions
  to building
  or installing 'unix/libtk8.3.so'?

  Thanks
  -Nick Oleksinski


tkt_uuid: 406317ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 27. Objects
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: MM type can lack string rep
comment:
  The code described at
  http://mini.net/cgi-bin/wikit/1329.html does not work
  with the CVS HEAD version of Tk, but rather panics with
  a complaint about how "UpdateStringProc should not be
  invoked for type mm".  A work-around is to force a
  particular variable to have a string representation,
  but this is not good in any case.  Instead, the problem
  should not occur in the first place.

  Suggested fix: write an updateStringProc for the MM
  type.


tkt_uuid: 406411ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 46. Unix Fonts
priority: 8
foundin: None
resolution: Fixed
title: Fix for iso10646 fonts in Unix.
comment:
  The test for "isTwoByteFont" in tkUnixFont.c was
  incorrect, leading to the wrong interpretation of the
  iso10646 unicode fonts.  The mappaing from that
  character set to the "unicode" encoding was also
  missing.  A good unicode font set is available at
  http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz


tkt_uuid: 409172ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: transient toplevel windows crash 8.3.2
comment:
  Initial Comment:
  The following short script crashes tcl/tk 8.3.2 under windows 98

  --- BEGIN SCRIPT ---
  update idletasks
  toplevel .foo
  # update idletasks ;#  <--  THIS WORKS AROUND
  # set z 0
  # button .foo.x -command {global z; set z 1;}
  # pack .foo.x
  wm transient .foo .
  tkwait variable z
  # exit
  --- END SCRIPT ---


  Setup:
  I have verified this crash under Windows 98 with tcl 8.3.2 and 8.4a2.  It does not crash 8.2.1.
  I have received reports that it also crashes under Windows 2000 and Windows ME using 8.3.2.

  Reproduction:

  Save the script to a file named "something.tcl" and double click on that file from explorer
  OR
  Create a shortcut that runs "c:\path\to\wish83.exe something.tcl" and click on that shortcut

  The crash only occurrs when this script is run directly via a shortcut or double-clicking a tcl file 
  directly;  starting the wish interpreter first and source-ing or pasting the script will NOT cause the 
  crash.  


  Expected result:
  As is, 2 windows should appear, one of which is transient.

  The commented out lines are necessary for the script to be sane, but not for the crash.

  Actual result:
  Windows popup saying  "This program has performed an illegal operation and will be shut down"

  Additional information:
  The indicated line will prevent the crash when uncommented.

  The indicated line prevents the crash from occurring.


tkt_uuid: 409566ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Out of Date
title: tcl/tk on MacOS-Japanese
comment:
  I can't start up WISH application.

  When start up, It display dialog with no text and 
  button.

  this is same result if I use OS started with no-
  extension( shift-key start up )

  environment:
     8500/G3-300 MacOS9.1(J)
     G3(B/W) 400 MacOS9.04(J)


tkt_uuid: 410389ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 56. [grab]
priority: 7 High
foundin: obsolete: 8.3.2
resolution: None
title: grab with multiple interpreter
comment:
  I am running an application with multiple interpreter.

  If I make a local grab on one window in an 
  interpreter, and I ask on another interpreter who is 
  grabbing, it reports the name of the window the other 
  interpreter is grabbing.
  This is creating a problem, particularly because the 
  menu posting, as is in the tk library file menu.tcl, 
  is looking for this and trying to remove the old grab 
  on an unexisting window


tkt_uuid: 411307ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: event generate can crash
comment:
  In tkBind.c:HandleEventGenerate handling of options -
  above, -root, -subwindow and -window make use of 
  NameToWindow to parse the window specification. 
  NameToWindow CAN return TCL_OK with a NULL tkWin 
  pointer (this happens when a window id is given which 
  does not refer to a Tk window). Unlike in the handling 
  of objv[0], however, the option handling core does not 
  check for this case.

  There should supposedly be a NameToWindowId helper 
  function anyway, since the returned Tk window pointer 
  is only used to look up the window id anyway in the 
  option handling code.

  The bug struck me when I tried to generate an event 
  from a binding, trying to forward %R with -root.


tkt_uuid: 411640ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: "space" directories/files and -multiple
comment:
  bash$ mkdir "/tmp/space dir"
  bash$ touch "/tmp/space dir/foo bar"
  bash$ touch "/tmp/space dir/spong wibble"
  bash$ wish8.4
  % tk_getOpenFile -initialdir {/tmp/space dir} -multiple
  1

  You cannot select a single space-containing filename
  using the above (but several files works, but you get
  odd values in the [entry] during the process...)


tkt_uuid: 411669ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 6
foundin: obsolete: 8.3.2
resolution: Fixed
title: <hpBackTab> in tk.tcl is fatal on HP-UX
comment:
  This is a re-submit of Tcl bug 232383 from Ken Martch
  (khmartch).  It's a Tk bug, so it belongs here.

  The <hpBackTab> Keysym in tk.tcl in the command
     event add <<PrevWindow>> <hpBackTab>
  causes a stack dump when running wish on HP-UX B.10.20.
  Changing the line to 
     event add <<PrevWindow>> <BackTab>
  allows wish to start without error.  However I have not
  verified if the
  intended function of the Keysym is correct.


tkt_uuid: 411781ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: \t causes trouble with justified text
comment:
  If \t is included in text that is center or right 
  justified (using tag configure -justify) the tab 
  characters appear on the screen as small rectangles - 
  of the style often used for unavailable characters.

  This occurs with Tk8.3 on windows (possibly others, I 
  don't know)

  This looks excessively yucky!

  I guess there are possible situations in which \t makes 
  no sense in justified text. In these cases I would 
  suggest the best course is not to write anything on the 
  screen for the \t character, and to raise an error 
  which could be processed or ignored using catch


tkt_uuid: 411893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Duplicate
title: font names returned as single chars
comment:
  In a statically linked TK application (built with TCL 
  PRO 1.4.1), on Windows/NT, font names returned by the 
  [font families] command consist only of the first 
  character of each name.

  I have debugged the code, and it appears that 
  TkpFontPkgInit is called before TkWinXInit; the latter 
  initialises the tkPlatformId variable which is used 
  indirectly by the former.  This all means that 
  systemEncoding does not get set on NT systems, and the 
  TkpGetFontFamilies function does not decode the font 
  list returned by NT correctly.


tkt_uuid: 412042ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 7 High
foundin: None
resolution: Fixed
title: increase file open -multiple capability
comment:
  THe current tk_getOpenFile -multiple is limited to 
  opening 260 bytes worth of data in the 
  format '<dir>\0<file1>\0<file2>\0...<fileN>\0\0'.  The 
  attached patch documents this better and increases 
  that amount to 260*20 (which allows for over 300 files 
  to be opened).


tkt_uuid: 412727ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: XIM Patch
comment:
  Re-registration of Tcl Patch 402391 from bitwalk
  (Keiichi Takahashi).  It patches Tk, not Tcl.
  It belongs here.


tkt_uuid: 413735ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: Test event-click-drag-1.2 fails
comment:
  On Solaris 8 (SunOS 5.8) with CDE:

  ==== event-click-drag-1.2  click and drag in an entry
  widget, this
                              tests tkEntryMouseSelect in
  entry.tcl  FAILED
  ...
  ---- Result was:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 4 {l/Tk
  selection}
  ---- Result should have been:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 2
  {Tcl/Tk selection}
  ==== event-click-drag-1.2 FAILED


tkt_uuid: 413904ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Fixed
title: entry-20.* cause invalid memory use
comment:
  Running the test suite with Electric Fence, I see
  invalid memory usage in the routine
  EntryValidateChange() when running tests entry-20.*.

  EntryValidate() frees entryPtr, but later code
  in EntryValidateChange() keeps right on using it.

  I see Tcl_Preserve() sprinkled here and there, which
  might solve the problem, except that DestroyEntry
  calls ckfree() instead of Tcl_EventuallyFree().

  There's a comment indicating this is intentional,
  but it still needs fixing. 


tkt_uuid: 413913ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4a2
resolution: Fixed
title: SIGSEGV in listbox-27.1
comment:
  Stack trace isn't helpful:

  Program received signal SIGSEGV, Segmentation fault.
  0x20000170f28 in _XFlushInt () from
  /usr/X11R6/lib/libX11.so.6
  (gdb) bt
  #0  0x20000170f28 in _XFlushInt () from
  /usr/X11R6/lib/libX11.so.6
  #1  0x20000170eb8 in _XFlush () from
  /usr/X11R6/lib/libX11.so.6
  #2  0x20000170eb8 in _XFlush () from
  /usr/X11R6/lib/libX11.so.6
  Cannot access memory at address 0x1202edffc

  After placing the "obvious" Tcl_Preserve() and
  Tcl_Release() calls in DisplayListBox():

  Program received signal SIGSEGV, Segmentation fault.
  0x12003b380 in Tk_FreeCursor (display=0x2000076f118,
  cursor=0x34000e8)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkCursor.c:526
  526         if (!dispPtr->cursorInit) {
  (gdb) bt
  #0  0x12003b380 in Tk_FreeCursor
  (display=0x2000076f118, cursor=0x34000e8)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkCursor.c:526
  #1  0x120039cb4 in FreeResources
  (optionPtr=0x12040d9c0, objPtr=0x0, 
      internalPtr=0x1204308a0 "è", tkwin=0x1203f9740)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkConfig.c:1608
  #2  0x1200399cc in Tk_FreeConfigOptions
  (recordPtr=0x120430790 "@\227? \001", 
      optionTable=0x12040d8e0, tkwin=0x1203f9740)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkConfig.c:1511
  #3  0x12007d704 in DestroyListbox (memPtr=0x120430790
  "@\227? \001")
      at
  /home/dgp/src/tk8.3/unix/../generic/tkListbox.c:1451
  #4  0x12018f990 in Tcl_Release (clientData=0x120430790)
      at ./../generic/tclPreserve.c:241
  #5  0x12007dee8 in DisplayListbox
  (clientData=0x120430790)
      at
  /home/dgp/src/tk8.3/unix/../generic/tkListbox.c:1778
  #6  0x12019b6cc in TclServiceIdle () at
  ./../generic/tclTimer.c:692
  #7  0x1201817a8 in Tcl_DoOneEvent (flags=34) at
  ./../generic/tclNotify.c:923
  #8  0x1200f8a60 in Tk_UpdateObjCmd
  (clientData=0x120370030, 
      interp=0x120319310, objc=2, objv=0x11fffdb50)
      at /home/dgp/src/tk8.3/unix/../generic/tkCmds.c:889
  #9  0x120185810 in EvalObjv (interp=0x120319310,
  objc=2, objv=0x11fffdb50, 
      command=0x1203fb8af "    update idle\n    winfo
  exists .l\n", length=36, 
      flags=0) at ./../generic/tclParse.c:932
  #10 0x120186424 in Tcl_EvalEx (interp=0x120319310, 
      script=0x1203fb840 "\n    destroy .l\n    pack
  [listbox .l]\n    update\n   
   .l configure -cursor xterm -xscrollcommand { destroy
  .l }\n    update idle\n   
   winfo exists .l\n", numBytes=147, flags=262144)
      at ./../generic/tclParse.c:1393
  #11 0x120115f60 in Tcl_EvalObjEx (interp=0x120319310,
  objPtr=0x120417df0, 
      flags=262144) at ./../generic/tclBasic.c:2580
  #12 0x120190d04 in Tcl_UplevelObjCmd (dummy=0x0,
  interp=0x120319310, objc=1, 
      objv=0x12031aa98) at ./../generic/tclProc.c:604
  #13 0x12014b63c in TclExecuteByteCode
  (interp=0x120319310, codePtr=0x1203fc260)
      at ./../generic/tclExecute.c:873
  #14 0x120116324 in Tcl_EvalObjEx (interp=0x120319310,
  objPtr=0x120405500, 
      flags=0) at ./../generic/tclBasic.c:2733
  #15 0x1201917b4 in TclObjInterpProc
  (clientData=0x1203ff8a0, 
      interp=0x120319310, objc=5, objv=0x11fffe990)
      at ./../generic/tclProc.c:1001
  #16 0x12017d03c in InvokeImportedCmd
  (clientData=0x120419480, 
      interp=0x120319310, objc=5, objv=0x11fffe990)
      at ./../generic/tclNamesp.c:1468
  #17 0x120185810 in EvalObjv (interp=0x120319310,
  objc=5, objv=0x11fffe990, 
      command=0x1203f63f6 "\ntest listbox-27.1 {widget
  deletion while active} {\n 
     destroy .l\n    pack [listbox .l]\n    update\n   
  .l configure -cursor xterm
   -xscrollcommand { destroy .l }\n    update idle\n   
  winfo exists .l\n} "..., 
      length=277, flags=0) at ./../generic/tclParse.c:932
  #18 0x120186424 in Tcl_EvalEx (interp=0x120319310, 
      script=0x1203e69c0 "# This file is a Tcl script to
  test out the \"listbox\" 
  command\n# of Tk.  It is organized in the standard
  fashion for Tcl tests.\n#\n# 
  Copyright (c) 1993-1994 The Regents of the University
  of California.\n"..., 
      numBytes=64331, flags=0) at
  ./../generic/tclParse.c:1393
  #19 0x120175508 in Tcl_EvalFile (interp=0x120319310, 
      fileName=0x12037a5d0 "./../tests/listbox.test")
      at ./../generic/tclIOUtil.c:323
  #20 0x1201298b4 in Tcl_SourceObjCmd (dummy=0x0,
  interp=0x120319310, objc=2, 
      objv=0x12031aa80) at ./../generic/tclCmdMZ.c:858
  #21 0x12014b63c in TclExecuteByteCode
  (interp=0x120319310, codePtr=0x1203cf350)
      at ./../generic/tclExecute.c:873
  #22 0x120116324 in Tcl_EvalObjEx (interp=0x120319310,
  objPtr=0x1203859f0, 
      flags=131072) at ./../generic/tclBasic.c:2733
  #23 0x12015ee64 in Tcl_RecordAndEvalObj
  (interp=0x120319310, 
      cmdPtr=0x1203859f0, flags=131072) at
  ./../generic/tclHistory.c:142
  #24 0x12015ec18 in Tcl_RecordAndEval
  (interp=0x120319310, 
      cmd=0x120326358 "source ./../tests/listbox.test\n",
  flags=131072)
      at ./../generic/tclHistory.c:62
  #25 0x12004a310 in StdinProc (clientData=0x120380310,
  mask=2)
      at /home/dgp/src/tk8.3/unix/../generic/tkMain.c:356
  #26 0x12016cecc in Tcl_NotifyChannel
  (channel=0x120380310, mask=2)
      at ./../generic/tclIO.c:6139
  #27 0x1201b7adc in FileHandlerEventProc
  (evPtr=0x12038f020, flags=-3)
      at ./../unix/tclUnixNotfy.c:624
  #28 0x120181160 in Tcl_ServiceEvent (flags=-3) at
  ./../generic/tclNotify.c:607
  #29 0x120181770 in Tcl_DoOneEvent (flags=-3) at
  ./../generic/tclNotify.c:910
  #30 0x12003d5e4 in Tk_MainLoop ()
      at
  /home/dgp/src/tk8.3/unix/../generic/tkEvent.c:1257
  #31 0x12004a11c in Tk_MainEx (argc=1, argv=0x11ffff448, 
      appInitProc=0x120025920 <Tcl_AppInit>,
  interp=0x120319310)
      at /home/dgp/src/tk8.3/unix/../generic/tkMain.c:285
  #32 0x1200258f8 in main (argc=1, argv=0x11ffff448)
      at /home/dgp/src/tk8.3/unix/tkAppInit.c:77

  So what is the non-obvious, correct fix?


