# ticket

tkt_uuid: ec7fa6bb5ce9f532853666639963399e1455fe06
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
severity: Minor
foundin: 8.6
resolution: None
title: Column and Row resize cursors could use better cursors
comment:
  Here's an example tree view widget:

  -----
  package require Tk
  ttk::treeview .tree
  .tree configure -columns "right"
  .tree heading #0 -text "left"
  .tree heading 0 -text "right"
  pack .tree
  -----

  On Win7 x64, when you try to resize the columns the cursor will change into the horizontal resize cursor (the same one as the one used for the edge of the window).

  However a more appropriate cursor is the horizontal /column/ resize cursor. There's also a row resize cursor as well on Win32. They're listed here:

  http://msdn.microsoft.com/en-us/library/windows/desktop/bb545459.aspx#concepts

  They're under the "Compound mouse interactions" table in the row labeled "Resizing", they're named "Row and column resize". They're the cursors used by default for column/row resize in most apps, e.g. Windows Explorer, uTorrent, etc.


tkt_uuid: ee40fd1fce8f2e407b25f158f3c079a52eedc2df
type: Bug
status: Open
subsystem: 54. [console]
priority: 5 Medium
severity: Minor
foundin: 8.5.14
private_contact: ebaa1541055af50f459f78f20fd039ce17a08b59
resolution: None
title: report error message in Tk_CreateConsoleWindow
comment:
  In Tk_CreateConsoleWindow(), if an error occurs in Tcl_Init(consoleInterp) or Tk_Init(consoleInterp), the error is not redirected to interp.

      if (Tcl_Init(consoleInterp) != TCL_OK) {
  	goto error;
      }

  must become:

      if (Tcl_Init(consoleInterp) != TCL_OK) {
  	Tcl_Obj *result_obj = Tcl_GetObjResult(consoleInterp);
  	Tcl_SetObjResult(interp, result_obj);
  	goto error;
      }


tkt_uuid: b83bea349f5e2c7057060610e7dc5432e79753f4
type: Bug
status: Pending
subsystem: 23. Option Parsing
priority: 5 Medium
severity: Minor
foundin: 8.6.1
resolution: None
title: config-2.1 regression
comment:
  Starting with commit

  http://core.tcl.tk/tk/info/aaf11bdce2

  I see test config-2.1 failing:

  ==== config-2.1 Tk_DeleteOptionTable - reference counts FAILED
  ==== Contents of test case:

      set x {}
      testobjconfig chain1 .a
      testobjconfig chain2 .b
      testobjconfig chain3 .c
      deleteWindows
      testobjconfig delete chain3
      lappend x [testobjconfig info chain2] [testobjconfig info chain1]
      testobjconfig delete chain2
      lappend x [testobjconfig info chain2] [testobjconfig info chain1]

  ---- Result was:
  {1 4 -three 2 2 -one} {2 2 -one} {} {1 2 -one}
  ---- Result should have been (exact matching):
  {3 4 -three 2 2 -one} {2 2 -one} {} {2 2 -one}
  ==== config-2.1 FAILED

  The commit changed the expected result of the test
  even though the results of the test body did not
  change.


tkt_uuid: 3574945fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 6
severity: Minor
foundin: None
resolution: None
title: Scrolling up with elided text doesn't play nice
comment:
  Create a basic text widget with some elided text, for example:

  pack [text .t -yscroll ".s set"] [scrollbar .s -command ".t yview"] -side left -fill y
  .t tag config hide -elide 1
  foreach x [list 0 1 2 3 4 5 6 7 8 9 0] {
    .t insert end "foo\nfoo\nfoo\nfoo\nfoo\nfoo\n"
    .t insert end "bar\nbar\nbar\nbar\nbar\nbar\n" hide
  }


  Then scroll the text a line at a time, either by clicking in the text widget and using the up/down arrow keys, or with

  .t yview scroll 1 unit
  .t yview scroll -1 unit

  The text scrolls down without any problem, but when scrolling up again, it pauses whenever it gets to an ellided line, causing the scroll action to have no visible effect. (tested on 8.5.9 and 8.6b1 on Windows XP and Win 7)


tkt_uuid: 2966299fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
severity: Minor
foundin: obsolete: 8.5.8
resolution: Invalid
title: Text Widget Tab key inserts wrong spacing
comment:
  in Text widget, using a monospace font like "courier new", after the first Tab width of a line, i.e. if Tab width is 8 characters then after the first 8 characters in a line, and/or you inserted characters equal or more than the tab width, no matter where you're standing if you insert a Tab and the preceding character was not a Tab the Tab spacing produced is a single space, this behaviour is not correct, if I'm standing exactly at the Tab width the spacing entered should be a full Tab's width not a single space, and if I am standing a character or more to the right of the Tab width a Tab should enter a spacing enough to make me stand at the next Tab Width of the Widget, this behavior can be proven to be wrong by being inconsistent with Vi, Vim, Emacs, Notepad, and even Firefox behavior, see the attached script for a live demonstration.
  this happens always on wish 8.5 and in wish 8.4 if you changed the tab width to the width of any no. of characters using the "font measure" command to acquire the width, I've included the second case in the demo with commented lines,


tkt_uuid: 27ea26d6661258e60381a89372a0b6e934ba7d3b
type: Bug
status: Open
subsystem: 18. [text]
priority: 4
severity: Important
foundin: 8.6.1
private_contact: a7e7367685096fac070c962aca70a4f5a8ccac9f
resolution: None
title: Segfault in wish on [text delete]: TkTextIsElided()?
comment:
  I get a segmentation fault when deleting text in a text widget under certain conditions.  Software environment:

  Tcl/Tk 8.6.1 (compiled from source), also happens on 8.5
  X.Org X Server 1.13.0
  Linux SBIS4079 3.5.0-22-generic #34-Ubuntu SMP Tue Jan 8 21:47:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

  I'm seeing the error in a text editor I'm building in Tcl/Tk, which uses the Tk text widget as its core.  The segfault occurs in the following scenario:

   1. Open a file containing more text than can fit on the screen, so that scrolling is possible.
   2. Scroll down a little in the text widget (using the scrollbar, mousewheel, or Page Down key; note that scrolling the viewport by moving the text insertion point alone does not appear to trigger the bug).
   3. Invoke a menu command to clear all the text (a typical File:New or File:Close operation)

  The segfault then occurs.  I will see what I can to to produce a minimal script that will reproduce this - as it stands, my editor codebase is getting a bit unwieldy, and I haven't been able to recreate the segfault condition in any of the small test cases I've tried so far (not surprisingly).

  From some tracing of the Tcl script, it seems the segfault is being triggered by a [text delete] operation, specifically:

  {.editor.text delete 1.0 end}

  (".editor" is simply a frame.)  Deleting less text also triggers the segfault.

  A gdb session implicates the TkTextIsElided function:

  Program received signal SIGSEGV, Segmentation fault.
  TkTextIsElided (textPtr=0x80d848, indexPtr=0x7fffffffc1c0, elideInfo=0x7fffffff9240) at /usr/local/src/tk8.6.1/unix/../generic/tkTextBTree.c:3533
  3533	    while ((index + segPtr->size) <= indexPtr->byteIndex) {

  I'm not using text elision in my editor (yet).  Note that the segfault apparently has something to do with the fact that the code is triggered from a menu -  the segfault does not happen if I perform the [text delete] from tclsh.

  Thanks!


tkt_uuid: 1449858fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.6b1.1
resolution: None
title: limit on inserted string size in an entry widget
comment:
  Try this in wish:

  set str [string repeat "0123456789" 4380]
  entry .e
  pack .e
  .e insert 0 $str


  Doing this I get after some amount of waiting an 
  entry widget packed in the . toplevel. Good.

  The problem is that the entry is apparently empty 
  (fully white).

  Selecting some area makes the selected characters 
  apparent, while unselecting them hides them again.

  Is there some (undocumented) limit in the length of 
  what can be inserted in an entry widget?

  Replacing 4380 by 4350 makes the string to be visible.

  I already found the tk_messageBox silently does not 
  open if the -message parameter exceeds some limit. 
  Maybe this limit is the same?

  Windows XP SP2, Tcl/Tk 8.5a4 or 8.4.12 as well.

  I have been told in the newsgroup that this limit 
  could have something to do with the font width. Some 
  limit in pixels number is probably silently hit.

  Moreover, still from the ng:
  On Mac OS 10.4.5 with tcl/tk 8.4.7 neither 4350 nor 
  4380 works, and indeed in either case the entry 
  appears to actually be *empty*, but it will not 
  accept any further input


tkt_uuid: 857686bb3dca4f3ada486fbaf7d9deaf9bf0cebb
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: a013af67114eccc19ad12b04f14923acea9e96b7
resolution: Fixed
title: textDisp-29.2.x tests fail
comment:
  Tests textDisp-29.2.x fail (identically) in core-8-5-branch and in trunk:


  ==== textDisp-29.2 miscellaneous: lines wrap but are still too long FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 +0+0
      text .t2.t -width 20 -height 10 -font $fixedFont  -wrap char -xscrollcommand ".t2.s set"
      pack .t2.t -side top
      scrollbar .t2.s -orient horizontal -command ".t2.t xview"
      pack .t2.s -side bottom -fill x
      .t2.t insert end 123
      frame .t2.t.f -width 300 -height 50 -bd 2 -relief raised
      .t2.t window create 1.1 -window .t2.t.f
      .t2.t xview scroll 1 unit
      update
      list [.t2.t xview] [winfo geom .t2.t.f] [.t2.t bbox 1.3]

  ---- Result was:
  {0.02 0.4866666666666667} 300x50+-1+20 {6 70 7 15}
  ---- Result should have been (exact matching):
  {0.023333333333333334 0.49} 300x50+-2+20 {5 70 7 15}
  ==== textDisp-29.2 FAILED



  ==== textDisp-29.2.1 miscellaneous: lines wrap but are still too long FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 +0+0
      text .t2.t -width 20 -height 10 -font $fixedFont  -wrap none -xscrollcommand ".t2.s set"
      pack .t2.t -side top
      scrollbar .t2.s -orient horizontal -command ".t2.t xview"
      pack .t2.s -side bottom -fill x
      .t2.t insert end 1\n
      .t2.t insert end [string repeat "abc" 30]
      .t2.t xview scroll 5 unit
      update
      .t2.t xview

  ---- Result was:
  0.009523809523809525 0.23174603174603176
  ---- Result should have been (exact matching):
  0.05555555555555555 0.2777777777777778
  ==== textDisp-29.2.1 FAILED



  ==== textDisp-29.2.2 miscellaneous: lines wrap but are still too long FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 +0+0
      text .t2.t -width 20 -height 10 -font $fixedFont  -wrap char -xscrollcommand ".t2.s set"
      pack .t2.t -side top
      scrollbar .t2.s -orient horizontal -command ".t2.t xview"
      pack .t2.s -side bottom -fill x
      .t2.t insert end 123
      frame .t2.t.f -width 300 -height 50 -bd 2 -relief raised
      .t2.t window create 1.1 -window .t2.t.f
      .t2.t xview scroll 2 unit
      update
      list [.t2.t xview] [winfo geom .t2.t.f] [.t2.t bbox 1.3]

  ---- Result was:
  {0.02 0.4866666666666667} 300x50+-1+20 {6 70 7 15}
  ---- Result should have been (exact matching):
  {0.04666666666666667 0.5133333333333333} 300x50+-9+20 {}
  ==== textDisp-29.2.2 FAILED



  ==== textDisp-29.2.3 miscellaneous: lines wrap but are still too long FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 +0+0
      text .t2.t -width 20 -height 10 -font $fixedFont  -wrap char -xscrollcommand ".t2.s set"
      pack .t2.t -side top
      scrollbar .t2.s -orient horizontal -command ".t2.t xview"
      pack .t2.s -side bottom -fill x
      .t2.t insert end 123
      frame .t2.t.f -width 300 -height 50 -bd 2 -relief raised
      .t2.t window create 1.1 -window .t2.t.f
      .t2.t xview scroll 7 pixels
      update
      list [.t2.t xview] [winfo geom .t2.t.f] [.t2.t bbox 1.3]

  ---- Result was:
  {0.02 0.4866666666666667} 300x50+-1+20 {6 70 7 15}
  ---- Result should have been (exact matching):
  {0.023333333333333334 0.49} 300x50+-2+20 {5 70 7 15}
  ==== textDisp-29.2.3 FAILED



  ==== textDisp-29.2.4 miscellaneous: lines wrap but are still too long FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 +0+0
      text .t2.t -width 20 -height 10 -font $fixedFont  -wrap char -xscrollcommand ".t2.s set"
      pack .t2.t -side top
      scrollbar .t2.s -orient horizontal -command ".t2.t xview"
      pack .t2.s -side bottom -fill x
      .t2.t insert end 123
      frame .t2.t.f -width 300 -height 50 -bd 2 -relief raised
      .t2.t window create 1.1 -window .t2.t.f
      .t2.t xview scroll 17 pixels
      update
      list [.t2.t xview] [winfo geom .t2.t.f] [.t2.t bbox 1.3]

  ---- Result was:
  {0.02 0.4866666666666667} 300x50+-1+20 {6 70 7 15}
  ---- Result should have been (exact matching):
  {0.056666666666666664 0.5233333333333333} 300x50+-12+20 {}
  ==== textDisp-29.2.4 FAILED


tkt_uuid: 3501372fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 29. Colormaps and Visuals
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: Rejected
title: Washed out colors on Mac OS X display
comment:
  While building a Tk app in Python on Mac OS X 10.7.3, I noticed the colors appear consistently "washed out" as if there is some sort of bad gamma correction going on under the hood. As a test, I write a very simple app that draws 1-pixel-high rectangles to a canvas with varying levels of intensity on each of the RGB channels, creating a black-to-white gradient.

  Second, I created a black-to-white gradient in GIMP to use as a baseline. When placed side-by-side, it's pretty clear that Tk is adjusting colors incorrectly.

  I've tried the same test on Linux, and it appears to work correctly, displaying the same exact gradient as generated by GIMP. I have also tried updating ActiveTcl and Python on OS X, but the problem persists. I'm now using python.org Python 2.7.2, and ActiveTcl 8.5.11.1.

  Attached is a PNG that illustrated the difference between the Tk gradient and the GIMP gradient, as well as the Python source I used to generate the Tk gradient.


tkt_uuid: e814c2fe0d3af4284aea6eeada8805fcb403e359
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Severe
foundin: 8.5.14
private_contact: a7673d7774a7264840c8898b901228c171b16b73
resolution: Fixed
title: Crash in Aqua Tk due to menus
comment:
  A Mac application I distribute crashes whenever anyone tries to change font size, using Tcl/Tk 8.5.12 - 8.5.14 and MacOS X 10.8 (and likely earlier versions as well). I do not see the bug with 8.5.11 so I distribute that with my application.

  I was finally able to create a simple test case, which I am pasting in below. I also see the crash if I make the "Something" menu item a command that changes the font size (and then select that menu item). My application crashes if the user changes some other preferences, including a color in the option database. So far it appears that I only see the crash if I touch the apple menu.

  To see the crash run the following code and push the button.

  # tcl menu crash
  menu .parentMenu
  menu .parentMenu.apple -tearoff 0
  # the following line is optional, but shows the menu is created
  .parentMenu.apple add command -label "Something"
  .parentMenu add cascade -label Wish -menu .parentMenu.apple

  font create testFont
  option add "*Button.font" testFont

  button .btn -text "Change Font" -command { font configure testFont -size 20 }
  pack .btn

  . configure -menu .parentMenu


tkt_uuid: 3417012fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: Segfault if [scale]'s -digits parameter value too large.
comment:
  Example:
  scale .s -digits 1000 will segfault
  or
  scale .s -digits <somelargenumber> ; .s get will segfault


tkt_uuid: bc4552d0bb8d4489b1d9675bbf7e0873d32bdb0c
type: Patch
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 500c9a7a4e11b3ea0441850610e04006941c0cf3
resolution: Postponed
title: Tcl_SetServiceMode in nextEventMatchingMask can be removed
comment:
  In the nextEventMatchingMask method in macosx/tkMacOSXNotify.c, in this section:

  @implementation TKApplication(TKNotify)
  - (NSEvent *) nextEventMatchingMask: (NSUInteger) mask
          untilDate: (NSDate *) expiration inMode: (NSString *) mode
          dequeue: (BOOL) deqFlag
  {
  ...
      int oldMode = Tcl_SetServiceMode(TCL_SERVICE_ALL);
      NSEvent *event = [[super nextEventMatchingMask:mask untilDate:expiration
              inMode:mode dequeue:deqFlag] retain];
      Tcl_SetServiceMode(oldMode);
  ...
  }

  we first set the service mode using Tcl_SetServiceMode, then we call the nextEventMatchingMask method of the superclass, and then we restore the original service mode.

  The Tcl_SetServiceMode function (in generic/tclNotify.c) is the following:

  int Tcl_SetServiceMode(int mode)
  {
      int oldMode;
      ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);
      oldMode = tsdPtr->serviceMode;
      tsdPtr->serviceMode = mode;
      Tcl_ServiceModeHook(mode);
      return oldMode;
  }

  Now the superclass nextEventMatchingMask method simply gets the next available event, but does not invoke any Tcl/Tk code. So setting tsdPtr->serviceMode has no consequences.

  The Tcl_ServiceModeHook function (in macosx/tclMacOSXNotify.c) creates the runloop timer if it doesn’t already exist. But since we also call Tcl_SetServiceMode from Tk_MacOSXSetupTkNotifier during Tk initialization, the runloop timer already exist by the time we call nextEventMatchingMask.

  So I think the two calls to Tcl_SetServiceMode in the nextEventMatchingMask method can be removed. The patch does just that. This patch was made relative to this patch which I submitted previously:

  https://core.tcl.tk/tcl/tktview?name=883155fb98

  However, these two patches can be applied independently of each other.


tkt_uuid: 1323974fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
severity: Minor
foundin: obsolete: 8.5a4
resolution: Duplicate
title: failing tests
comment:
  ==== textDisp-27.7 SizeOfTab procedure, center
  alignment, wrap -none (potential numerical problems) FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      set cm [winfo fpixels .t 1c]
      .t configure -tabs {1c 2c center 3c 4c 5c 6c 7c 8c}
  -wrap none -width 40
      .t insert 1.0
  a\tb\tc\td\te\n012345678934567890a\tbb\tcc\tdd
      set width [expr {$fixedWidth * 19}]
      set tab $cm
      while {$tab < $width} {
          set tab [expr {$tab + $cm}]
      }
      # Now we've calculated to the end of the tab after
  'a', add one
      # more for 'bb\t' and we're there, with 4 for the
  border.  Since
      # Tk_GetPixelsFromObj uses the standard 'int(0.5 +
  float)' rounding,
      # so must we.
      set tab [expr {4 + int(0.5 + $tab + $cm)}]
      update
      set res [.t bbox 2.23]
      lset res 0 [expr {[lindex $res 0] - $tab}]
      set res

  ---- Result was:
  -16 18 7 13
  ---- Result should have been (exact matching):
  -28 18 7 13
  ==== textDisp-27.7 FAILED


  ==== textImage-3.2 delayed image management FAILED
  ==== Contents of test case:

          catch {
              image create photo small -width 5 -height 5
              small put red -to 0 0 4 4
          }
          catch {destroy .t}
          text .t -font test_font -bd 0
  -highlightthickness 0 -padx 0 -pady 0
          pack .t
          .t image create end -name test
          update
          set result ""
          lappend result [.t bbox test]
          .t image configure test -image small -align top
          update
          lappend result [.t bbox test]

  ---- Result was:
  {0 8 0 0} {0 0 5 5}
  ---- Result should have been (exact matching):
  {} {0 0 5 5}
  ==== textImage-3.2 FAILED


tkt_uuid: e2f801f6ee3784ebff175a76451a993c4762ad8a
type: Patch
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: 500c9a7a4e11b3ea0441850610e04006941c0cf3
resolution: Postponed
title: tkProcessEvent return value is trivial
comment:
  The return value of tkProcessEvent in macosx/tkMacOSXEvent.c is processedEvent, which is either the same as the input argument theEvent, or equal to the return value of tkProcessKeyEvent or tkProcessMouseEvent. As these two functions always return the input argument theEvent, the return value of tkProcessEvent is always the same as the input argument theEvent. Therefore, in tkMacOSXNotify.c we do not need to check for the return value of tkProcessEvent.

  The attached patch is relative to the source code after applying this patch:
  https://core.tcl.tk/tk/tktview?name=bc4552d0bb


tkt_uuid: 1591493fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5a5
resolution: None
title: textImage-3.2 test case failure
comment:
  tk 8.5 cvs head built on solaris 2.9 with sun c
  compiler, test suite display back via exceed 10.0.0.12
  on win xp.

  textImage.test

  ==== textImage-3.2 delayed image management FAILED
  ==== Contents of test case:

          catch {
              image create photo small -width 5 -height 5
              small put red -to 0 0 4 4
          }
          catch {destroy .t}
          text .t -font test_font -bd 0
  -highlightthickness 0 -padx 0 -pady 0
          pack .t
          .t image create end -name test
          update
          set result ""
          lappend result [.t bbox test]
          .t image configure test -image small -align top
          update
          lappend result [.t bbox test]

  ---- Result was:
  {0 8 0 0} {0 0 5 5}
  ---- Result should have been (exact matching):
  {} {0 0 5 5}
  ==== textImage-3.2 FAILED


tkt_uuid: c18c36f80c67c88be099d38a24fc01448eda3a03
type: Bug
status: Open
subsystem: (unused)
priority: 5 Medium
severity: Minor
foundin: 8.5.16
private_contact: 5312fcfb57a92ddd64553c14c04a390a9032b63f
resolution: None
title:
  Cocoa Tk can segfault when embedded Tcl interpreters are created and destroyed in the same app bundle

comment:
  Due to recent changes in Python's test suite, a formerly working scenario can now result in Tk segfaults on OS X using current Cocoa Tk's.  Most users of Tk would probably not run into this case but it does, I believe, point out a bug in Cocoa Tk, one that results in a crash.  The scenario is complicated and my analysis may not be totally correct but I think the basic problem is clear.

  The Python test suite runner has a -j n option to allow multiple tests to be run simultaneously.  If -j is not specified, the test runner runs each test sequentially in one process.  If -j n is specified, where n > 0, the test runner creates n threads and, in each thread, repeatedly creates a subprocess to run one test until all tests have been executed.  Previously it was the case that the Python tests that used Tk (i.e. tests of the Python tkinter module) were pretty much all run with the same Tk root, created by the first test to run.  Recently, code was added to the tests to ensure that the root was destroyed after each test case and a new root created to avoid possible side effects among tests.  With that code in place, the test will often, but not always, cause Tk to segfault when run with -j.  To investigagte, I built debug versions of a Tcl and Tk 8.5.17 release candidate and, after examining the resulting crash reports, added some printf's (so the source line numbers may be off a little bit in the traceback).

  I believe the problem here is with the callbacks that Tk sets up to handle the "high-level" Apple Events in tkMacOSXHLEvents.c.  Here's the output from a test run:

  $ ./bin/python3.5 -m test -w -uall -j3 test_tk
  [1/1] test_tk
  *** in TkpInit ***, interp=0x7f8cf4904610 
   *** in TkpInit initialization ***, interp=0x7f8cf4904610 
   *** in TkMacOSXInitAppleEvents ***, interp=0x7f8cf4904610 
   *** in TkpInit ***, interp=0x7f8cf4ac0210
  Fatal Python error: Segmentation fault

  You can see TkpInit (in tkMacOSXInit.c) is called the first time with a pointer to one interpreter.  It then does its first time initialization (protected by 'if (!initialized)') including calling TkMacOSXInitAppleEvents to setup the callbacks for the various Apple Event handlers.  In particular, Tk stores the address of the interp instance it is running under into the Apple event callbacks.  It also happens that this first Tcl interpreter instance isn't asked to do much so it doesn't get as far as having Tk actually display anything which I think is significant later.  So far, no problem.  Then, for the next text case, Python cleans up the existing root and indirectly causes a new Tcl interpreter instance to be created: you can see that TkpInit is called again but with a different interp address.  But because "initialized" is still set in tkMacOSXInit, TkMacOSXInitAppleEvents is not called a second time.  This second interpreter instance is asked to actually display stuff which, I believe, results in the process finally being promoted to a gui app and results in an oapp ("open application") Apple event being received by Tk.  In the crash report below, you can see that happening.  Unfortunately, the oapp callback handler established in the first call to TkpInit (and TkMacOSXInitAppleEvents) contains the address of the first interpreter instance, now no longer valid.  But OappHandler blindly passes it along to Tcl_GetCommandInfo and neither check that the interp pointer is still valid.  So Tcl_GetCommandInfo dereferences a no-longer valid pointer; this is where the random behavior occurs.  If you're lucky, nothing bad happens (which seems to often (always?) be the case when running in 32-bit mode); in 64-bit mode, it will often crash as in this case in frame 3.

  Process:         pytest_10.9 [93374]
  Path:            /py/*/pytest_10.9.framework/Versions/3.5/Resources/Python.app/Contents/MacOS/pytest_10.9
  Identifier:      org.python.pytest_10.9
  Version:         3.5.0a0 (3.5.0a0)
  Code Type:       X86-64 (Native)
  Parent Process:  pytest_10.9 [93373]
  Responsible:     Terminal [12437]
  User ID:         501

  Date/Time:       2014-10-30 13:05:51.987 -0700
  OS Version:      Mac OS X 10.9.5 (13F34)
  Report Version:  11
  Anonymous UUID:  7FDFA581-A708-3453-3FE0-0D3FEA7F6707


  Crashed Thread:  0  Dispatch queue: com.apple.main-thread

  Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
  Exception Codes: EXC_I386_GPFLT

  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
  0   libsystem_kernel.dylib        	0x00007fff971ff292 __kill + 10
  1   pytest_10.9                   	0x00000001076ab870 faulthandler_fatal_error + 432 (faulthandler.c:312)
  2   libsystem_platform.dylib      	0x00007fff97f335aa _sigtramp + 26
  3   ???                           	0xcbcbcbcbcbcbcbcb 0 + 14685055086129564619
  4   Tcl_debug                     	0x0000000108314623 Tcl_GetCommandInfo + 51 (tclBasic.c:2566)
  5   Tk_debug                      	0x000000010862c4a9 OappHandler + 121 (tkMacOSXHLEvents.c:229)
  6   com.apple.AE                  	0x00007fff96494e1f aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 381
  7   com.apple.AE                  	0x00007fff96494c32 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 31
  8   com.apple.AE                  	0x00007fff96494b36 aeProcessAppleEvent + 315
  9   com.apple.HIToolbox           	0x00007fff9133f161 AEProcessAppleEvent + 56
  10  com.apple.AppKit              	0x00007fff93b1a0b6 _DPSNextEvent + 1026
  11  com.apple.AppKit              	0x00007fff93b1989b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
  12  Tk_debug                      	0x000000010863cd52 -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 338 (tkMacOSXNotify.c:56)
  13  Tk_debug                      	0x000000010863d421 TkMacOSXEventsCheckProc + 401 (tkMacOSXNotify.c:271)
  14  Tcl_debug                     	0x00000001083e7f66 Tcl_DoOneEvent + 550 (tclNotify.c:968)
  15  Tk_debug                      	0x00000001084f318f Tk_UpdateObjCmd + 271 (tkCmds.c:1104)
  16  Tcl_debug                     	0x0000000108315df7 TclEvalObjvInternal + 2423 (tclBasic.c:3727)
  17  Tcl_debug                     	0x0000000108316fa5 Tcl_EvalObjv + 117 (tclBasic.c:3925)
  18  _tkinter.so                   	0x00000001082e9dbb Tkapp_Call + 827 (_tkinter.c:1278)
  19  pytest_10.9                   	0x00000001074499dd PyCFunction_Call + 221 (methodobject.c:94)
  20  pytest_10.9                   	0x00000001075926a6 call_function + 1974 (ceval.c:4269)
  21  pytest_10.9                   	0x000000010758ab2f PyEval_EvalFrameEx + 78335 (ceval.c:2860)
  [...]
  132 pytest_10.9                   	0x000000010761baaa RunModule + 1114 (main.c:209)
  133 pytest_10.9                   	0x000000010761af1f Py_Main + 4335 (main.c:710)
  134 org.python.pytest_10.9        	0x000000010739de64 0x10739d000 + 3684
  135 libdyld.dylib                 	0x00007fff8ac7a5fd start + 1

  Thread 1:: Dispatch queue: com.apple.libdispatch-manager
  0   libsystem_kernel.dylib        	0x00007fff97200662 kevent64 + 10
  1   libdispatch.dylib             	0x00007fff928c6421 _dispatch_mgr_invoke + 239
  2   libdispatch.dylib             	0x00007fff928c6136 _dispatch_mgr_thread + 52

  Thread 2:
  0   libsystem_kernel.dylib        	0x00007fff971ffe6a __workq_kernreturn + 10
  1   libsystem_pthread.dylib       	0x00007fff8ceb1f08 _pthread_wqthread + 330
  2   libsystem_pthread.dylib       	0x00007fff8ceb4fb9 start_wqthread + 13

  Thread 3:
  0   libsystem_kernel.dylib        	0x00007fff971ffe6a __workq_kernreturn + 10
  1   libsystem_pthread.dylib       	0x00007fff8ceb1f08 _pthread_wqthread + 330
  2   libsystem_pthread.dylib       	0x00007fff8ceb4fb9 start_wqthread + 13

  Thread 4:
  0   libsystem_kernel.dylib        	0x00007fff971ffe6a __workq_kernreturn + 10
  1   libsystem_pthread.dylib       	0x00007fff8ceb1f08 _pthread_wqthread + 330
  2   libsystem_pthread.dylib       	0x00007fff8ceb4fb9 start_wqthread + 13

  Thread 5:
  0   libsystem_kernel.dylib        	0x00007fff971ff9aa __select + 10
  1   Tcl_debug                     	0x0000000108449105 NotifierThreadProc + 949 (tclMacOSXNotify.c:1778)
  2   libsystem_pthread.dylib       	0x00007fff8ceb0899 _pthread_body + 138
  3   libsystem_pthread.dylib       	0x00007fff8ceb072a _pthread_start + 137
  4   libsystem_pthread.dylib       	0x00007fff8ceb4fc9 thread_start + 13

  Thread 0 crashed with X86 Thread State (64-bit):
    rax: 0x0000000000000000  rbx: 0x000000010799df58  rcx: 0x000000010799da48  rdx: 0x0000000000000000
    rdi: 0x0000000000016cbe  rsi: 0x000000000000000b  rbp: 0x000000010799dab0  rsp: 0x000000010799da48
     r8: 0x0000000000000012   r9: 0x00007fff5882f700  r10: 0x0000000000000002  r11: 0x0000000000000202
    r12: 0x0000000061657674  r13: 0x00007fff7cc1cbb8  r14: 0x0000000000000003  r15: 0x000000006f617070
    rip: 0x00007fff971ff292  rfl: 0x0000000000000202  cr2: 0x000000010d05a258
    
  Logical CPU:     0
  Error Code:      0x02000025
  Trap Number:     133


  Some of the outputs from the printf's get lost in the crash.  Here's another run where the call to Tcl_GetCommandInfo in OappHandler has been commented out so that there is no crash.  Here you can see that OappHandler was called with the (now stale) address of the initial interp that was saved and returned in the oapp callback:

  $ ./bin/python3.5 -m test -w -uall -j2 -v test_ttk_guionly
  [...]
  [1/1] test_ttk_guionly
   *** in TkpInit ***, interp=0x7feffa119010 
   *** in TkpInit initialization ***, interp=0x7feffa119010 
   *** in TkMacOSXInitAppleEvents ***, interp=0x7feffa119010 
   *** in TkpInit ***, interp=0x7feff9a02a10 
  test_horizontal_range (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ...  
   *** in OappHandler ***, interp=0x7feffa119010 
  ok
  test_initialization (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok
  test_initialization_no_master (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ...  
   *** in TkpInit ***, interp=0x7feffa277410 
  ok
  test_resize (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok
  test_variable_change (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ... ok
  test_widget_destroy (tkinter.test.test_ttk.test_extensions.LabeledScaleTest) ...  
   *** in TkpInit ***, interp=0x7feff9b67c10 
  ok
  test_initialization (tkinter.test.test_ttk.test_extensions.OptionMenuTest) ... ok
  test_menu (tkinter.test.test_ttk.test_extensions.OptionMenuTest) ... ok
  test_widget_destroy (tkinter.test.test_ttk.test_extensions.OptionMenuTest) ...
   *** in TkpInit ***, interp=0x7feff9b67c10 


  We certainly can workaround the crash in Python by special-casing the Tk-related tests.  But, in any case, it's not nice for Tk to segfault.  The Tk Apple event handlers should not be so trusting as to assume that the callbacks still contain a valid interpreter instance pointer and/or TkMacOSXInitAppleEvents should possibly be called for each interpreter initialization.


tkt_uuid: 775811ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5a0
resolution: Out of Date
title: textTag.test fails on Tru64Unix 5.1A
comment:
  I use Xfree86/fvwm2 from linux laptop to display the X
  apps from Tru64Unix machine. I tested current cvs tcl/tk.

  ==== textTag-16.2 TkTextPickCurrent procedure FAILED
  ==== Contents of test case:

      event gen .t <ButtonRelease-1> -state 0x100 -x $x1
  -y $y1
      event gen .t <Motion> -x $x2 -y $y2
      set x [.t index current]
      .t tag add big 3.0
      update
      lappend x [.t index current]

  ---- Result was:
  3.2 3.2
  ---- Result should have been (exact matching):
  3.2 3.1
  ==== textTag-16.2 FAILED


tkt_uuid: 910f1b49554768469bcc0d6590cf0a82968d7f1b
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: 8.6 trunk
private_contact: e476148cded301ffff84bcdc432536dc0c949e88
resolution: None
title: Cocoa Key{Press,Release} serial numbers for auto-generated events
comment:
  for auto-generated KeyPress or KeyRelease events, it appears that under X11,
  KeyRelease serials are matched to KeyPress serials, but under Cocoa, KeyPress
  serials are matched to KeyRelease serials, but then in a ::ttk::spinbox in
  Cocoa, no serials match so Key* serial mechanism can't be used to detect
  synthesized Key events, as it can under X11.



  #! /bin/env tclsh

  package require Tk

  canvas .c -width 200 -height 200
  ::ttk::spinbox .sp1 -from 0 -to 100 -increment 1
  pack .c .sp1

  bind all <KeyPress> +[list [namespace current]::truekeypress %W %# [namespace current]::truepress]
  bind all <KeyRelease> +[list [namespace current]::truekeyrelease %W %# [namespace current]::truepress]


  variable truepress
  array set [namespace current]::truepress [list press 0 release 0]

  proc truekeypress {w serial arrayname} {
      puts "press: $serial"
      upvar $arrayname state
      set state(press) $serial
      if {$serial ne $state(release)} {
          event generate $w <<TrueKeyPress>>
      }
  }

  proc truekeyrelease {w serial arrayname} {
      puts "release: $serial"
      upvar $arrayname state
      set state(release) $serial
      after 0 [list apply [list {w arrayname} {
          upvar $arrayname state
          if {$state(release) ne $state(press)} {
              event generate $w <<TrueKeyRelease>>
          }
      } [namespace current]] $w $arrayname]
  }


tkt_uuid: 1591491fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5a5
private_contact: eda214b8908e4945e7a6d1377e45d6a5246ab6a7
resolution: Wont Fix
title: textDisp test case failure on cvs head
comment:
  solaris 2.9 sun c compiler build of tk 8.5 cvs head;
  test suite displayed via exceed 10.0.0.12 on a win xp
  system.

  textDisp.test

  ==== textDisp-27.7 SizeOfTab procedure, center
  alignment, wrap -none (potential 
  numerical problems) FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      set cm [winfo fpixels .t 1c]
      .t configure -tabs {1c 2c center 3c 4c 5c 6c 7c 8c}
  -wrap none -width 40
      .t insert 1.0
  a\tb\tc\td\te\n012345678934567890a\tbb\tcc\tdd
      set width [expr {$fixedWidth * 19}]
      set tab $cm
      while {$tab < $width} {
          set tab [expr {$tab + $cm}]
      }
      # Now we've calculated to the end of the tab after
  'a', add one
      # more for 'bb\t' and we're there, with 4 for the
  border.  Since
      # Tk_GetPixelsFromObj uses the standard 'int(0.5 +
  float)' rounding,
      # so must we.
      set tab [expr {4 + int(0.5 + $tab + $cm)}]
      update
      set res [.t bbox 2.23]
      lset res 0 [expr {[lindex $res 0] - $tab}]
      set res

  ---- Result was:
  -36 18 7 13
  ---- Result should have been (exact matching):
  -28 18 7 13
  ==== textDisp-27.7 FAILED


tkt_uuid: 1591489fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5a5
private_contact: eda214b8908e4945e7a6d1377e45d6a5246ab6a7
resolution: Out of Date
title: test suite text-1.10 failure , cvs head
comment:
  tk 8.5 cvs head, built on solaris 2.9 using sun c
  compiler, then test suite run output via exceed
  10.0.0.12 on win xp system.

  text.test

  ==== text-1.10 text options FAILED
  ==== Contents of test case:

          set result {}
          lappend result [catch {.t2 configure [lindex
  $test 0] [lindex $test 3]}]
          .t2 configure [lindex $test 0] [lindex $test 1]
          lappend result [.t2 cget [lindex $test 0]]
      
  ---- Result was:
  0 fixed
  ---- Result should have been (exact matching):
  1 fixed
  ==== text-1.10 FAILED


tkt_uuid: d65cf7e1ed6ee4e4a0c19ad1403cb5f00c2732fa
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
severity: Minor
foundin: 8.5.15
private_contact: 4a267845b96d18ced148980dad8c23b791785018
resolution: None
title: Canvas coordinate system is offset by 3 pixels on Mac OS X
comment:
  On OS X (and *not* on linux) the coordinate system on the Canvas object behaves as if the top left corner has coordinates (3,3).  Here is a demonstration script. The blue rectangle *should* have equal 10 pixel margins on all sides but instead it is moved up and to the left by 3 pixels.  On the other hand the red square does have equal margins, but it should appear to be shifted down and to the right by 3 pixels.

  . configure -background gray
  pack [ canvas .c -width 200 -height 200 -background white ]
  .c create rectangle 10 10 189 189 -outline blue
  .c create rectangle 13 13 192 192 -outline red


tkt_uuid: 280089486ea81c960f3df457a4681ed13312dcf2
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: a013af67114eccc19ad12b04f14923acea9e96b7
resolution: Fixed
title: text-19.16 fails
comment:
  text-19.16 {DeleteChars procedure, updates affecting topIndex} fails in trunk (8.6)


  Test log:

  ==== text-19.16 DeleteChars procedure, updates affecting topIndex FAILED
  ==== Contents of test case:

      .top.t insert end "abc def\n01 2345 678 9101112\nLine 3\nLine 4\nLine 5\n6\n7\n8\n"
      .top.t yview 2.4
      .top.t delete 2.5
      set x [.top.t index @0,0]
      .top.t delete 2.5
      list $x [.top.t index @0,0]

  ---- Result was:
  2.0 2.0
  ---- Result should have been (exact matching):
  2.3 2.0
  ==== text-19.16 FAILED


tkt_uuid: 7fcb7ca586605f5dfaafc78d47366b6c4074e4e8
type: Bug
status: Open
subsystem: 75. wish
priority: 5 Medium
severity: Minor
foundin: wish v8.5
private_contact: 5bdb56320b31bdefa67afbbb9e01471cec20b21b
resolution: None
title: exec on a script which execute the 'rsh' command
comment:
  This bug is similar to :
  http://sourceforge.net/p/tcl/mailman/message/16175494/

  TCL code :
  exec ./script.sh &

  Bash script script.sh :
  [...]
  rsh [IP] ls ==> Hang on this line

  The wish processus is stopped (and can run again with a SIGCONT signal).
  The Bash script is also stopped.
  The rsh processus is also stopped.
  Sending a SIGCONT to the rsh processus stop again the wish processus...

  The script works if it is run from a terminal (without wish).

  I have to use 'rsh' because the server is very old (1984) and use a very old operating system which dosn't have SSH capacity.

  Thanks,
  Germain


tkt_uuid: 4d8f66055a6da8dd993023a52df7d96baf21bd1a
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Minor
foundin: 8.6.2
resolution: None
title: Support for Win7/8 style tk_getOpenFile and friends
comment:
  The tk_get{Open,Save}File and tk_chooseDirectory display the older XP style dialogs as opposed to the new Win7/8 ones.

  Displaying the newer dialogs seemingly requires a new API - sample code at http://code.msdn.microsoft.com/CppShellCommonFileDialog-17b20409/sourcecode?fileId=52757&pathId=1435971692

  To maintain support for XP, the API's should be called dynamically with fallback to the older code if the API is not present.

  I can take a stab at this but would like confirmation from someone who is more knowledgeable than me wrt the Windows UI whether the above code is the right way to go or there might be some simpler mechanism based on changing the manifest (just as there was to switch from Win2K -> XP style dialogs).


tkt_uuid: fbc98654613da1edff35887c550b514cc340e0cd
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
severity: Important
foundin: 8.5-8.6
private_contact: 582b61b01c28772572a4036587ff671d73c1245e
resolution: None
title: tk_chooseDirectory -mustexist option incorrect on Windows
comment:
  tk_chooseDirectory -mustexist option does not work as documented on Windows.

  The "New Folder" button is visible and active even when the  mustexist option is given a value of "true".

  This may be a limitation of the Windows native dialog being used, if so the documentation should be changed to reflect the mustexist option does nothing on windows.  If it is not a limitation of the Windows native dialog being used, then the code should be fixed to invoke the native dialog in such a way that either the "New Folder" button is not visible or is inactive.


tkt_uuid: 53ef902284760bbb53af0e4147001c69b26c1df7
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: 8.5.16
resolution: None
title: macosx test suite fatal error
comment:
  using the `make test` under the macosx directory,
  on the second pass, I see this fatal error:

  Error in startup script: cannot use namespace qualifiers in hidden command token (rename)The window ID 0xfb277a10 does not correspond to a valid Tk Window.
      invoked from within
  "load {} Tk $slave"
      (procedure "safe::loadTk" line 63)
      invoked from within
  "safe::loadTk foo"
      (file "/Users/dgp/fossil/tk8.5.16/tests/tk.test" line 153)
  ...

  (I truncated the stack trace)


tkt_uuid: 1d37c3e16616a0e6283ef390272f0cf483b74b5f
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Critical
foundin: 8.6.2
private_contact: 5312fcfb57a92ddd64553c14c04a390a9032b63f
resolution: Fixed
title: Cocoa Tk built for OS X 10.10 fails with "Mac OS X 10.10000 or later required "
comment:
  When built on OS X 10.10 (Yosemite) or with a MACOSX_DEPLOYMENT_TARGET of 10.10, Cocoa Tk aborts during initialization due to a faulty version check.  Because the minor version number (the y of x.y.z) has now reached two digits for 10.10.x, Apple has had to incompatibility change the version numbering scheme used in its AvailabilityMacros.h which are used by Cocoa Tk.

  The following test program which duplicates the relevant code from macosx/tkMacOSXInit.c illustrates the problem:

  <verbatim>
  #include <stdio.h>
  #include <stdlib.h>
  #include <sys/utsname.h>
  #include <AvailabilityMacros.h>

  int main() { 
      struct utsname name;
      long tkMacOSXMacOSXVersion = 0;

      uname(&name);
      printf("uname release = %s\n", name.release);
      printf("MAC_OS_X_VERSION_MIN_REQUIRED = %i\n", MAC_OS_X_VERSION_MIN_REQUIRED);
      tkMacOSXMacOSXVersion = (strtod(name.release, NULL) + 96) * 10;
  	printf("tkMacOSXMacOSXVersion = %li\n", tkMacOSXMacOSXVersion);
  	return 0;
  }
  </verbatim >

  On OS X 10.8.5, the results are:

  <verbatim >
  uname release = 12.5.0
  MAC_OS_X_VERSION_MIN_REQUIRED = 1080
  tkMacOSXMacOSXVersion = 1085
  </verbatim >

  But on OS X 10.10, the results are:

  <verbatim >
  uname release = 14.0.0
  MAC_OS_X_VERSION_MIN_REQUIRED = 101000
  tkMacOSXMacOSXVersion = 1100
  </verbatim >

  Note the difference in format of MAC_OS_X_VERSION_MIN_REQUIRED.

  This causes the test at [https://core.tcl.tk/tk/finfo?name=macosx/tkMacOSXInit.c] line 239 in TkpInit to fail on 10.10 with the resulting abort message referenced in the title.

  There are obviously various ways to fix this for 8.6.x and 8.5.x.  It might be best to find out how Apple presumably fixed their copy of 8.5 for the 10.10 release.  As of now, [http://www.opensource.apple.com] has not yet been updated with 10.10 sources.


tkt_uuid: 0cb85bcb48ee518644330bf45d6646f3f78b7243
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
severity: Minor
foundin: 8.5+
resolution: None
title: Mysteries when all default named fonts are deleted
comment:
  Over in http://core.tcl.tk/tk/tktview/280089486ea81c960f3df457a4681ed13312dcf2
  some failing text test were tracked down to the impact
  of font.test having deleted all the default named fonts, including
  "TkFixedFont".  With that font deleted, the rendered text in
  the text widget changed size and the tests failed.  In the investigation
  there are some mysteries about how things do what they do that
  are worth tracking down.

  Another Q is whether some core set of fonts should perhaps be
  un-delete-able.


tkt_uuid: fb35eb59dd18603f8e47133d04573a14aa802e80
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
severity: Severe
foundin: 8.6.2
private_contact: 663166fc0fdcdf4ff5a1ebe025df27c09f552ea1
resolution: Fixed
title: PNGs on Mac OS X displaying incorrectly
comment:
  All PNG images I have tested have a translucent background where they should be 100% transparent. The same result appears whether the image is displayed as a canvas item or as part of a ttk::label widget (I don't think I've tried a non-ttk label widget).

  This image illustrates the problem:
  https://cdn.mediacru.sh/SYfnMG7d_E9f.png

  Here is the source PNG shown in the image above:
  https://cdn.mediacru.sh/_mrBnMR3FVz3.png

  Here is where I suspect the problem lies:
  https://github.com/tcltk/tk/commit/a6f4a5d2b811d3d5a547ca0164a499eb40c18153

  This commit was after 8.6.1 and before 8.6.2 release dates. It fixed the initial PNG problem on OS X Mavericks, and I'm guessing it introduced this new, more subtle problem on apparently all versions of OS X.

  Paul Walton


tkt_uuid: 810c43d789043d342eae6c73aa3c318f863fe762
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: trunk
private_contact: a013af67114eccc19ad12b04f14923acea9e96b7
resolution: Fixed
title: textDisp-19.11.20 and textDisp-19.11.23 fail
comment:
  textDisp-19.11.20 and textDisp-19.11.23 fail


  Both tests concern TextWidgetCmd procedure, "index +displaylines"


  This happens on 8.6 (trunk) branch only (these tests are not present in the 8.5 branch).


  Test log:

  ==== textDisp-19.11.20 TextWidgetCmd procedure, "index +displaylines" FAILED
  ==== Contents of test case:

      .t tag remove elide 1.0 end
      .t tag add elide "12.0" "16.0 +1displaylines"
      list [.t index "11.5 +2d lines"]  [.t index "12.0 +2d lines"] [.t index "11.0 +2d lines"]  [.t index "13.0 +2d lines"] [.t index "13.0 +3d lines"]  [.t index "13.0 +4d lines"]

  ---- Result was:
  15.5 16.0 15.0 16.0 16.67 16.33
  ---- Result should have been (exact matching):
  16.38 16.50 16.33 16.50 16.67 17.0
  ==== textDisp-19.11.20 FAILED


  ==== textDisp-19.11.23 TextWidgetCmd procedure, "index +displaylines" FAILED
  ==== Contents of test case:

      .t tag remove elide 1.0 end
      .t tag add elide "12.3" "16.0 +1displaylines"
      list [.t index "11.5 +1d lines"] [.t index "11.5 +2d lines"]  [.t index "12.0 +1d lines"]  [.t index "12.0 +2d lines"] [.t index "11.0 +2d lines"]  [.t index "13.0 +2d lines"] [.t index "13.0 +3d
  lines"]  [.t index "13.0 +4d lines"]

  ---- Result was:
  16.17 15.5 16.28 16.0 15.0 16.0 16.65 16.33
  ---- Result should have been (exact matching):
  16.17 16.33 16.28 16.46 16.28 16.49 16.65 17.0
  ==== textDisp-19.11.23 FAILED


tkt_uuid: f84cd3303a72a60a89ee581dee4520cc561cc3a6
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
severity: Minor
foundin: 8.6.0
private_contact: be10c68edb35fa3f93c8cac6f2c0d27dc3933920
resolution: Fixed
title: PNG saved not equal to read PNG
comment:
  I wrote a tcl/Tk helper joining PNG files to a toolbar image used in my C++/MFC project. 
  This helper additionally allows to split a toolbar image into single PNG files. 

  But ... some splitted PNG files are not identical to the joined, while the joined toolbar image looks the way I expected. 

  Here the code I used to join the images: 

      set toolbarImgFile  [file tail [pwd]].png 
      set files           [glob -nocomplain -directory [pwd] -types f -- *16.png] 
      set filesCount      [llength $files]; 
      
      if {$filesCount != 0} { 
          image create photo toolbarImage -width [expr {$filesCount*16}] -height 16 -format png -palette 255/255/255; 
          
          set x 0; 

          foreach file [lsort -dictionary $files] { 
              toolbarImage read $file -to $x 0; 

              incr x 16 
          } 

          toolbarImage write $toolbarImgFile -format png; 

          image delete toolbarImage; 
      } 

  Here the code I used to split the images: 

      set toolbarImgFile  [file tail [pwd]].png 
      set pathPrefix      [file rootname $toolbarImgFile]; 
      
      image create photo toolbarImage -file $toolbarImgFile; 
          
      set width   [image width toolbarImage]; 
      set height  [image height toolbarImage]; 
      
      for { 
          set valid   [expr {$width % $height == 0}]; 
          set i       0; 
          set count   [expr {$width / $height}]; 
          set x       0; 
      } {$valid && $i < $count} {} { 
          set pngFile [format {%s_%d_%d.png} $pathPrefix [incr i] $height]; 
          
          toolbarImage write $pngFile -from $x 0 [incr x $height] $height -format png; 
      } 
      
      image delete toolbarImage; 

  Three of the joined PNG images are not the same anymore after splitting, here an example for the first not identical image: 

  package require base64; 

  set joinedImgB64 {iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAACXklEQVQ4y52Sy04UQRSGv+6uuTID 
  zAByJxoEVOICF7o2Rh/AjbhwQ5gxvBFRHwCDunHhE6gLFm7ABNlwvwyOM0PPdFdVd3W74DaGhQkn 
  OZVKzvm//HVOWSsrK7HneXieh+/7/O8upSSKIgDGx8expZQopa6klJLzWntPu3hhYQFx3qClJFU5 
  YrT2m2zLRbda7PuKNZGijoWUEmPMP2LgFKCkpLi7xVSkyRQ7Mbk0QT1B4fCI/O4mQSLLr0zmivgC 
  ICqHTAQ+HX09OKk0ttciUpq4q5v+fBfPLfBbPgdac/PRQ2JjsBwHAFspRXF/l7Rjg2WBZRHH4IYR 
  uf4bDN0aY3BogNG+AtMO1N8tsvHhI9HZc2wpJal6HeP7mBOXsFGn8adGOinIFrtJFAok8jlENksq 
  10FvJknz0xLbX79dOvBPGuhaDVWtoirHuNUaqTZHYMHZmRCCHDEby8uXMzgIY/qPj0l5HpbjoGMH 
  4/vYJy5xUmKkwvgSozRREEIUUV1bPQVIKdnsKlBcX2Mgn0UkBH66A50WREGA7ThEQUDYbBK2moSe 
  T6A0KgwvHXjd3XxP57mztU1PUiALPfRa0YWj2IQYz0e7Lu5Jg3qzSeb2ZNs/0Jra2Ch7lsXAwQGZ 
  vQpJLRnozCESAqKIUCparkulWmPHU9x7MdsGOIMMP5ih/HqRyBh+vHnL+pfPFISNDehA02h67HiS 
  4uwrpp88vpyBUoqRkRHK5fLpahyHmdI8G1NTrC+9p/ZzlSA0dExMcvflLPefPcUR4nQzpVIpHhwc 
  ZH5+nuuEGB4eZm5ujuvGX+bBgCERryGmAAAAAElFTkSuQmCC}; 

  set splittedImgB64 {iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAABp0RVh0 
  U29mdHdhcmUAVGsgVG9vbGtpdCB2OC42LjCjHintAAACqUlEQVR4nJ3S/0saYRwHcP+LWkEG+cOa 
  tZKMUQuaYanH7Mv6Yq2MVedZYbXK6XTXaZmJtxvTcpBL2WI1m4FKbCtKNmqNBUFUtG9Baq21tS2h 
  /2CfO2ocsZ96wf1y93ze9354Hs4qWASzIAAmwGPgBDbQB7SgHdwCtaDmhAFw3oF5EAI+4AUjwA5M 
  QAc0oAXUAfbwHuCEwQzwT01NBZwOx7IZx9fudHWttKNooEmptKhQFFOpVPXg7DAT8ApM+/3+MGW3 
  fyMtlj/DJHlIDQ7u41rtV1SpXJCJxURpaWmtQqE4O8wE0PsOuoaHd21mc9wzMnL8bGws7nY4flgJ 
  4ktvR8dmt0az3qPRfFC3tNCN1kLB4G40Gv0XQO970ajTHZIDA3Gvy3U84fEcjToc2/04vv+fRm+u 
  SyTh+xQVOwnhPAEr7Rh20G8w/H5osx09oqjIkMm0d6bRzyGCiN1ubd2slstDeULh0sTkJBMwCt42 
  KBT0R/ovBya9fqO3s5PdKO52OumAXVjzua6iIpyXk+MtKy9nAujzfg4n+6m+snIHa2yMtDU1rbai 
  KLvRrwdW6/c+nS7S1tz8sUouD18RCEgej8cE0Oc9pFar564VFKzLS0q2biDI0s3qanajfWNPT6wT 
  w7Yba2o2ELF4NpvPt6SmpjIBA+CuXq83SWUy32U+f16YlTVTXFTEbrSDKZXbDVVVW2USyXJBbq6P 
  x+VS4uJiJuAe6AZqDMNQGYLg2QKB9VJGxlxhfv5po61yqXRdKhK9vyoUBi6mpZFJiYkvx7xeJoB9 
  z+kw+iV9REGD0fgiOzOTbhSG53VWerovjcslLyQkeLq12mgkEmECTu85Dtg3LAYLFp6Oj7ukCGJJ 
  SUkhkpKT7YUi0cyo2306zATANVcRYO+cOGZw3mHaX011VIZoT/FvAAAAAElFTkSuQmCC}; 

  image create photo joinedImg -data [base64::decode $joinedImgB64] -format png; 
  image create photo splittedImg -data [base64::decode $splittedImgB64] -format png; 

  toplevel .t; 
  label .t.l1 -image joinedImg -text "joined" -compound top; 
  label .t.l2 -image splittedImg -text "splitted" -compound top; 
  pack .t.l1 .t.l2 -side left -fill none -expand 0 -padx 3 -pady 3;


tkt_uuid: 0c7ac8216d331d5fc98dad21c6165aad0dbb4801
type: Bug
status: Closed
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Minor
foundin: 8.5 & 8.6
private_contact: 8d249660b7d93ca00711812d8bb79b037e348cd1
resolution: Rejected
title: treeview tag command raises error with nodename containing space
comment:
  Hi,

  today I have noticed, that the ttk::treeview widget works very well with spaces in nodenames, but an error is raised, if you try to tag a node containg spaces in name.

  Although the node is listed in the
     <pre>[.widget children $parentnode]</pre>
  command, like "Program Files" for e. g., the
     <pre>[.widget tag tagname "Program Files"]</pre>
  command raises a "Node not found" error.

  Is that a bug and does someone know a workaround for that problem?

  Of coarse, I know, it is possible to replace the spaces by some unusual character or introduce a completely different indexing system for the widget, but this makes it a lot more complex to handle full pathnames of filesystems or similar tree structures as windows registry, which allow spaces in names.

  Regards


tkt_uuid: d6832081784525788771792e174e54d7aa5cc640
type: Bug
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Severe
foundin: 8.6
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
resolution: None
title: OSX Segfault when combobox is located on second screen
comment:
  Under normal conditions (and on the primary monitor), ttk comboboxes work normally. But under the latest 10.9 (Maverics) if a window is moved to the second display of the computer, clicking on the menu selector of the combobox produces the following segfault:

  Process:         irmsde [34394]
  Path:            /Users/USER/*/irmsde
  Identifier:      irmsde
  Version:         0
  Code Type:       X86-64 (Native)
  Parent Process:  bash [55857]
  Responsible:     Terminal [521]
  User ID:         501

  Date/Time:       2014-06-12 12:38:48.942 -0400
  OS Version:      Mac OS X 10.9.3 (13D65)
  Report Version:  11
  Anonymous UUID:  EAB60C7C-4834-FAFF-68F3-0BCB1A2842A1

  Sleep/Wake UUID: 0D0C9F7B-8006-44A6-BE70-65BFD569908B

  Crashed Thread:  0  Dispatch queue: com.apple.main-thread

  Exception Type:  EXC_CRASH (SIGABRT)
  Exception Codes: 0x0000000000000000, 0x0000000000000000

  Application Specific Information:
  *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'
  abort() called
  terminating with uncaught exception of type NSException

  Application Specific Backtrace 1:
  0   CoreFoundation                      0x00007fff9192d25c __exceptionPreprocess + 172
  1   libobjc.A.dylib                     0x00007fff8edf7e75 objc_exception_throw + 43
  2   CoreFoundation                      0x00007fff9192d10c +[NSException raise:format:] + 204
  3   AppKit                              0x00007fff88614e97 _NXCreateWindowWithStyleMask + 132
  4   AppKit                              0x00007fff88614d7d _NSCreateWindow + 64
  5   AppKit                              0x00007fff884cd74c -[NSWindow _commonAwake] + 2963
  6   AppKit                              0x00007fff884cc717 -[NSWindow _makeKeyRegardlessOfVisibility] + 85
  7   AppKit                              0x00007fff884cc690 -[NSWindow makeKeyAndOrderFront:] + 29
  8   irmsde                              0x000000010a34ea5c XMapWindow + 134
  9   irmsde                              0x000000010a2c1e51 Tk_MapWindow + 69
  10  irmsde                              0x000000010a3564a4 TkpWmSetState + 171
  11  irmsde                              0x000000010a354fbf Tk_WmObjCmd + 11648
  12  irmsde                              0x000000010a1a2716 TclNRRunCallbacks + 80
  13  irmsde                              0x000000010a1a38ee TclEvalEx + 1826
  14  irmsde                              0x000000010a1a31c6 Tcl_EvalEx + 26
  15  irmsde                              0x000000010a29e321 Tk_BindEvent + 3751
  16  irmsde                              0x000000010a2a30e3 TkBindEventProc + 324
  17  irmsde                              0x000000010a2a956f Tk_HandleEvent + 1049
  18  irmsde                              0x000000010a2a99d5 WindowEventProc + 85
  19  irmsde                              0x000000010a24d4bc Tcl_ServiceEvent + 140
  20  irmsde                              0x000000010a24d765 Tcl_DoOneEvent + 324
  21  irmsde                              0x000000010a2151d5 Tcl_VwaitObjCmd + 153
  22  irmsde                              0x000000010a1a2716 TclNRRunCallbacks + 80
  23  irmsde                              0x000000010a1a38ee TclEvalEx + 1826
  24  irmsde                              0x000000010a242089 Tcl_FSEvalFileEx + 465
  25  irmsde                              0x000000010a2b57ea Tk_MainEx + 926
  26  irmsde                              0x000000010a191faf main + 82
  27  libdyld.dylib                       0x00007fff8983b5fd start + 1


tkt_uuid: b4214b47120e23fc75ec806b20d2ddfb0845b2d4
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
severity: Minor
foundin: 8.6.1
private_contact: 55805032f00760ddf84eb3f8acb077da7bef1411
resolution: None
title: Segfault on unexpected <Destroy> event
comment:
  MinGW64, Win7:

  A toplevel is created inside an oo class like:

  ...
  toplevel $_me -background $tkcolour::windowbg
  #bind $_me <Destroy> [list catch {puts ___xxxxxxxxxxxxxx.x.x.x.x.xxxxxxxxxxxxxxx___}]
  bind $_me <Destroy> [list catch [callback destroy]]
  ...

  The destroy event is fired during my object/GUI creation and forces a segfault. See stack below.
  I already tried to create a simple tcl/tk example but it does not crash that way.

  So the reason is clear to me - there is access to an object which is deleted, triggered by the event (see line #12).
  What's not clear to me is why the <Destroy> event is fired?
  When I replace the "destroy" with the "puts" I see lots of outputs in the console. In my understanding this should also not be?


  thx


  (gdb)
  #0  Tcl_GetString (objPtr=0x0) at d:/CM.git/tcltk86/dcompile/tcl/generic/tclObj.c:1598
  #1  0x000000006197fd10 in MenuVarProc (clientData=0x3e9d530, interp=0x1c94720,
      name1=0x3e25830 "::oo::Obj74::_layoutAutoOpen", name2=0x0, flags=192)
      at ./../generic/tkMenu.c:2492
  #2  0x0000000067586279 in TclCallVarTraces (iPtr=0x1c94720, arrayPtr=0x0, varPtr=0x22e6d0,
      part1=0x3e25830 "::oo::Obj74::_layoutAutoOpen", part2=0x0, flags=192, leaveErrMsg=0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclTrace.c:2675
  #3  0x0000000067585db9 in TclObjCallVarTraces (iPtr=0x1c94720, arrayPtr=0x0, varPtr=0x22e6d0,
      part1Ptr=0x427e480, part2Ptr=0x0, flags=64, leaveErrMsg=0, index=-1)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclTrace.c:2517
  #4  0x000000006758ff21 in UnsetVarStruct (varPtr=0x3e38640, arrayPtr=0x0, iPtr=0x1c94720,
      part1Ptr=0x427e480, part2Ptr=0x0, flags=0, index=-1)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclVar.c:2504
  #5  0x0000000067594672 in TclDeleteNamespaceVars (nsPtr=0x3e3a4f0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclVar.c:5332
  #6  0x000000006753b5af in TclTeardownNamespace (nsPtr=0x3e3a4f0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclNamesp.c:1118
  #7  0x000000006753b4bf in Tcl_DeleteNamespace (namespacePtr=0x3e3a4f0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclNamesp.c:1028
  #8  0x000000006753a7f2 in Tcl_PopCallFrame (interp=0x1c94720)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclNamesp.c:421
  #9  0x000000006756c7de in InterpProcNR2 (data=0x427d8b8, interp=0x1c94720, result=0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclProc.c:1880
  #10 0x000000006741c8c1 in TclNRRunCallbacks (interp=0x1c94720, result=0, rootPtr=0x427d6a0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4390
  #11 0x000000006741c059 in Tcl_EvalObjv (interp=0x1c94720, objc=2, objv=0x1c9abc0, flags=2097168)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4121
  #12 0x000000006741e7d5 in TclEvalEx (interp=0x1c94720,
      script=0x22ed00 "catch {::oo::Obj74::my destroy}\nttk::notebook::TLCleanup .oowin1_.containerFra
  me.notebook.mcsettings.table_.tframe.table.hdr.t.f.l0", numBytes=131, flags=131072, line=1,
      clNextOuter=0x0,
      outerScript=0x22ed00 "catch {::oo::Obj74::my destroy}\nttk::notebook::TLCleanup .oowin1_.contain
  erFrame.notebook.mcsettings.table_.tframe.table.hdr.t.f.l0")
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:5259
  #13 0x000000006741db79 in Tcl_EvalEx (interp=0x1c94720,
      script=0x22ed00 "catch {::oo::Obj74::my destroy}\nttk::notebook::TLCleanup .oowin1_.containerFra
  me.notebook.mcsettings.table_.tframe.table.hdr.t.f.l0", numBytes=131, flags=131072)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4924
  #14 0x00000000618f86dc in Tk_BindEvent (bindPtr=0x1d2d430, eventPtr=0x22f050, tkwin=0x4283110,
      numObjects=0, objectPtr=0x22eed8) at ./../generic/tkBind.c:1492
  #15 0x000000006192ebde in TkBindEventProc (winPtr=0x4283110, eventPtr=0x22f050)
      at ./../generic/tkCmds.c:316
  #16 0x0000000061940dba in Tk_HandleEvent (eventPtr=0x22f050) at ./../generic/tkEvent.c:1363
  #17 0x00000000619cff07 in Tk_DestroyWindow (tkwin=0x4283110) at ./../generic/tkWindow.c:1432
  #18 0x000000006192f15d in Tk_DestroyObjCmd (clientData=0x1cf2b40, interp=0x1c94720, objc=2,
      objv=0x1c9a8f0) at ./../generic/tkCmds.c:497
  #19 0x000000006741c832 in Dispatch (data=0x5845658, interp=0x1c94720, result=0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4357
  #20 0x000000006741c8c1 in TclNRRunCallbacks (interp=0x1c94720, result=0, rootPtr=0x0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4390
  #21 0x000000006741f3e5 in TclEvalObjEx (interp=0x1c94720, objPtr=0x675585f6 <Tcl_GetString>,
      flags=131072, invoker=0x0, word=0) at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:5956
  #22 0x000000006741f376 in Tcl_EvalObjEx (interp=0x1c94720, objPtr=0x675585f6 <Tcl_GetString>,
      flags=131072) at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:5937
  #23 0x000000006750a51b in Tcl_RecordAndEvalObj (interp=0x1c94720, cmdPtr=0x3b7fde0, flags=131072)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclHistory.c:190
  #24 0x00000000618c2991 in InterpreterObjCmd (clientData=0x1ce1780, interp=0x3001f50, objc=3,
      objv=0x31ae358) at ./../generic/tkConsole.c:821
  #25 0x000000006741c832 in Dispatch (data=0x3b7f308, interp=0x3001f50, result=0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4357
  #26 0x000000006741c8c1 in TclNRRunCallbacks (interp=0x3001f50, result=0, rootPtr=0x0)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4390
  #27 0x000000006741c059 in Tcl_EvalObjv (interp=0x3001f50, objc=1, objv=0x31ae080, flags=2097168)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4121
  #28 0x000000006741e7d5 in TclEvalEx (interp=0x3001f50,
      script=0x22f750 "\n .console mark set insert {end - 1c}\n   tk::ConsoleInsert .console \"\\n\"\n
          tk::ConsoleInvoke\n     break\n    ", numBytes=101, flags=131072, line=4,
      clNextOuter=0x0,
      outerScript=0x22f750 "\n    .console mark set insert {end - 1c}\n   tk::ConsoleInsert .console \
  "\\n\"\n        tk::ConsoleInvoke\n     break\n    ")
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:5259
  #29 0x000000006741db79 in Tcl_EvalEx (interp=0x3001f50,
      script=0x22f750 "\n .console mark set insert {end - 1c}\n   tk::ConsoleInsert .console \"\\n\"\n
          tk::ConsoleInvoke\n     break\n    ", numBytes=101, flags=131072)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclBasic.c:4924
  #30 0x00000000618f86dc in Tk_BindEvent (bindPtr=0x33007d0, eventPtr=0x3cfe040, tkwin=0x35558d0,
      numObjects=0, objectPtr=0x22f928) at ./../generic/tkBind.c:1492
  #31 0x000000006192ebde in TkBindEventProc (winPtr=0x35558d0, eventPtr=0x3cfe040)
      at ./../generic/tkCmds.c:316
  #32 0x0000000061940dba in Tk_HandleEvent (eventPtr=0x3cfe040) at ./../generic/tkEvent.c:1363
  #33 0x0000000061941490 in WindowEventProc (evPtr=0x3cfe030, flags=-3)
      at ./../generic/tkEvent.c:1753
  #34 0x000000006754116b in Tcl_ServiceEvent (flags=-3)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclNotify.c:670
  #35 0x0000000067541595 in Tcl_DoOneEvent (flags=-3)
      at d:/CM.git/tcltk86/dcompile/tcl/generic/tclNotify.c:967
  #36 0x0000000061941aa0 in Tk_MainLoop () at ./../generic/tkEvent.c:2131
  #37 0x000000006197a640 in Tk_MainExW (argc=-1, argv=0x365600, appInitProc=0x4015ba <Tcl_AppInit>,
      interp=0x1c94720) at ./../generic/tkMain.c:381
  #38 0x00000000004015af in wWinMain (hInstance=0x400000, hPrevInstance=0x0,
      lpszCmdLine=0x5f389a L"bin/main.tcl", nCmdShow=10) at winMain.c:150
  #39 0x00000000004013c9 in __fu0__set_invalid_parameter_handler ()
  #40 0x0000000000400000 in ?? ()
  #41 0x0000000000000000 in ?? ()


tkt_uuid: c84f660833546b1b84e7fd3aef930c2f17207461
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
severity: Severe
foundin: 8.5.9
private_contact: 4e7dc665ba0390226502e3a0c7904b22da216513
resolution: None
title: Tk crashes when toplevel placed on second display, Mac
comment:
  Placing a Tk top-level window on the second display of a dual display Mac OS system causes a crash when that second display is positioned above the primary display in Mac system display preferences.

  Here is how to produce this crash, tested on Mac OS 10.9.5, with two displays with the primary display positioned below the secondary display (using Mac system display preferences). The following wish command attempts to put the toplevel on the second display.

  $ wish
  % toplevel .t ; wm geometry .t 100x100+500+-500

  It crashes will the following output

  2014-10-08 17:51:32.982 Wish[92437:507] Error (1000) creating window shape
  2014-10-08 17:51:32.983 Wish[92437:507] (
  	0   CoreFoundation                      0x00007fff8ad2525c __exceptionPreprocess + 172
  	1   libobjc.A.dylib                     0x00007fff8a50ae75 objc_exception_throw + 43
  	2   CoreFoundation                      0x00007fff8ad2510c +[NSException raise:format:] + 204
  	3   AppKit                              0x00007fff890159b9 _NSCreateWindowWithOpaqueShape2 + 159
  	4   AppKit                              0x00007fff89014a21 -[NSWindow _commonAwake] + 3720
  	5   AppKit                              0x00007fff890136f7 -[NSWindow _makeKeyRegardlessOfVisibility] + 85
  	6   AppKit                              0x00007fff89013670 -[NSWindow makeKeyAndOrderFront:] + 29
  	7   Tk                                  0x00000001016c8beb XMapWindow + 134
  	8   Tk                                  0x000000010163cafd Tk_MapWindow + 69
  	9   Tk                                  0x0000000101644e6a TkInstallFrameMenu + 271
  	10  Tcl                                 0x00000001017c770d TclServiceIdle + 87
  	11  Tcl                                 0x00000001017aecee Tcl_DoOneEvent + 344
  	12  Tk                                  0x0000000101624a41 Tk_MainLoop + 33
  	13  Tk                                  0x000000010163003f Tk_MainEx + 1445
  	14  Wish                                0x000000010160553f Wish + 9535
  	15  libdyld.dylib                       0x00007fff8a7305fd start + 1
  	16  ???                                 0x0000000000000001 0x0 + 1
  )
  2014-10-08 17:51:32.993 Wish[92437:507] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'
  *** First throw call stack:
  (
  	0   CoreFoundation                      0x00007fff8ad2525c __exceptionPreprocess + 172
  	1   libobjc.A.dylib                     0x00007fff8a50ae75 objc_exception_throw + 43
  	2   CoreFoundation                      0x00007fff8ad2510c +[NSException raise:format:] + 204
  	3   AppKit                              0x00007fff890159b9 _NSCreateWindowWithOpaqueShape2 + 159
  	4   AppKit                              0x00007fff89014a21 -[NSWindow _commonAwake] + 3720
  	5   AppKit                              0x00007fff890136f7 -[NSWindow _makeKeyRegardlessOfVisibility] + 85
  	6   AppKit                              0x00007fff89013670 -[NSWindow makeKeyAndOrderFront:] + 29
  	7   Tk                                  0x00000001016c8beb XMapWindow + 134
  	8   Tk                                  0x000000010163cafd Tk_MapWindow + 69
  	9   Tk                                  0x0000000101644e6a TkInstallFrameMenu + 271
  	10  Tcl                                 0x00000001017c770d TclServiceIdle + 87
  	11  Tcl                                 0x00000001017aecee Tcl_DoOneEvent + 344
  	12  Tk                                  0x0000000101624a41 Tk_MainLoop + 33
  	13  Tk                                  0x000000010163003f Tk_MainEx + 1445
  	14  Wish                                0x000000010160553f Wish + 9535
  	15  libdyld.dylib                       0x00007fff8a7305fd start + 1
  	16  ???                                 0x0000000000000001 0x0 + 1
  )
  libc++abi.dylib: terminating with uncaught exception of type NSException
  /usr/bin/wish: line 2: 92437 Abort trap: 6           "$(dirname $0)/../../System/Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish" "$@"

  This may appear to be a very obscure bug actually it is quite common, the crashes being reported over 50 times for the molecular visualization Tk app I develop, UCSF Chimera.

    https://plato.cgl.ucsf.edu/trac/chimera/ticket/11677

  Also it has been reported as a Python bug when the Tk IDLE shell is used and a tooltip appears

     http://bugs.python.org/issue16177

  Here is why it happens frequently.  For users with dual display Mac systems the second display by default is logically placed to the right of the primary display.  If that display has more vertical pixels then the primary display then the top of that secondary display is above the top of the primary display.  This situation is the norm since the primary display is often a laptop, and the secondary often a large external display with more pixels.  When a toplevel is placed on that secondary display above the position of the top of the primary display then the crash occurs.  In both the Chimera and IDLE crash reports this happens for tooltips shown in popup balloons.  This makes it an especially aggravating bug for the user -- they accidentally hover the mouse over a Tk window triggering a tooltip balloon window which causes a crash before that tooltip is shown.  The user has no idea why the app crashed -- they weren't doing anything.

  It took a long time for me to figure this out.

  You may think the cause is related to the negative y position specified in the geometry "wm geometry .t 100x100+500+-500".  But remarkably if the second display is to the left of the primary and a negative x position is used "wm geometry .t 100x100+-500+500" everything works correctly without a crash.  So the bug is specific to the y axis!

  A search for the routine seen in the crash trace "makeKeyAndOrderFront" in the tk code finds it in one place tkMacOSXSubwindows.c in XMapWindow().  I placed a print statement in TkMacOSXMakeRealWindowExist() in tkMacOSXWm.c to print the requested window geometry at the line
  "    [window setFrame:geometry display:NO];" and the y window position appeared to be correct.  In the Mac native NSWindow api the y coordinates increase from bottom to top of screen, while Tk y coordinates increase from 0 at top of primary screen to bottom.  So Tk has translated the negative y position, such as +500+-500 to 500,1780.  So I did not discern any clue as to the cause of the crash with this debugging.

  A possibly revealing observation is that if the toplevel is displayed on the primary display and then an attempt is made to move it with "wm geometry" to the secondary display, then no crash happens, and the window will not move to the secondary display, and instead is moved to the very bottom of the primary display.  It is only when the toplevel is mapped first on the secondary display that the crash happens.

  Unfortunately (or actually fortunately) I don't know enough about the native Mac window toolkit or the Tk Mac code to understand what is causing this problem.  The reported Apple exception

  'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'

  should mean something to a Mac developer.

  Good luck!  I would love to see a solution to this.  For now I simply will disable tooltips that have negative y positions.


tkt_uuid: 9e487e9f158b3aeda2b92ca75deb3abc04e21a61
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
severity: Critical
foundin: 8.5.x
private_contact: 219192cc5b7de6cef9c96726d1feb29d0382f2dc
resolution: Fixed
title: Fix for tkWinButton to avoid problems in plugin
comment:
  Change the event handler code to prevent it from handling WM_NULL messages. Those are used by some browsers to make sure a plugin is still alive and responsive. Without the modification the plugin is not useable in those browsers.


     case BN_CLICKED: {
          /*
           * OOPS: chromium fires WM_NULL regularly to ping if plugin is still
           * alive. When using an external window (i.e. via the tcl 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_BackgroundException(interp, code);
                  }
                  Tcl_Release((ClientData)interp);
              }
              Tcl_ServiceAll();
              return 0;
          }

      }


tkt_uuid: 7579528afb37fb0041afdf5c615baf6b7c56cd52
type: Bug
status: Open
subsystem: 99. Other
priority: 9 Immediate
severity: Critical
foundin: 8.6.1
private_contact: d9d53f66e8b68b2c247c61dd503e71656c2e82fb
resolution: None
title: tk crashes on Mac when using dead keys
comment:
  I am running ActiveTCL 8.6.1.1 with Python 2.7.8 on Mac OS X 10.9. When using IDLE and pressing ANY dead key (many international keyboards use these for accents or umlauts) on Danish or German keyboard layout, the application crashes.

  I tracked this to Tk being the problem. There was a bug in the old bug tracking system closed in 2011 that looks related.

  This is critical, as we are using Python and IDLE to teach our first year students, of which ca. 30% have a Mac notebook. It is reproducible on all machines.


tkt_uuid: 5029cccdfd0da6265ff4f5ab79d2d240241ac7a7
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Important
foundin: 8.6.2
resolution: None
title: Aqua: menu-22.[345] hang
comment:
  Starting with checkin [51268e7b4f]  the tests menu-22.[345]
  block indefinitely in their [tkwait visibility] commands.


tkt_uuid: 279b027fd74d2e37a0e6104de165c55e6b28f8d0
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
severity: Minor
foundin: 8.6.2
private_contact: 8475f421649231f1e116ac602bea4537d2b027b4
resolution: None
title: Canvas moveto command moves text items to unexpected location
comment:
  I expected the canvas moveto subcommand to move a text item to the specified location. However it ends up at some offset. The following code returns something like 24.0 17.0 instead of 10.0 10.0, as I would have expected.

  canvas .c
  set id [.c create text 0 0 -text hello]
  .c moveto $id 10 10
  puts [.c coords $id]

  It seems that moveto actually uses the bbox coordinates of the text item rather than the coordinates as returned by the coords subcommand, judging by the fact that [.c bbox $id] returns "10 10 39 24" after the moveto.

  If that is the intended behavior of the command, it could at least do with a clearer description in the manual page.


tkt_uuid: 62f1343ad2fd9c77d1f3bf4c9e244e6f33787172
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
severity: Important
foundin: 8.4, 8.6
private_contact: 74b163a427e7cd605d0d65ed74192d4e2755332b
resolution: None
title: Tk textbox not working with "Bengali" set as keyboard input language
comment:
  OS: Windows, TK: 8.4 and 8.6
  If keyboard input is configured for "Bengali" language, the input characters appear as ????. If I type bengali text e.g. in Notepad++ and Copy & Paste it to the Tk textbox the characters are displayed correctly.

  For other keyboard languages like "Arabic" it works correctly.

  I looked into the sources and it seems the problem already occurs where keyboard input is processed (thats why copy & paste works).

  When keyboard input is processed the following script is executed: 
  "\n\ttk::ConsoleInsert %W %A\n    "

  %A is replaced with the pressed key and in case of "Bengali" it always inserts "?".


tkt_uuid: 3c8a969ac152fa7e2e367f2bc00b1acda61482ba
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
severity: Important
foundin: 8.6.2
private_contact: 438e59f1f1c891b29d2528ed82d1e629cecc6336
resolution: None
title: [selection handle] doesn't replace a previously installed utf-8 handler
comment:
  Setting up a selection handler for type STRING also triggers the setting up of the relative UTF-8 handler. When replacing a handler by a subsequent call to [selection handle], the UTF-8 handler is not modified. This results in the old handler to be called even after a new one was installed.

  The following simple script exhibits this behavior:

  ===================================================================================================

  package require Tk

  set i 0
  proc setup {} {
      global i

      switch $i {
          0 { selection handle . h1; incr i }
          1 { selection handle . h2; incr i }
          default { exit }
      }

      selection own .
      puts "Ready..."
  }

  proc h1 {off max} {
      after 0 setup
      return "h1"
  }

  proc h2 {off max} {
      after 0 setup
      return "h2"
  }

  setup

  ===================================================================================================

  This script will copy "h1" twice in the PRIMARY selection.

  The following patch Works For Me (tm), but please double check it before committing.

  ===================================================================================================

  --- generic/tkSelect.c
  +++ generic/tkSelect.c
  @@ -182,35 +182,32 @@
   		winPtr->selHandlerList = selPtr;
   		selPtr->selection = selection;
   		selPtr->target = target;
   		selPtr->format = target; /* We want UTF8_STRING format */
   		selPtr->proc = proc;
  -		if (selPtr->proc == HandleTclCommand) {
  -		    /*
  -		     * The clientData is selection controlled memory, so we
  -		     * should make a copy for this selPtr.
  -		     */
  -
  -		    unsigned cmdInfoLen = Tk_Offset(CommandInfo, command) +
  -			    ((CommandInfo *)clientData)->cmdLength + 1;
  -
  -		    selPtr->clientData = ckalloc(cmdInfoLen);
  -		    memcpy(selPtr->clientData, clientData, cmdInfoLen);
  -		} else {
  -		    selPtr->clientData = clientData;
  -		}
  -		selPtr->size = 8;
   		break;
   	    }
   	    if (selPtr->selection==selection && selPtr->target==target) {
  -		/*
  -		 * Looks like we had a utf-8 target already. Leave it alone.
  -		 */
  +                break;
  +            }
  +	}
   
  -		break;
  -	    }
  +	if (selPtr->proc == HandleTclCommand) {
  +	    /*
  +	     * The clientData is selection controlled memory, so we
  +	     * should make a copy for this selPtr.
  +	     */
  +
  +	    unsigned cmdInfoLen = Tk_Offset(CommandInfo, command) +
  +		((CommandInfo *)clientData)->cmdLength + 1;
  +
  +	    selPtr->clientData = ckalloc(cmdInfoLen);
  +	    memcpy(selPtr->clientData, clientData, cmdInfoLen);
  +	} else {
  +	    selPtr->clientData = clientData;
   	}
  +	selPtr->size = 8;
       }
   }
   

   /*
    *----------------------------------------------------------------------

  ===================================================================================================


tkt_uuid: dd5e4b73e0bfdde045f546dc559e2cbca22ea302
type: Bug
status: Deleted
subsystem: 66. Aqua Window Operations
priority: 5 Medium
severity: Critical
foundin: 8.6.2
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
resolution: None
title: Crash in Tk
comment:
  At random my application crashes with the following stack trace:

  My guess is that it's at least tangentially related to the OTHER Freeing/Garbage Collection we sorted out last week.

  Process:         irmsde [9134]
  Path:            /Users/USER/*/irmsde
  Identifier:      irmsde
  Version:         0
  Code Type:       X86-64 (Native)
  Parent Process:  bash [95738]
  Responsible:     Terminal [75111]
  User ID:         501

  Date/Time:       2014-09-04 14:52:05.746 -0400
  OS Version:      Mac OS X 10.9.4 (13E28)
  Report Version:  11
  Anonymous UUID:  EAB60C7C-4834-FAFF-68F3-0BCB1A2842A1

  Sleep/Wake UUID: 34114FA6-1C8C-46AB-9090-1B5AF783CEC5

  Crashed Thread:  0  Dispatch queue: com.apple.main-thread

  Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
  Exception Codes: EXC_I386_GPFLT

  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
  0   libobjc.A.dylib               	0x00007fff95a3a0e6 objc_release + 22
  1   libobjc.A.dylib               	0x00007fff95a3965a (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 502
  2   com.apple.CoreFoundation      	0x00007fff97151932 _CFAutoreleasePoolPop + 50
  3   com.apple.Foundation          	0x00007fff99aeae17 -[NSAutoreleasePool drain] + 147
  4   irmsde                        	0x000000010bf82c73 -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 264
  5   irmsde                        	0x000000010bf82fc8 TkMacOSXEventsCheckProc + 255
  6   irmsde                        	0x000000010be8327f Tcl_DoOneEvent + 314
  7   irmsde                        	0x000000010be4a034 Tcl_VwaitObjCmd + 153
  8   irmsde                        	0x000000010bdd6f8a TclNRRunCallbacks + 80
  9   irmsde                        	0x000000010bdd8162 TclEvalEx + 1826
  10  irmsde                        	0x000000010be77bad Tcl_FSEvalFileEx + 465
  11  irmsde                        	0x000000010beeb442 Tk_MainEx + 926
  12  irmsde                        	0x000000010bdc6823 main + 82
  13  libdyld.dylib                 	0x00007fff8ef105fd start + 1


tkt_uuid: 514ff64dd00314a5094fd4c872b261819e64ba35
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
severity: Important
foundin: 8.6.1
private_contact: 15d05e35c6efd35720375a1ce4b01373f7d13297
resolution: None
title: canvas rotated text overlap intersection not working
comment:
  <p>Tk 8.6.1 on Windows & Linux.
  <p>The canvas find overlap test is not working for rotated text containing newlines.  The following script illustrates the problem.  When the mouse is immediately over the rotated text, the canvas <b>current</b> tag picks up the item, but the <b>find overlap</b> test for a 9x9 square doesn't.  The overlap only works when the mouse is next to the text, not immediately over it.  No problem for non-rotated text.

  <pre>
  pack [canvas .c -width 400 -height 400] -fill both -expand 1

  bind .c <Motion> {
      puts "Current item: [.c find withtag current]\
          Overlapping [.c find overlapping [expr {%x-4}] [expr {%y-4}]\
             [expr {%x+4}] [expr {%y+4}]]"
  }

  .c create text 200 200 \
      -text "This is line one\nand line two\nand line three here" \
      -font "Helvetica 18" -angle 90
  </pre>


tkt_uuid: a79cca6910533ae60b5bd0c9d96771764e136281
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Severe
foundin: 8.5.15
private_contact: 374a464d4ade3efa5b8895e71dc2d8dfbe39acfe
resolution: Works For Me
title: Event system broken on latest Mac OS X, latest tools -TransformProcessType err
comment:
  I'm new to the Mac but not to Tcl/Tk so please forgive me if I am making a rookie mistake.

  I have a new Mac Pro, OS X 10.9.4, with a new Xcode install downloaded through the App Store yesterday which is v5.1.1.  I'm building without X-windows installed, using defaults, working in the macosx subdirectorys.  To build successfully, the unix/configure and unix/configure.in need to have the garbage collection flag removed:


  RCS file: /usr/cvsroot/tk8.5/unix/configure.in,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -c -r1.4 -r1.5
  *** configure.in	26 Nov 2013 21:59:44 -0000	1.4
  --- configure.in	12 Aug 2014 18:52:05 -0000	1.5
  ***************
  *** 365,371 ****
    if test $tk_aqua = yes; then
        AC_DEFINE(MAC_OSX_TK, 1, [Are we building TkAqua?])
        LIBS="$LIBS -framework Cocoa -framework Carbon -framework IOKit"
  !     EXTRA_CC_SWITCHES='-std=gnu99 -x objective-c -fobjc-gc'
        TK_WINDOWINGSYSTEM=AQUA
        if test -n "${enable_symbols}" -a "${enable_symbols}" != no; then
            AC_DEFINE(TK_MAC_DEBUG, 1, [Are TkAqua debug messages enabled?])
  --- 365,371 ----
    if test $tk_aqua = yes; then
        AC_DEFINE(MAC_OSX_TK, 1, [Are we building TkAqua?])
        LIBS="$LIBS -framework Cocoa -framework Carbon -framework IOKit"
  !     EXTRA_CC_SWITCHES='-std=gnu99 -x objective-c'
        TK_WINDOWINGSYSTEM=AQUA
        if test -n "${enable_symbols}" -a "${enable_symbols}" != no; then
            AC_DEFINE(TK_MAC_DEBUG, 1, [Are TkAqua debug messages enabled?])


   After building and installing,  there is a problem with the event system that manifests itself as windows not being painted properly.  To see the issue run the Tk demos for Animated labels or Animated waves.  

  macbook:unix user$ /usr/local/bin/wish8.5
  % source $tk_library/demos/widget
  % 


  Click on either Animated demo near the end of the dialog.  There is no animated motion of the text or wave.  If you click on the Desktop and back on the demo dialog, you can cause a redraw that shows the changed position.  

  The dialog box with local grab shows a similar problem.  The dialog displays itself as blank with an Ok button.  Click on the Desktop and the dialog repaints to show the message text.

  A fresh build of Tcl/Tk 8.6.1 shows identical buggy behavior.  The builds are 64 bit on a 64 bit system, as is the wish 8.5.9 version that comes pre-installed and which does work properly.

  % parray tcl_platform
  tcl_platform(byteOrder)   = littleEndian
  tcl_platform(machine)     = x86_64
  tcl_platform(os)          = Darwin
  tcl_platform(osVersion)   = 13.3.0
  tcl_platform(platform)    = unix
  tcl_platform(pointerSize) = 8
  tcl_platform(threaded)    = 1
  tcl_platform(user)        = user
  tcl_platform(wordSize)    = 8
  %


tkt_uuid: 9c2f8da61129bb2c0b91e58bbfd317c2f5e4347e
type: RFE
status: Open
subsystem: 01. Bindings
priority: 7 High
severity: Severe
private_contact: 783215cd8ea24f5d409b7c496d6505d264d9be6c
resolution: None
title: Handling simple touch events
comment:
  Feature request:

  Under a windows 8 tablet, or any other touch-enabled device, it is impossible to listen for and handle touch events from the user, such as a pinch to make smaller/bigger, or perhaps swipe left/right.
  The request is to provide bindings to handle these simple touch events.


tkt_uuid: 471cf20e82950d7be1e4ffb62b313d6e47ac7595
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Severe
foundin: 8.5,8.6
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
resolution: Fixed
title: Calls to TkpConfigureMenuEntry Crash under OSX Maverics
comment:
  This problem is best demonstrated by opening TkChat under a recent OSX.

  During initialization, the menu is modified by that program. TkChat used to work properly, but following an OS update, the following stack trace is generated (as soon as the program updates the event loop):

  Process:         wish8.6 [98619]
  Path:            /Users/USER/*/wish8.6
  Identifier:      wish8.6
  Version:         8.6.1 (8.6.1)
  Code Type:       X86-64 (Native)
  Parent Process:  bash [54133]
  Responsible:     Terminal [54128]
  User ID:         501

  Date/Time:       2014-05-30 13:28:30.397 -0400
  OS Version:      Mac OS X 10.9.3 (13D65)
  Report Version:  11
  Anonymous UUID:  EAB60C7C-4834-FAFF-68F3-0BCB1A2842A1

  Sleep/Wake UUID: ECD8FBE4-6257-4974-9AE4-997B8685753F

  Crashed Thread:  0  Dispatch queue: com.apple.main-thread

  Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
  Exception Codes: KERN_INVALID_ADDRESS at 0x00000000646e6124

  VM Regions Near 0x646e6124:
  --> 
      __TEXT                 000000010f418000-000000010f41c000 [   16K] r-x/rwx SM=COW  /Users/USER/*/*.6

  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
  0   libtk8.6.dylib                	0x000000010f4e57f9 TkpConfigureMenuEntry + 1875
  1   libtk8.6.dylib                	0x000000010f465895 MenuWorldChanged + 56
  2   libtk8.6.dylib                	0x000000010f43dd79 RecomputeWidgets + 44
  3   libtk8.6.dylib                	0x000000010f43dd87 RecomputeWidgets + 58
  4   libtcl8.6.dylib               	0x000000010f64579c TclServiceIdle + 87
  5   libtcl8.6.dylib               	0x000000010f62968c Tcl_DoOneEvent + 347
  6   libtk8.6.dylib                	0x000000010f4ed3da -[TKContentView(TKWindowEvent) generateExposeEvents:] + 172
  7   libtk8.6.dylib                	0x000000010f4ed314 -[TKContentView(TKWindowEvent) drawRect:] + 650
  8   com.apple.AppKit              	0x00007fff8fc0804f -[NSView _drawRect:clip:] + 3748
  9   libtk8.6.dylib                	0x000000010f4edc7f -[TKContentView(TKContentViewPrivate) _drawRect:clip:] + 127
  10  com.apple.AppKit              	0x00007fff8fc068c4 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1799
  11  libtk8.6.dylib                	0x000000010f4eda75 -[TKContentView(TKContentViewPrivate) _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 198
  12  com.apple.AppKit              	0x00007fff8fc06ca0 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2787
  13  com.apple.AppKit              	0x00007fff8fc04706 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 841
  14  com.apple.AppKit              	0x00007fff8fc03eb1 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 314
  15  com.apple.AppKit              	0x00007fff8fc00e9f -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2828
  16  com.apple.AppKit              	0x00007fff8fbe02fa -[NSView displayIfNeeded] + 1680
  17  com.apple.AppKit              	0x00007fff8fbf9f0a -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 2024
  18  com.apple.AppKit              	0x00007fff8fbf9480 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 786
  19  com.apple.AppKit              	0x00007fff8fbf9100 -[NSWindow orderWindow:relativeTo:] + 162
  20  libtk8.6.dylib                	0x000000010f4542ea Tk_RestackWindow + 73
  21  libtk8.6.dylib                	0x000000010f430b3e Tk_RaiseObjCmd + 174
  22  libtcl8.6.dylib               	0x000000010f57e52a TclNRRunCallbacks + 80
  23  libtcl8.6.dylib               	0x000000010f57f702 TclEvalEx + 1826
  24  libtcl8.6.dylib               	0x000000010f61df99 Tcl_FSEvalFileEx + 465
  25  libtk8.6.dylib                	0x000000010f445bf7 Tk_MainEx + 1612
  26  wish8.6                       	0x000000010f41b4c5 main + 47
  27  libdyld.dylib                 	0x00007fff8b55e5fd start + 1


tkt_uuid: f846291134efbd8c05ec856b1d1603baad4186ea
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
severity: Minor
foundin: 8.5, 8.6
private_contact: e755306c9ef019bc4ca35d69adcf001dece786ff
resolution: Works For Me
title: entry field loses focus
comment:
  Here's a test program exhibiting the behaviour. 

  Run the program, type something in the first entry field. 
  Press Return. 
  Type some more characters. 
  a) With the destroy statements commented out, further text entry is possible. 
  b) With the destroy statements active, further text entry is not possible. 


  package require Tk 

  variable e1 
  variable e2 

  proc docopy { } { 
    variable e1 
    variable e2 

  #  destroy .i1 
  #  destroy .i2 

    if { ! [winfo exists .l1 ] } { 
      ttk::label .l1 -text $e1 
      ttk::label .l2 -text $e2 
    } else { 
      .l1 configure -text $e1 
      .l2 configure -text $e2 
    } 
    grid .l1  -in .r 
    grid .l2 -in .r 
  } 

  set e1 {def} 
  set e2 {456} 
  ttk::entry .e1 -width 10 -textvariable e1 
  ttk::entry .e2 -width 10 -textvariable e2 
  ttk::button .b1 -text Copy -command docopy 
  ttk::label .i1 -text {This is extra text} 
  ttk::label .i2 -text {This is extra text} 
  ttk::frame .l 
  ttk::frame .r 
  grid .l .r 
  grid .e1 -in .l 
  grid .e2 -in .l 
  grid .b1 -in .l 
  grid .i1 -in .r 
  grid .i2 -in .r 
  # why are these necessary? 
  lower .l 
  lower .r 
  bind .e1 <Return> docopy


tkt_uuid: 3547356fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: [tk busy] (8.6) bug with menu on toplevel
comment:
  The 8.6 [tk busy] command does not cause menu's attached to toplevels via configure -menu (menu widget name) to become "busy" when it makes the rest of the toplevel busy.

  I.e., run the following in an 8.6 interpreter:

  button .b -text "Button\n.b" -command [ puts stderr "Button .b" ]
  pack .b

  menu .mbar

  menu .mbar.file

  .mbar.file add command -label "Open" -command [ list puts stderr "Open" ]

  .mbar.file add command -label "Close" -command [ list puts stderr "Close" ]

  .mbar add cascade -menu .mbar.file -label File

  . configure -menu .mbar

  tk busy .

  Not that the button is "busy" and unavailable, but the menu attached to . via the -menu option is still available, and can be accessed.

  The busy.n man page makes no mention of what should be the expected behavior of performing [tk busy .toplevel] when .toplevel has a -menu attached.  I was expecting that the attached menu would also be made busy along with the rest of the toplevel window.

  I tested this with 8.6b2 under Linux and with an 8.6b1 starkit under windows.  Both Linux and Windows exhibited the bug.


tkt_uuid: 45bc2252066b706bfea8553c34b13a92ca3bbb3d
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Important
foundin: 8.5
private_contact: 4a267845b96d18ced148980dad8c23b791785018
resolution: Accepted
title: Display artifacts when scrolling a Text widget on OS X
comment:
  On OS X, when scrolling a Text widget with embedded images, each image will leave a "vapor trail" comprised of many copies of the image, sometimes overlapping.

  I will upload a screen shot showing the artifacts, and a patch which appears to fix the problem.

  The basic issue seems to be that when an image is displayed on an NSView, it is also created as a subview.  This causes the Appkit to repeatedly display the subview image in its original position, while earlier copies of the image are scrolled into different locations and remain in the display.

  The patch adds a damage region for each embedded image and also forces redisplay of each image after the scroll.  It is hard to verify from the terse Apple documentation that this is the correct procedure but, empirically, it works.


tkt_uuid: 99b84e49ffe486949ef08fd4b68feb29bb3e9002
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
severity: Critical
foundin: 8.5.15.1, 8.6.1
private_contact: 4a267845b96d18ced148980dad8c23b791785018
resolution: Accepted
title: PhotoImages do not support alpha channel on OSX Mavericks
comment:
  PhotoImages with alpha channel data do not work at all on OS X Mavericks.

  This bug was discussed in this thread:
   http://sourceforge.net/p/tcl/mailman/message/31694269/
  where the problem was correctly isolated in the XCopyArea function.  The implementation of XCopyArea uses NSCopyBits which requires as one of its arguments a GState.  However, in Mavericks Apple changed the allocateGState function to be a no-op, and this makes NSCopyBits unusable.

  The function TkImgPhotoDisplay calls XGetImage which, in the macosx version, in turn calls XCopyArea.  Since XGetImage is unable to retrieve the background image to be blended with the PhotoImage, TkImagePhotoDisplay cannot support the alpha channel. 

  I have written new implementations of XCopyArea and XGetImage.  Since I don't see any way of uploading a patch on this form, and since my patch is too long to paste here, I will send the patch directly to some of the developers.

  Marc Culler


tkt_uuid: aefc556471df7ffb785e62c28e3a440d8165b9f4
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 8
severity: Critical
foundin: All
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
resolution: Fixed
title: Tk Cocoa, error: garbage collection is no longer supported
comment:
  With Xcode 5.1, Apple has discontinued support for Garbage Collection. After configuring, all attempts to compile Tk (or Tk based extension) dies on the first file with:

  error: garbage collection is no longer supported
  make[1]: *** [tkStubLib.o] Error 1
  make: *** [tcltk] Error 2

  Apple recommends transitioning to Automatic Reference Counting (ARC). The process is described at:
  https://developer.apple.com/library/mac/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226

  Essentially the memory access routines that trade in Native Cocoa objects need a rewrite to support the new API. (As do extensions like Canvas3d which also trade in native Cocoa objects.)

  The native Tk for Cocoa will not compile on OSX with Xcode 5.1 or above until this is fixed. Already compiled binaries seem not to be affected. Tcl and Tk (using X11 emulation) are not affected.


tkt_uuid: a35d6d5b5c5e6f88efbd9c9bd6347aa455198a28
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
severity: Important
foundin: 8.5, 8.6
private_contact: 761898199aaa965dbaf1f38baac2df6f9d13db48
resolution: Works For Me
title: More Tk redraw issues on OS X Mavericks
comment:
  Apologies in advance for any botching of terminology... merely a user of Tkinter, and unfamiliar with TCL, and so on.

  I am having issues with secondary windows not closing themselves on OS X Mavericks 10.9.2. This seems to be a bug similar to previous fixes for Mavericks where events weren't being updated.

  Initially, I thought I was dealing with the same problem described in various places, e.g.:
  * http://core.tcl.tk/tk/tktview?name=53f7a1b553
  * http://bugs.python.org/issue19373
  * https://github.com/Homebrew/homebrew/issues/25974
  * http://grokbase.com/t/python/tkinter-discuss/13aqwsf5hd/idle-bug-under-macosx-maverick

  I played with installing the latest ActiveTcl (both 8.5.19 and 8.6.1, iirc). I tried the tcl-tk package in homebrew, and then reinstalling brew's Python with the --with-brewed-tk flag.  I see these issues both with 2.7.6 from brew, and from the OS X-built-in 2.7.5 versions of Python.

  (as a sidenote, I find it weird how Tk uses the __version__ variable for a revision number, and then only lists major.minor versions in TclVersion/TkVersion)

  From the github link, the Tkinter._test() method was suggested. I tried it on 10.9.1 and 10.9.2, and saw that that issue (not displaying in 10.9.1) is indeed fixed on my 10.9.2 machine. i.e.: `python -c "import Tkinter; Tkinter._test()`

  So I conclude this is probably a different (but similar) bug. I haven't been able to find anything more via googling.

  I have created an example with the code at the end of this report, which reproduces my issue on the 10.9.1 and 10.9.2 machines, and runs fine on a 10.8.5 machine. I invoke a tkMessageBox upon the start of my program, and upon clicking a button, the window fails to close, the button's appearance is stuck in the "down" view, and the original window works fine (the quit button).

  In addition to seeing the issue with various tkMessageBox methods, I've also had issues with other secondary windows in the full app that I pared down to the included example. Some behaviors not illustrated in my example, but observed:
  * Multiple tkMessageBox windows can be visisble at once
  * A Tkinter.Toplevel window does not appear by itself.
  * If a button press triggers a tkFileDialog, any tkMessageBox window closes properly

  I welcome any insights. Let me know if I can provide more info.


  ----------------------------------------

  from Tkinter import *
  from tkMessageBox import askyesno, showinfo, askokcancel, showwarning

  class TkMonitorDialog(Frame):
      """The main window"""

      def __init__(self, root):
          Frame.__init__(self, root)
          root.title("App")

          # quit button
          self.qbutton = Button(self, text="Quit", command=root.destroy)
          self.qbutton.pack()

      def mystart(self):
          #showinfo("Click button",
          #askokcancel("Click button",
          #showwarning("Click button",
          askyesno("Click button",
                  "If a button is clicked, does not close on"
                  "Mavericks 10.9.1 or 10.9.2, but works on 10.8.5."
                  "But Quit button still works in main window.")
          return

  if __name__ == '__main__':
      root = Tk()
      x = TkMonitorDialog(root)
      x.pack()
      x.mystart()
      print 'ok started.'
      root.mainloop()


tkt_uuid: 08d16a673a0015caa010ec544bb29e3b17774029
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Severe
foundin: 8.6, 8.6
private_contact: 5846a328c39e4967aaeb56d4e03d3e783e2dd1b8
resolution: Out of Date
title: Combo Boxes Crash under OSX Maverics
comment:
  Wish is now crashing under OSX maverics whenever a user clicks on a combobox. The stack trace is as follows:

  2014-06-02 12:50:07.256 irmsde[10202:507] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'
  *** First throw call stack:
  (
  	0   CoreFoundation                      0x00007fff95d8025c __exceptionPreprocess + 172
  	1   libobjc.A.dylib                     0x00007fff91f42e75 objc_exception_throw + 43
  	2   CoreFoundation                      0x00007fff95d8010c +[NSException raise:format:] + 204
  	3   AppKit                              0x00007fff8fd32e97 _NXCreateWindowWithStyleMask + 132
  	4   AppKit                              0x00007fff8fd32d7d _NSCreateWindow + 64
  	5   AppKit                              0x00007fff8fbeb74c -[NSWindow _commonAwake] + 2963
  	6   AppKit                              0x00007fff8fbea717 -[NSWindow _makeKeyRegardlessOfVisibility] + 85
  	7   AppKit                              0x00007fff8fbea690 -[NSWindow makeKeyAndOrderFront:] + 29
  	8   irmsde                              0x0000000107f6ce86 XMapWindow + 134
  	9   irmsde                              0x0000000107ee011e Tk_MapWindow + 69
  	10  irmsde                              0x0000000107f748c4 TkpWmSetState + 171
  	11  irmsde                              0x0000000107f733df Tk_WmObjCmd + 11648
  	12  irmsde                              0x0000000107dc0d7e TclNRRunCallbacks + 80
  	13  irmsde                              0x0000000107dc1f56 TclEvalEx + 1826
  	14  irmsde                              0x0000000107dc182e Tcl_EvalEx + 26
  	15  irmsde                              0x0000000107ebc5e1 Tk_BindEvent + 3751
  	16  irmsde                              0x0000000107ec13a3 TkBindEventProc + 324
  	17  irmsde                              0x0000000107ec7823 Tk_HandleEvent + 1049
  	18  irmsde                              0x0000000107ec7c89 WindowEventProc + 85
  	19  irmsde                              0x0000000107e6b874 Tcl_ServiceEvent + 140
  	20  irmsde                              0x0000000107e6bb0d Tcl_DoOneEvent + 308
  	21  irmsde                              0x0000000107e33858 Tcl_VwaitObjCmd + 153
  	22  irmsde                              0x0000000107dc0d7e TclNRRunCallbacks + 80
  	23  irmsde                              0x0000000107dc1f56 TclEvalEx + 1826
  	24  irmsde                              0x0000000107e60465 Tcl_FSEvalFileEx + 465
  	25  irmsde                              0x0000000107ed3a9e Tk_MainEx + 926
  	26  irmsde                              0x0000000107db0617 main + 82
  	27  libdyld.dylib                       0x00007fff8b55e5fd start + 1
  	28  ???                                 0x0000000000000003 0x0 + 3
  )
  libc++abi.dylib: terminating with uncaught exception of type NSException


tkt_uuid: a80f5d7165a4911af4048b46a78e4ec4daeac079
type: Bug
status: Closed
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Important
foundin: 8.6.1
private_contact: 40457e5afe8a36186aa645530f63f3f03472c366
resolution: Fixed
title: combobox selection bug
comment:
  tested on Windows XP and Windows 7 from wish86 using Tcl 8.6.1:

  grid [ttk::combobox .country -textvariable country]
  .country configure -values [list USA Canada Australia]

  tested on Windows XP python tkinter using Tcl 8.5.11:

  from tkinter import Tk
  from tkinter import ttk
  root = Tk()
  ttk.Combobox(root, values=['USA', 'Canada', 'Australia']).grid(row=0, column=1)
  root.mainloop()

  1) Enter some text into the text entry area of the combobox

  2) Drag the mouse from inside the text entry area of the combobox to a point to the left of combobox.  This selects the entered text from the start of the drag to the begining of the entered text.

  3) Select one of the drop-down items with the mouse.

  The combobox is now in a buggy state where left arrow, right arrow, HOME, and END do nothing.  The cursor does not move and the highlight does not change.  Typing a character replaces the highlighted text with the character, as expected, but the highlight becomes locked on the new character so typing additional characters just replaces the previously typed character with the new character.  Nothing you can do with the keyboard will get it out of this buggy state.  Even making selections from the drop-down with keyboard or mouse will not get it out.  The only way to get it to start behaving well again is to click (or double-click) with the mouse inside the text area.

  Note that dragging from the text entry area to a point to the right of the combobox then selecting from the drop-down with the mouse has similar buggy behavior.

  If you drag from the text entry area to the left of the combobox before entering any text, then make a selection from the drop-down with the mouse, then type characters, each character will be entered to the left of the previous character so you will be typing backwards.


tkt_uuid: 0917069c05e9c354a27c8105a7a22264090b9274
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 7 High
severity: Minor
foundin: 8.5.15 and 8.6.1
private_contact: bae840f83030d7c43a3da90e5b0e5b5159656e6e
resolution: None
title: tk on HDPI displays renders tiny fonts
comment:
  I'm trying to run tk application (tkabber) on High DPI display (236 DPI in my case) under Linux. tk seems to be DPI unaware in this aspect since it renders fonts in tiny sizes like this:

  http://ixion.pld-linux.org/~arekm/tkabber-tiny-fonts.jpg

  (look at menus, writting text area - these are tiny and unconfigurable in tkabber; fortunately roster and main window area have fonts configurable, so I increased these there should be no need to do that)

  Anyway tk should be DPI aware and render fonts properly according to DPI. Right now we have a situation where using the same tk application on different machines (laptops) will give us unusable results in some cases.

  From #tcl irc:
  21:47 <@ijchain> <schelte> The sources say: "Font size specified in pixels on X11, not points. This is Theoretically Wrong, but in practice works better; using points leads to 
                   huge inconsistencies across different servers."
  21:48 <@ijchain> <schelte> It looks like it is now also "Wrong in practice" and should possibly be reconsidered.


tkt_uuid: 8a270c661cb7829dce10f89777f3f4a23fabec8c
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Minor
foundin: 8.6.0
private_contact: d4bbf66f445929e627fc15cea06ac36f09044260
resolution: None
title: ttk::treeview -selectmode doesn't match [listbox]
comment:
  There's no themed [listbox], but [ttk::treeview]s can be set up to do more or less the same job. However, although they both have the -selectmode option, they work differently; in [listbox], -selectmode single allows you to select a single row, while -selectmode browse also lets you select a single row, but also lets you drag the row to reorder elements.

  In [ttk::treeview], there's no "single", and "browse" doesn't allow dragging. It would be nice if the treeview's "browse" was renamed "single", and a new "browse" mode that allowed dragging, to match the one in [listbox], was added.


tkt_uuid: a2abc45ee636463eccff3b7255de688619fa51a3
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
severity: Minor
foundin: 8.6.1
private_contact: e6e0da3db38bd7f7aaef501760314ad0221f3e23
resolution: None
title: Cursor at wrong position after event generate -warp on secondary screen
comment:
  When using the -warp option with event generate for a widget that is on a different screen from the main application, it takes the -x and -y as absolute positions, instead of relative to the specified widget as it does on the main screen.

  Example script:

  package require Tk

  set screen2 [lindex $argv 0]
  if {$screen2 eq ""} {set screen2 :1}

  toplevel .t -screen $screen2

  proc cursor {w} {
      puts "Widget: [winfo rootx $w],[winfo rooty $w]"
      event generate $w <Motion> -x 100 -y 100 -warp 1
      update idletasks
      puts "Cursor: [join [winfo pointerxy $w] ,]\n"
  }

  after 10000 {
      cursor .
      cursor .t
      exit
  }

  This should report a cursor position that is 100 higher than the widget position in both x and y direction. It is correct for the main screen, but reports 100,100 for the secondary screen.

  This works correctly with Tk 8.5.15, but not with Tk 8.6.0.

  Tk 8.5.15:
  Widget: 796,94
  Cursor: 896,194

  Widget: 172,216
  Cursor: 272,316

  Tk 8.6.0:
  Widget: 820,142
  Cursor: 920,242

  Widget: 196,264
  Cursor: 100,100


  OS: OpenSUSE linux 13.1 KDE 4.11.2, kernel 3.11.6.


tkt_uuid: 3107390fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: Tk 8.5.9 fails to build "wish" on FreeBSD 8.1
comment:
  Tk 8.5.9 and possibly others, build "libtk85.so.1", and then try to link "wish" against it using "-ltk85".  This fails.  Copying "libtk85.so.1" to "libtk85.so" after "gmake" fails and re-running "gmake" yields a working "wish"

  Build log attached


tkt_uuid: 1844430fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: cygwin make fails in 8.4.14-8.5b3
comment:
  When building tk in the cygwin environment, the Makefile dependencies should use the cygwin file names not the Windows native ones.  Currently, the following error message is given:

  Makefile:419: *** target pattern contains no `%'.  Stop.

  And if that one is fixed, there's an other one on line 425 (the line numbers are from tk 8.5b3).

  Attached is a patch that changes the two dependencies on
  TCL_SRC_DIR_NATIVE to TCL_SRC_DIR in tk-src/win/Makefile.in.


tkt_uuid: 3477449fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: Patch - segfault when mark out of -startline/-endline range
comment:
  The attached patch fixes item 1630271:

  https://sourceforge.net/tracker/?func=detail&aid=1630271&group_id=12997&atid=112997

  The patch is against the latest core-8-5-branch (from today).


tkt_uuid: 220822ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: final: 8.0.5
resolution: Fixed
title: some canvas polygons leave trails when moved
comment:
  OriginalBugID: 2251 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-16'
  LastModified: '1999-08-21'
  Severity: MED
  Status: Assigned
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2426 2250
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: Power PC


  Name:
  Michael Halle

  ReproducibleScript:
  Load the canvas item types demo.  Look for the four-pointed star shaped
      object
      in the "polygons" section. Drag it.

  ObservedBehavior:
  Its corners leave trails that are not erased.



  This seems to be a Mac only problem, but it may have to due with
  incorrect calculation in the bounding code for Macs, as exists for
  ovals on Windows (bug 2426). 
  -- 08/21/1999 hobbs


tkt_uuid: 3314770fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5.9
resolution: Fixed
title: regression - Windows file dialogs not resizable
comment:
  In changes to support the latest look in Windows, we lost the ability to resize the dialog.  I think the only thing that needs to be added is OFN_ENABLESIZING to the ofn.Flags in GetFileNameA|W.


tkt_uuid: 3083971fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 20. [tk_optionMenu]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: tk_optionMenu popup in wrong location on extended desktop
comment:
  I'm running ActiveTcl 8.5.7 on WinXP with an extended desktop. The main screen (the one with the taskbar) is to the right and somewhat lower than the secondary screen. When a tk_optionMenu is on the part of the secondary screen that's above the main screen, then the menu pops up too low... in fact, it's at the top edge of the main screen, as you can see in the attached screenshot. If the tk_optionMenu is below the top of the main screen (on either screen) then it pops up where expected.


tkt_uuid: 220954ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Works For Me
title: button-release events get lost when target window is destroy
comment:
  OriginalBugID: 6293 Bug
  Version: 8.3
  SubmitDate: '2000-09-21'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-Red Hat
  OSVersion: redhat 6.0
  Machine: dell precision 410


  Name:
  Jonas Beskow

  Comments:
  This bug was introduced in tk 8.3 and is also present 8.4a1. There is a
      passage at the top of Tk_HandleEvent() that seems to be responsible
      (when it is commented out, the errant behavoiur goes away):

          /*
           * Hack for simulated X-events: Correct the state field
           * of the event record to match with the ButtonPress
           * and ButtonRelease events.
           */

          if (eventPtr->type==ButtonPress) {
            dispPtr = TkGetDisplay(eventPtr->xbutton.display);
      eventPtr->xbutton.state |= dispPtr->mouseButtonState;
      switch (eventPtr->xbutton.button) {
          case 1: dispPtr->mouseButtonState |= Button1Mask; break; 
          case 2: dispPtr->mouseButtonState |= Button2Mask; break; 
          case 3: dispPtr->mouseButtonState |= Button3Mask; break; 
      }
          } else if (eventPtr->type==ButtonRelease) {
      dispPtr = TkGetDisplay(eventPtr->xbutton.display);
      switch (eventPtr->xbutton.button) {
          case 1: dispPtr->mouseButtonState &= ~Button1Mask; break; 
          case 2: dispPtr->mouseButtonState &= ~Button2Mask; break; 
          case 3: dispPtr->mouseButtonState &= ~Button3Mask; break; 
      }
      eventPtr->xbutton.state |= dispPtr->mouseButtonState;
          } else if (eventPtr->type==MotionNotify) {

      dispPtr = TkGetDisplay(eventPtr->xmotion.display);
      eventPtr->xmotion.state |= dispPtr->mouseButtonState;
          }

  ReproducibleScript:
  toplevel .x
  pack [label .x.l -text "double-click me!"]

  bind .x.l <Double-Button-1> [list destroy .x]
  bind . <B1-Motion> {puts "B1-Motion event"}

  # run the above lines, double-click on the label
  # when the labe-window goes away, move pointer over main window with no button pressed

  ObservedBehavior:
  B1-motion events are fired when no button is pressed

  DesiredBehavior:
  B1-motion events should not fire when no button is pressed


tkt_uuid: 3505358fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 29. Colormaps and Visuals
priority: 6
foundin: obsolete: 8.5.10
resolution: Fixed
title: invalid color name "#f75df642f527"
comment:
  Environment openSuse Linux 11.2, TclTk 8.5.11 latest trunk;
  In windows the bug is not existent.

  I see the bug when creating a tabnotebook which throws the error:
  invalid color name "#f75df642f527"
  (processing "-fill" option)
  invoked from within
  "$itk_component(canvas) create line [expr {floor(0 + ($itk_option(-borderwidth)/2.0))}] [expr {floor(0 + ($itk_option(-borderwidth)/2.0))}] $wid [e..."
  (object "::.cCMainWindow0.shellchildsite.eFrame.workFrame" method "::iwidgets::Tabnotebook::_redrawBorder" body line 14)
  invoked from within
  "_redrawBorder $wid $hgt"

  The color name comes from:
  - procedure [topShadow {bgColor}]
  - which calls [set hsb [rgbToHsb [winfo rgb . $bgColor]]]
  - ... and a lot more ...

  There is no bug in fossil checkout c309fddc73

  thx


tkt_uuid: 3520912fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.11
resolution: Fixed
title: Cocoa and crash in notifier
comment:
  The current build of the tk-cocoa-8-5-backport branch crashes on startup (before any evaluation of scripts) probably in the notifier. Similar problems experienced on 8.6.


tkt_uuid: 3600260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Errors in new virtual event definitions
comment:
  library/tk.tcl (trunk and core-8-6-0)

  The virtual event <<SelectPrevPara>> is defined twice for each windowing system.
  In each case, the second definition should be for <<SelectNextPara>>.


tkt_uuid: 3021557fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.6b2
resolution: None
title: Moving the cursor in elided text freezes Tk
comment:
  wish freezes when moving the cursor in a text widget containing elided text.

  To reproduce, just paste the following in wish:

  package require Tk
  info patchlevel  ;# spits 8.5.7 for me (ActiveState version)
  text .t
  pack .t
  .t insert end "Fifteen men on the Dead Man's Chest\n"
  .t insert end "Yo-ho-ho, and a bottle of rum!\n"
  .t insert end "Drink and the devil had done for the rest \n"
  .t insert end "Yo-ho-ho, and a bottle of rum!\n"
  .t insert end "\nFifteen men on the Dead Man's Chest\n"
  .t insert end "a poem by Robert Louis Stevenson\n"
  .t tag add hidden 2.10 3.15
  .t tag configure hidden -elide true
  # now :
  #  1. click in the text widget to place the cursor just
  #     before the letter D of the word "Dead" (1st line)
  #  2. press the down arrow once on the keyboard
  #  3. press the up arrow once on the keyboard
  #
  # ==> wish is frozen with 100% CPU

  This happens for me on Win Vista 64 bits OS with the ActiveState binary distribution of Tcl/Tk version 8.5.7 (32 bits).

  It also happens under ActiveState's 8.6 beta 3, windows 7 64 bit.


tkt_uuid: 3080953fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 8
foundin: None
resolution: Fixed
title: Malformed Unicode characters in %A substitution
comment:
  %A substitute in bind scripts is broken, contains the unicode character, but in wrong encoding.
  For example "\u015b" (letter ś) becomes two-character string "\x5b\x01"

  System is Windows XP, tcl/tk is latest from CVS. Version from 2010-09-21 doesn't have bug.


tkt_uuid: 897516ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Out of Date
title: Static build needs more 2 ole libs for tkWinSend
comment:
  nmake -f makefile.vc OPTS=static with 8.5a0 produced 
  link errors. I goggled for the symbols and added
  ole32.lib and oleaut32.lib to the assignment of
  baselibs in makefile.vc

  <baselibs  = kernel32.lib user32.lib
  >baselibs  = kernel32.lib user32.lib ole32.lib oleaut32.lib

  The static build now completes w/o error.

  I'm on Win2000 but I am using a very old copy of MSVC
  which could be a factor:
  Microsoft (R) 32-bit C/C++ Standard Compiler Version 
  12.00.8168 for 80x86
  Copyright (C) Microsoft Corp 1984-1998. All rights 
  reserved.


  Cheers,
  Roy

  ======= ERROR OUTPUT BELOW ======
  (corrected by adding libs as described above)

  ....
  stubs.c
  lib -nologo -out:".\Release\tk85s.lib" 
  @c:\tmp\nme10728.

  link -nologo -machine:IX86 -release -opt:ref -
  opt:icf,3 -subsystem:windows -
  out:".\Release\wish85s.exe" kernel32.lib user32.lib 
  gdi32.lib "..\..\tcl\win\Release\tcl85s.lib" .\Release\tk_Sta
  tic\winMain.obj .\Release\tk_Static\wish.res ".\Release\tk
  85s.lib"
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CoGetMalloc@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CreateBindCtx@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__GetRunningObjectTable@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CreateFileMoniker@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__VariantClear@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__SysFreeString@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__VariantChangeType@16
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__SysAllocString@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__VariantInit@4
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__SetErrorInfo@8
  tk85s.lib(tkWinSend.obj) : error LNK2001: unresolved 
  external symbol __imp__CreateErrorInfo@4
  .\Release\wish85s.exe : fatal error LNK1120: 11 
  unresolved externals


tkt_uuid: 2999920fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Rejected
title: Internal Virtual event string operations
comment:
  In tkBind.c, every translation from virtual event
  string to Tk_Uid consists of the stripping of "<<"
  and ">>" from the begin and the end. In the
  translation back, those are added again. This
  is inefficient, just for saving 4 characters for each
  event in the Tk_Uid table.

  So, here is a patch. Advantages:
  - GetAllVirtualEvents does not need a Tcl_DString
    any more
  - GetVirtualEventUid does not longer change its
    virtString argument

  Any objections? Needless to say that all tests
  still pass after applying this patch.


tkt_uuid: 3541305fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: Xfree/Xsync... shoulc not be macros
comment:
  In order to allow win32 extensions that use
  Xfree/Xsync ... to run under Cygwin as well
  (See presentation Eurotcl 2012), they
  should not be macro's but functions.

  In Tk 8.6 that's already done, but in 8.4/8.5
  it's possible to do the same thing, only the
  macro should detect whether the related
  stub functions are available or not.
  (Tk8.5.12+ has it, but not earlier versions)

  The stub entry tkIntStubsPtr->tkBindDeadWindow
  can be used for that. If it's NULL, then
  the stub functions are available (This
  stub entry is purposely removed on Cygwin
  8.4/8.5, and completely in 8.6, just because
  it serves no purpose)

  Solution:
  #ifdef USE_TK_STUBS
  #define XFree(data) (tkIntStubsPtr->tkBindDeadWindow? ((data)? (ckfree((char *) (data)), 0): 0): tkIntXlibStubsPtr->xFree(data))
  #else
  .... original definition
  #elseif


tkt_uuid: 3568760fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk documentation fails to build (patch provided)
comment:
  nmake -f makefile.vc htmlhelp .....  fails to build.

  Patch:

  --- makefile.vc
  +++ makefile.vc
  @@ -695,11 +695,11 @@
   CHMFILE=$(HTMLDIR)\$(HTMLBASE).chm

   htmlhelp: chmsetup $(CHMFILE)

   $(CHMFILE): $(DOCDIR)\*
  -       @$(TCLSH) $(TOOLSDIR)\tcltk-man2html.tcl
  +       @$(TCLSH) $(TCLTOOLSDIR)\tcltk-man2html.tcl
          @echo Compiling HTML help project
          @$(HHC) <<$(HHPFILE) >NUL
   [OPTIONS]
   Compatibility=1.1 or later
   Compiled file=$(HTMLBASE).chm


tkt_uuid: 3176239fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: obsolete: 8.6b2
resolution: Fixed
title: control-MouseWheel causes segv
comment:
  On X11, on Ubuntu 10.10 with Tcl/Tk 8.6b1.1 (2011-1-18 version, can't get latest CVS version due to sourceforge breakin), the attached ctrlwheelbug.tcl script will cause a Tcl/Tk crash in XLookupSymbol if the user presses control-MouseWheel.  MouseWheel events without the control key do not have problems.  The same script works with Tcl/Tk 8.4.19 and 8.5.8.  Looking through the other bug reports, this might be the same bug as #3117468.


tkt_uuid: 3555644fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Fixed
title: Better use of virtual events.
comment:
  Some observations:
  - In listbox.tcl, <Control-Left> is bound to scrolling back a page, but on
    Mac it should be bound to <Option-Left>
  - in console,tcl <Control-a> and <Home> are both bound to the same
    action.
  - many more of similar examples, all related to the 6 virtual events
    mentioned below.

  All of those (and more) can be solved by using the virtual events
  <<PrevChar>>, <<NextChar>>, <<PrevWord>>, <<NextWord>>
  <<LineStart>> and <<LineEnd>> in stead of <Left>, <Right>,
  <Control-Left>, <Control-Right>, <Home/Control-Key-a> and
  <End/Control-Key-e> in all bindings.


tkt_uuid: 3027438fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Tk_Main calls Tcl_CreateInterp before Tcl_FindExecutable
comment:
  Suggestion: move the Tcl_CreateInterp call out
  of Tk_MainEx into the Tk_Main macro. The macro
  then could look like:

  #define Tk_Main(argc, argv, proc) Tk_MainEx(argc, argv, proc, \
  (Tcl_FindExecutable(argv[0]), Tcl_CreateInterp()))

  patch attached


tkt_uuid: 3160703fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Add unicode support for tk_chooseDirectory on Windows
comment:
  tk_chooseDirectory does not handle unicode directory names properly on Windows - for example on a Windows box this fails:
  % file mkdir c:/\u2345
  % tk_chooseDirectory -initialdir C:/\u2345 ; # this goes to "My Computer" while "C:/" works

  When choosing directory with non-ansi chars - the following is returned:
  C:/?

  Attached is a sample patch (ported from 8.5a4 patch BitRock used) so it might miss some features added in 8.5 and 8.6 development.

  This can be reimplemented and/or #ifdef-ed to properly support Windows CE, if needed.


tkt_uuid: 2768586fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Menu posting problem on dual monitors
comment:
  This bug happens on Windows in dual monitor mode, when the second monitor is placed above the primary monitor. Note that this means that the second monitor has negative y coordinates.
  When posting a menu on the second monitor (either from a menubutton or directly with tk_popup), the menu is actually displayed on the primary monitor.

  The reason can be found in the procedures ::tk::MbPost and ::tk::PostOverPoint. These contains checks like:

  if {$y < 0} {
      set y 0
  }

  Which makes it impossible to post menus at negative y coordinates.


tkt_uuid: 3471873fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: mark next/prev with peer text widgets
comment:
  The attached patch fixes items 3288113 and 3288121:

  Missing marks when searching through mark next from peers:
    https://sourceforge.net/tracker/?func=detail&aid=3288113&group_id=12997&atid=112997

  Endless loop with mark prev from peer text widget:
    https://sourceforge.net/tracker/?func=detail&aid=3288121&group_id=12997&atid=112997

  The patch is against the latest Fossil sources.

  The existing textMark.test suite passes with no failure.
  Plus I have added one test item for each issue above that the patch is fixing.


tkt_uuid: 3518311fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: Make fails: tkMain.c points missing tclInt.h
comment:
  Version: TK 8.5.11
  OS: Slackware64
  TCL: tcl8.5.11
  Description: The configure runs fine, but the make fails to build.

  uname -a
  Linux darkstar 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

  gcc -c -O2  -pipe  -Wall -fPIC -I/home/user/tk8.5.11/unix/../unix -I/home/user/tk8.5.11/unix/../generic -I/home/user/tk8.5.11/unix/../bitmaps -I/home/user/tcl8.5.11/generic -I/home/user/tcl8.5.11/unix  -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tk\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DHAVE_XSS=1 -DHAVE_LIBXFT=1 -DHAVE_XFT=1      -DTCL_NO_DEPRECATED  -DUSE_TCL_STUBS  /home/user/tk8.5.11/unix/../generic/tkMain.c
  /home/user/tk8.5.11/unix/../generic/tkMain.c:17:20: fatal error: tclInt.h: No such file or directory
  compilation terminated.
  make: *** [tkMain.o] Error 1


tkt_uuid: 2312027fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: Tk_CreateImageType and Tk_CreateOldImageType not thread safe
comment:
  Tk_CreateImageType and Tk_CreateOldImageType not thread safe.

  When modifying those functions for CONSTification (TIP #27), it was
  noted that they don't make a copy of the Tk_PhotoImageFormat
  strucuture for each thread, although the first pointer of it was stored
  in thread specific data. This means that calling a second
  Tk_CreateImageType in another thread will currupt the linked list
  in the other thread.

  The first attempt to fix this, lead to [Bug 2265860]: new test failures,
  but modifying the Tk_FindPhoto() function fixed this.

  This bug is already fixed in trunk now, to be backported


tkt_uuid: 3600251fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: current: 8.6.0
resolution: Fixed
title: Inappropriate replacement of Mac binding
comment:
  The (trunk and core-8-6-0) library/text.tcl replaced a Mac-only binding to <Control-v> with a binding to <<Paste>>.

  This is inappropriate because on the Mac, <Control-v> does not correspond to <<Paste>>.  The Mac-only binding to <Control-v> scrolls down one page.  This unusual binding is still found in some non-Tk Mac applications.

  I expect the Tk developers are also aware that some other revisions in 8.6.0 have not yet been merged back into the trunk.


tkt_uuid: 3597410fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: new virtual events <<NewLine>> and <<NewPage>>
comment:
  TkCon and console.tcl need those virtual events to make sure that
  <Return> and <KP_Enter> have the same binding without duplicating
  it. And the entry, spinbox and text widgets can be simplyfied with
  it as well.

  <<NewLine>> joins <Return> with <KP_Enter>, while <<NewPage>>
  does the same but then with the <Control> key.


tkt_uuid: 1866774fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Fixed
title: Remove X10 references from docs
comment:
  Hi *,

  X10 bitmaps are unsupported. At least if this error message is to be trusted:

  > wish8.5
  % image create bitmap -file logo_superh_mono.x10bm
  format error in bitmap data; looks like it's an obsolete X10 bitmap file
  % info patchlevel
  8.5.0

  The man pages GetBitmap and GetCursor are still mentioning it.

  BTW: the same error comes in 8.4.17 and 8.4.14 too. Using cvs annotate on generic/tkImgBmap.c, it seems it is unsupported since the early days of Tk 8.0...

  System: openSUSE 10.2 (X86-64)

  kind regards -- Matthias Kraft


tkt_uuid: 467524ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Fixed
title: GIF images are not read correctly
comment:
  Using "wish", (Tcl/Tk version 8.3.3) reading GIF
  formatted images with
  the "-from" option to the "image read" command results
  in either
  a corrupted image or a segmentation fault.

  Using a small GIF file (307x187) I tried the following:

  % image create photo
  image1
  % image1 read debris1.gif -from 0 0 100 100
  % canvas .c
  .c
  % pack .c
  % .c create image 0 0 -anchor nw -image image1
  1

  The resulting image that is displayed is corrupt.  In
  other instances
  using the "-from" option has resulted in a crash of the
  "wish"
  program due to a segementation fault.

  This problem also shows up under Tcl/Tk 8.3.2.  It has
  been reproduced
  under Solaris 2.6, Solaris 8, Windows NT, and Windows
  2000.  I have also noticed that the same code is used
  in the Tcl/Tk 8.4 Alpha releases.

  The problem seems to be in the the call to
  "ReadImage()" in 
  "tkImgGIF.c":

  1).  The "ReadImage()" function ignores any parameters
  that have been
        passed via the "-from" option.

  2).  Non-interlaced GIF images will load, but they will
  be corrupted.

  3).  Interlaced GIF images will typically cause a
  segmentation fault
        as they are read, but if not they will still be
  corrupted.

  I worked on a fix to prevent the problem, but it is not
  optimal:

  *** /afs/isis.unc.edu/home/m/c/mcknight/tkImgGIF.c     
  Wed Oct  3 11:29:46 2001
  --- tkImgGIF.c  Wed Oct  3 11:31:34 2001
  ***************
  *** 799,805 ****
        register unsigned char *top;
        int codeSize, clearCode, inCode, endCode,
  oldCode, maxCode,
          code, firstCode;
  !     
        /*
         *  Initialize the decoder
         */
  --- 799,805 ----
        register unsigned char *top;
        int codeSize, clearCode, inCode, endCode,
  oldCode, maxCode,
          code, firstCode;
  ! 
        /*
         *  Initialize the decoder
         */
  ***************
  *** 841,848 ****
        GetCode(chan, 0, 1);
    
        /* Read until we finish the image */
  !     for (i = 0, ypos = 0; i < rows; i++) {
  !       for (xpos = 0; xpos < len; ) {
    
              if (top == stack) {
                  /* Bummer -- our stack is empty.  Now
  we have to work! */
  --- 841,849 ----
        GetCode(chan, 0, 1);
    
        /* Read until we finish the image */
  ! 
  !     for (i = 0, ypos = 0; i < height; i++) {
  !       for (xpos = 0; xpos < width; ) {
    
              if (top == stack) {
                  /* Bummer -- our stack is empty.  Now
  we have to work! */
  ***************
  *** 947,955 ****
               * there are more in the file and we will
  be called to read 
               * one of them later)
               */
  !           *pixelPtr++ = cmap[v][CM_RED];
  !           *pixelPtr++ = cmap[v][CM_GREEN];
  !           *pixelPtr++ = cmap[v][CM_BLUE];
              if (transparent >= 0) {
                  *pixelPtr++ = cmap[v][CM_ALPHA];
              }
  --- 948,963 ----
               * there are more in the file and we will
  be called to read 
               * one of them later)
               */
  ! 
  !             if ( (xpos >= srcX) && (xpos < srcX+len)
  &&
  !                  (ypos >= srcY) && (ypos <
  srcY+rows)) {
  ! 
  !               *pixelPtr++ = cmap[v][CM_RED];
  !               *pixelPtr++ = cmap[v][CM_GREEN];
  !               *pixelPtr++ = cmap[v][CM_BLUE];
  ! 
  !             }
  ! 
              if (transparent >= 0) {
                  *pixelPtr++ = cmap[v][CM_ALPHA];
              }
  ***************
  *** 970,976 ****
          } else {
              ypos++;
          }
  !       pixelPtr = imagePtr + (ypos) * len *
  ((transparent>=0)?4:3);
        }
        return TCL_OK;
    }
  --- 978,989 ----
          } else {
              ypos++;
          }
  ! 
  !         if ( i >= (srcY+rows) ) {
  !             break;
  !         }
  ! 
  !       pixelPtr = imagePtr + (ypos-srcY) * len *
  ((transparent>=0)?4:3);
        }
        return TCL_OK;
    }


tkt_uuid: 2956548fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: TkpButtonSetDefaults only initialises one button type
comment:
  In tkButton,c, I spot the following code:
      if (!tsdPtr->defaultsInitialized) {
  TkpButtonSetDefaults(optionSpecs[type]);
  tsdPtr->defaultsInitialized = 1;
      }

  There are 4 button types, TkpButtonSetDefaults()
  will only be called once, for the first constructed
  button. The other types will have the original
  defaults, defined by DEF_BUTTON_BORDER_WIDTH,
  in stead of the default determined by
  GetSystemMetrics(SM_CXEDGE).

  Luck enough, no-one will ever spot the
  difference: DEF_BUTTON_BORDER_WIDTH
  has the value 2, and GetSystemMetrics(SM_CXEDGE)
  normally returns 2 as well. But if GetSystemMetrics
  one day returns a different value, it will only be
  taken over by one button type, the other 3 will
  be left as-is.

  This is already fixed in HEAD, as
  part of the CONSTification of tkButton. But
  since 8.5 and 8.4 have the same problem
  (8.3 is OK!), I would like to backport the
  same solution to 8.5 and 8.4 as well.

  Proposed solution: Introduce a MODULE_SCOPE
  variable tkDefButtonBorderWidth, which is set
  directly by TkpButtonSetDefaults, and stores
  the default value for all button types. This way,
  the specPtr argument is not used any more and
  one call is sufficient to initialize all buttons.
  In 8.6, I removed the specPtr argument from
  TkpButtonSetDefaults(), but in 8.5 and 8.4
  I will keep the function signature the same.
  Patch upcoming.

  Any comments?


tkt_uuid: 2898114fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Fixed
title: wish/tclsh unable run in directories with non-Latin chars
comment:
  To reproduce the bug:

  1. Create a directory: C:\软件 (or any directory name with non-Latin1 characters)
  2. Edit a new file with Notepad: C:\软件\test.tcl with content: tk_messageBox -message "Hullo world!"
  3. Save the file and double-click it in Windows Explorer.

  Result: "couldn't read file "C:\??\test.tcl": no such file or directory."

  Platform tested with: Windows XP SP3.


tkt_uuid: 3585396fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5.13
resolution: Fixed
title: winDialog.test requires user interaction
comment:
  It's reported that on Vista the tests winDialog-5.{8,9,24}
  require user interaction.  If this cannot be fixed, then
  these tests should be disabled by constraint.


tkt_uuid: 658279ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Possible transient bug
comment:
  This code on Windows using ActiveTcl 8.4.1:

  toplevel .foo

  toplevel .moo
  update idletasks
  wm transient .moo .foo
  grab set .moo

  toplevel .boo
  update idletasks
  wm transient .boo .moo
  grab set .boo

  toplevel .bar
  update idletasks
  wm transient .bar .boo
  grab set .bar

  Creates the proper windows.  Then, double-click the
  taskbar, iconifying the application.  Now, click the
  taskbar icon again, deiconifying the application. 
  Every window except the top one, .bar, come back.  The
  state of .bar is still withdrawn for some reason.  And,
  if you attempt to deiconify it, it draws the title bar
  and an outline of the window but never finishes.  It
  hangs there.


tkt_uuid: 2952745fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Crash in menu.test on Win32
comment:
  Running the standard Tk test suite on HEAD, using VC++ 6.0 or mingw (either
  debug or release), I am experiencing a crash. On Linux, everything works
  fine, but not on Windows (XP). I managed to generate the following stack
  trace, pointing to tkConfig.c, line 1629. The visual studio debugger indicates
  that specPtr here has the value 0xcdcdef00, while optionPtr points to
  0x00d25a4c, so it looks like specPtr is used after it is freed somewhere.

  Is anyone aware of recent changes which might have causes this?
  Stack trace:
  ===========================================
  Tk_FreeConfigOptions(char * 0x01a44f70, Tk_OptionTable_ * 0x00d2edd8, Tk_Window_ * 0x01a44170) line 1629 + 3 bytes
  DestroyMenuInstance(TkMenu * 0x01a44f70) line 1237 + 27 bytes
  TkDestroyMenu(TkMenu * 0x01a44f70) line 1318 + 9 bytes
  TkMenuEventProc(void * 0x01a44f70, _XEvent * 0x0012e534) line 764 + 9 bytes
  Tk_HandleEvent(_XEvent * 0x0012e534) line 1344 + 17 bytes
  Tk_DestroyWindow(Tk_Window_ * 0x01a44170) line 1415 + 9 bytes
  Tk_DestroyWindow(Tk_Window_ * 0x018fd9d8) line 1356 + 9 bytes
  FrameCmdDeletedProc(void * 0x01fa0d78) line 1730 + 9 bytes
  Tcl_DeleteCommandFromToken(Tcl_Interp * 0x01fd0c60, Tcl_Command_ * 0x01fa0cf8) line 2980 + 13 bytes
  TclTeardownNamespace(Namespace * 0x01ffc5c8) line 1062 + 13 bytes
  DeleteInterpProc(Tcl_Interp * 0x01fd0c60) line 1390 + 12 bytes
  Tcl_EventuallyFree(void * 0x01fd0c60, void (char *)* 0x0058fb11 DeleteInterpProc(Tcl_Interp *)) line 299 + 7 bytes
  Tcl_DeleteInterp(Tcl_Interp * 0x01fd0c60) line 1280 + 14 bytes
  SlaveObjCmdDeleteProc(void * 0x01fd0c60) line 2582 + 12 bytes
  Tcl_DeleteCommandFromToken(Tcl_Interp * 0x00d058a8, Tcl_Command_ * 0x018ebac0) line 2980 + 13 bytes
  Tcl_InterpObjCmd(void * 0x00000000, Tcl_Interp * 0x00d058a8, int 3, Tcl_Obj * const * 0x00df0bbc) line 797 + 25 bytes
  NRRunObjProc(void * * 0x01a844bc, Tcl_Interp * 0x00d058a8, int 0) line 4348 + 19 bytes
  TclNRRunCallbacks(Tcl_Interp * 0x00d058a8, int 0, TEOV_callback * 0x02049290, int 1) line 4295 + 18 bytes
  TclExecuteByteCode(Tcl_Interp * 0x00d058a8, ByteCode * 0x019548a0) line 2803 + 22 bytes
  NRCallTEBC(void * * 0x016f139c, Tcl_Interp * 0x00d058a8, int 0) line 4371 + 16 bytes
  TclNRRunCallbacks(Tcl_Interp * 0x00d058a8, int 0, TEOV_callback * 0x00000000, int 0) line 4295 + 18 bytes
  Tcl_EvalObjv(Tcl_Interp * 0x00d058a8, int 1, Tcl_Obj * const * 0x00df0280, int 2097152) line 4067 + 19 bytes
  TclEvalEx(Tcl_Interp * 0x00d058a8, const char * 0x01581c90, int 783, int 0, int 22, int * 0x00000000, const char * 0x01581c90) line 5237 + 22 bytes
  Tcl_EvalEx(Tcl_Interp * 0x00d058a8, const char * 0x01581c90, int 783, int 0) line 4893 + 29 bytes
  Tcl_FSEvalFileEx(Tcl_Interp * 0x00d058a8, Tcl_Obj * 0x00d0b7e0, const char * 0x00000000) line 1746 + 19 bytes
  Tk_MainEx(int -1, char * * 0x00bc15c8, int (Tcl_Interp *)* 0x00401005 _Tcl_AppInit, Tcl_Interp * 0x00d058a8) line 270 + 26 bytes
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00152331, int 10) line 135 + 26 bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! 7c817077()


tkt_uuid: 2477446fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: catch [image create photo] fails on invalid images
comment:
  When I use the following code 

  [catch {image create photo invalid_image_check -file $currently_selected_image}] 


  to detect if an image is valid or not, I'm getting the error

  "not enough free memory for image buffer
  Aborted"


  In tcl/tk 8.5. The problem is, the image is a very small icon file (132kb), and I got 2gb RAM.

  I'm using ActiveTCL's distribution and Slackware Linux.


tkt_uuid: 3540127fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: filebox.test fails on win32
comment:
  The reason is that saveOptionStrings and openOptionStrings
  (tkWinDialog.c lines 605 and 611) are not alphabetical.
  ==================================================

  filebox.test


  ==== filebox-1.1-1 tk_getOpenFile command FAILED
  ==== Contents of test case:

          tk_getOpenFile -foo

  ---- Result was:
  bad option "-foo": must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent, -title, -typevariable, or -multiple
  ---- Result should have been (exact matching):
  bad option "-foo": must be -defaultextension, -filetypes, -initialdir, -initialfile, -multiple, -parent, -title, or -typevariable
  ==== filebox-1.1-1 FAILED



  ==== filebox-1.3-1 tk_getOpenFile command FAILED
  ==== Contents of test case:

          tk_getOpenFile -foo bar

  ---- Result was:
  bad option "-foo": must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent, -title, -typevariable, or -multiple
  ---- Result should have been (exact matching):
  bad option "-foo": must be -defaultextension, -filetypes, -initialdir, -initialfile, -multiple, -parent, -title, or -typevariable
  ==== filebox-1.3-1 FAILED



  ==== filebox-4.1-1 tk_getSaveFile command FAILED
  ==== Contents of test case:

          tk_getSaveFile -foo

  ---- Result was:
  bad option "-foo": must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent, -title, -typevariable, or -confirmoverwri                                          te
  ---- Result should have been (exact matching):
  bad option "-foo": must be -confirmoverwrite, -defaultextension, -filetypes, -initialdir, -initialfile, -parent, -title, or -typevariab                                          le
  ==== filebox-4.1-1 FAILED



  ==== filebox-4.3-1 tk_getSaveFile command FAILED
  ==== Contents of test case:

          tk_getSaveFile -foo bar

  ---- Result was:
  bad option "-foo": must be -defaultextension, -filetypes, -initialdir, -initialfile, -parent, -title, -typevariable, or -confirmoverwri                                          te
  ---- Result should have been (exact matching):
  bad option "-foo": must be -confirmoverwrite, -defaultextension, -filetypes, -initialdir, -initialfile, -parent, -title, or -typevariab                                          le
  ==== filebox-4.3-1 FAILED


tkt_uuid: 220906ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 5 Medium
foundin: None
resolution: Fixed
title: More of Tk's internal functions exported through Stub table
comment:
  OriginalBugID: 4642 RFE
  Version: 8.3
  SubmitDate: '2000-03-28'
  LastModified: '2000-06-02'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All


  Name:

  Jan Nijtmans


  Comments:

  The forward declarations in tkIntDecls.h are necessary, otherwise source

      files always have to

      include tkText.h before tkInt.h.

      The file tkStubInit.c must be adapted as well, and tkIntDecls.h has more

      adaptations. But that can

      be done by "make genstubs", so it is not included in this patch.


  DesiredBehavior:

  My attempts to compile tkTest.c, tkUnixTest.c  and the tkprint extension as stub-enabled

  extensions failed because of critical functions are lacking from the Stub table. Therefore

  I request that the following functions (see patch) will be exported in a nearby future

  version of Tk.


  Patch:

  *** generic/tkInt.decls.origThu Feb 10 09:52:34 2000

  --- generic/tkInt.declsSun Mar 26 21:16:46 2000

  ***************

  *** 629,634 ****

  --- 629,679 ----

    }


  + declare 139 generic {

  +     int  TkTextGetIndex (Tcl_Interp *interp, struct TkText *textPtr, \

  +     char *string, struct TkTextIndex *indexPtr)

  + }

  + 

  + declare 140 generic {

  +     void  TkTextIndexBackBytes (CONST struct TkTextIndex *srcPtr, \

  +     int count, struct TkTextIndex *dstPtr)

  + }

  + 

  + declare 141 generic {

  +     void  TkTextIndexForwBytes (CONST struct TkTextIndex *srcPtr, \

  +     int count, struct TkTextIndex *dstPtr)

  + }

  + 

  + declare 142 generic {

  +     struct TkTextIndex * TkTextMakeByteIndex (struct TkTextBTree *tree, \

  +     int lineIndex, int byteIndex, struct TkTextIndex *indexPtr)

  + }

  + 

  + declare 143 generic {

  +     void  TkTextPrintIndex (CONST struct TkTextIndex *indexPtr, char *string)

  + }

  + 

  + declare 144 generic {

  +     struct TkTextSegment * TkTextSetMark (struct TkText *textPtr, char *name, \

  +     struct TkTextIndex *indexPtr)

  + }

  + declare 145 generic {

  +     int TkTextXviewCmd (struct TkText *textPtr, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }

  + declare 146 generic {

  +     void TkTextChanged (struct TkText *textPtr, struct TkTextIndex *index1Ptr, \

  +     struct TkTextIndex *index2Ptr)

  + }

  + declare 147 generic {

  +     int TkBTreeNumLines (struct TkTextBTree *tree)

  + }

  + declare 148 generic {

  +     void TkTextInsertDisplayProc (struct TkTextDispChunk *chunkPtr, \

  +     int x, int y, int height, int baseline, Display *display, \

  +     Drawable dst, int screenY)

  + }

  + 

    ##############################################################################


    # Define the platform specific internal Tcl interface. These functions are

  ***************

  *** 671,676 ****

  --- 716,727 ----

        void TkUnixSetMenubar (Tk_Window tkwin, Tk_Window menubar)

    }


  + declare 8 unix {

  +     int TkpTestembedCmd (ClientData clientdata, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }

  + 

  + 

    ############################

    # Windows specific functions


  ***************

  *** 814,819 ****

  --- 868,878 ----

        int TkWinGetPlatformId(void)

    }


  + declare 34 win {

  +     int TkpTestembedCmd (ClientData clietdata, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }

  + 

    ########################

    # Mac specific functions


  ***************

  *** 1044,1049 ****

  --- 1103,1112 ----

        void TkMacPreprocessMenu (void)

    }


  + declare 66 mac {

  +     int TkpTestembedCmd (ClientData clietdata, Tcl_Interp *interp, \

  +     int argc, char **argv)

  + }


    ##############################################################################


  *** generic/tkIntDecls.h.origWed Feb  9 03:13:51 2000

  --- generic/tkIntDecls.hSun Mar 26 21:17:14 2000

  ***************

  *** 22,27 ****

  --- 22,32 ----

    #define TCL_STORAGE_CLASS DLLEXPORT

    #endif


  + struct TkText;

  + struct TkTextIndex;

  + struct TkTextBTree;

  + struct TkTextDispChunk;

  + 

    /*

     * WARNING: This file is automatically generated by the tools/genStubs.tcl

     * script.  Any modifications to the function declarations below should be made


  PatchFiles:

  tkInt.decls tkIntDecls.h


tkt_uuid: 3536507fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 81. Portability
priority: 2
foundin: None
resolution: Fixed
title: clientData field in Tk_OptionSpec should be "const void *"
comment:
  The clientData field of Tk_OptionSpec always points to a nonmodifiable location, but because
  the type is ClientData (= void *) any constant pointer needs to be casted first.

  Suggestion: change this to "const void *", and a lot of type casts can be
  eliminated.


tkt_uuid: 2226093fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.6a4
resolution: Fixed
title: const changes not all correct
comment:
  The last set of changes (Nov 2) introduced a bug in tkUnixFont.c:2551.  You declare nameList as:

      const char *const *nameList;

  but that defies the assignment it receives at 2551.  mjanssen noticed this with gcc4, but my gcc3 glossed over it.  Please use gcc4 for const changes in the future to prevent const poisoning issues.


tkt_uuid: 2433260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: non-critical error in Tk_PhotoPutBlock
comment:
  With the use of valgrind I got the following message:

  ==1806== Source and destination overlap in memcpy(0x1D3FE6A8, 0x1D3FE6A8, 23104)
  ==1806==    at 0x1B907C17: memcpy (mac_replace_strmem.c:113)
  ==1806==    by 0x1BAF6C14: Tk_PhotoPutBlock (tkImgPhoto.c:4411)

  What I have done:
  I fetched an image block with Tk_PhotoGetImage(), did some modifications (recoloring), and used Tk_PhotoPutBlock(). The latter seems to be neccessary although only image pixels has been changed.

  I recommend to use function memmove() instead of function memcpy() inside Tk_PhotoPutBlock(). The documentation of Tk_PhotoPutBlock does not forbid the identity of block.pixelPtr.


tkt_uuid: 2229999fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 7 High
foundin: obsolete: 8.6a4
resolution: Fixed
title: Tk doesn't compile on HP-UX any more
comment:
  When compiling Tk on HP-UX, it doesn't compile any more.

  The reason is that 3 files now contain the "inline"
  'keyword', which is not available in the HP-UX
  compiler. The offending files are:

  unix/tkUnixEmbed.c
  generic/tkBusy.c
  generic/tkCanvas.c

  removing the 'inline' keywords, or compiling with
  -Dinline= fixes this.

  Regards,
         Jan Nijtmans


tkt_uuid: 220935ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 9 Immediate
foundin: obsolete: 8.4.16
resolution: Fixed
title: canvas dash update problem
comment:
  OriginalBugID: 5997 Bug
  Version: 8.4a1
  SubmitDate: '2000-07-10'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-Red Hat
  OSVersion: see below.
  Machine: Linux gitarre 2.2.15 #1 Wed May 10 22:58:59 CEST 2000 i686 unkno


  Name:
  Matthias Jung

  Extensions:
  none

  CustomShell:
  no.

  Comments:
  If other dash pattern styles are specified, e.g. {40 1}, the line IS
      updated. E.g. the above
      error can be worked around by specifying
      
      .c itemconfigure 1 -dash {40 1}
      .c itemconfigure 1 -dash {40 40}

  ReproducibleScript:
  canvas .c
  pack .c
  .c create line 1 1 300 200 -dash {15 15}
  .c itemconfigure 1 -dash {40 40}

  ObservedBehavior:
  Line is not updated to the new dash pattern.

  DesiredBehavior:
  Updated dash pattern.


tkt_uuid: 846824ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: Web-style colours
comment:
  Tk ought to support the CSS colours as described at:
  http://www.w3.org/TR/1998/REC-CSS2-
  19980512/syndata.html#color-units


tkt_uuid: 3076671fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: CVS HEAD Tk build fails on win32 with msys/mingw
comment:
  Trying to build CVS HEAD Tk fails - probably after changes to support Unicode:

  [23:02:58] 2  >> gcc -c -O2 -fomit-frame-pointer -DUNICODE -D_UNICODE -Wall -Wdeclaration-after-statement  -I"../../../sources/tk-8.6b1.2/win/../generic" -I"../../../sources/tk-8.6b1.2/win" -I"../../../sources/tk-8.6b1.2/win/../xlib" -I"../../../sources/tk-8.6b1.2/win/../bitmaps" -I"/y/cookit/sources/tcl-8.6b1.2//generic" -pipe -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DSTATIC_BUILD=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UXTHEME_H=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1  -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_ALLOCA_GCC_INLINE=1 -DHAVE_CAST_TO_UNION=1 -DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTATIC_BUILD=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ZLIB=1 -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1   -DBUILD_tk -DBUILD_ttk "../../../sources/tk-8.6b1.2/win/tkWinSend.c" -o tkWinSend.o
  [23:03:00] 2  >> In file included from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:15:
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/tchar.h:41: error: syntax error before "TCHAR"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/tchar.h:42: error: syntax error before "_TCHAR"
  [23:03:00] 2  >> In file included from y:/cookit/sources/tcl-8.6b1.2/generic/tcl.h:2391,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../generic/tkIntXlibDecls.h:25,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../xlib/X11/Xlib.h:1196,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinPort.h:64,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../generic/tkPort.h:20,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/../generic/tkInt.h:21,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:16:
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:53: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:54: warning: type defaults to `int' in declaration of `Tcl_WinUtfToTChar'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:54: warning: data definition has no type or storage class
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:56: warning: type defaults to `int' in declaration of `TCHAR'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:56: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:77: error: syntax error before "TCHAR"
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:77: warning: no semicolon at end of struct or union
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:78: warning: type defaults to `int' in declaration of `TCHAR'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:78: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:84: warning: type defaults to `int' in declaration of `TclPlatStubs'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:84: warning: data definition has no type or storage class
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:89: error: syntax error before '*' token
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:89: warning: type defaults to `int' in declaration of `tclPlatStubsPtr'
  [23:03:00] 2  >> y:/cookit/sources/tcl-8.6b1.2/generic/tclPlatDecls.h:89: warning: data definition has no type or storage class
  [23:03:00] 2  >> In file included from Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windef.h:246,
  [23:03:00] 2  >>                  from Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:48,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWin.h:38,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinInt.h:28,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSendCom.h:19,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:17:
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:96: error: syntax error before "TBYTE"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:97: error: syntax error before '*' token
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winnt.h:98: error: syntax error before '*' token
  [23:03:00] 2  >> In file included from Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h:50,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWin.h:38,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinInt.h:28,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSendCom.h:19,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:17:
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1026: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1027: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> Y:/cookit/win32/msys/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/winbase.h:1028: error: syntax error before "LPTSTR"
  [23:03:00] 2  >> In file included from ../../../sources/tk-8.6b1.2/win/tkWinSendCom.h:19,
  [23:03:00] 2  >>                  from ../../../sources/tk-8.6b1.2/win/tkWinSend.c:17:
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:190: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:191: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:193: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:194: error: syntax error before "LPCTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:195: warning: parameter names (without types) in function declaration
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinInt.h:196: error: syntax error before "LPTSTR"
  [23:03:00] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c: In function `Win32ErrorObj':
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:836: error: syntax error before "lpBuffer"
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:842: error: `lpBuffer' undeclared (first use in this function)
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:842: error: (Each undeclared identifier is reported only once
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:842: error: for each function it appears in.)
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:845: error: `sBuffer' undeclared (first use in this function)
  [23:03:01] 2  >> ../../../sources/tk-8.6b1.2/win/tkWinSend.c:849: error: `p' undeclared (first use in this function)
  [23:03:01] 2  >> make: *** [tkWinSend.o] Error 1
  [23:03:01] 2 waitForExtCommand: Error: Command exited with code 2

  Removing the following line from tkWinSend.c:15 resolves the issue, but I am not sure if it also works for non-MinGW builds on win32:
    * RCS: @(#) $Id: tkWinSend.c,v 1.24 2010/04/08 14:06:20 nijtmans Exp $
    */
  -#include <tchar.h>
   #include "tkInt.h"
   #include "tkWinSendCom.h"


tkt_uuid: 3534137fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: $tcl_platform(platform) != [tk windowingsystem]
comment:
  When trying to get cygwin Tk runnung as win32 GUI in
  stead of X11, noticing that in many of the library/*.tcl
  files $tcl_platform(platform) is checked to be "windows".

  However, when running cygwin, tcl_platform(platform)
  is "unix", so all those checks are wrong. The result is
  that many bindings don't work correctly.

  Solution: modify the checks for $tcl_platform(platform)
  eq "windows" to use [tk windowsingsystem] eq "win32"
  in steadm.


tkt_uuid: 3154705fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Close button has no effect
comment:
  When displaying a tk_messageBox on a system that doesn't provide native message boxes(linux), the close button does not respond when pressed.

  This appears to be caused by the following line which sets the WM_DELETE_WINDOW protocol to nil:
  wm protocol $w WM_DELETE_WINDOW { }

  The proposed solution is to set the protocol to execute the same code that is execute when <Escape> is pressed:
  wm protocol $w WM_DELETE_WINDOW [list $w.$cancel invoke]


tkt_uuid: 2932808fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: Canvas items not updating on widget state change
comment:
  The canvas widget allows different attributes to be set on items depending on their state, normal/disabled/active.  However, the items are not updated if the overall widget state is changed.  Example:

  pack [canvas .c] -fill both
  .c create text 100 100 -text "Test Text" \
  -disabledfill blue
  .c configure -state disabled

  The text should now be displayed in blue, but isn't.  Doing any item configuration forces an update:

  .c itemconfigure 1 -text "Updated Text"

  The attached patch fixes the problem.  It is for tk 8.5.8, tkCanvas.c revision 1.46.2.2.


tkt_uuid: 3163893fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: -initialdir option bug for tk_chooseDirectory under XP
comment:
  How to reproduce :
  1- test under XP
  2- Pull CVS HEAD as of 22 January 2011.
  3- Start wish
  4- Type : tk_chooseDirectory -initialdir c:\
   => the dialog does not open in c:\.
  5- Recompile wish with -DUNICODE -D_UNICODE removed (you have to tweak the tk generated makefile)
  6- Type : tk_chooseDirectory -initialdir c:\
   => the dialog correctly opens in c:\.

  It was working OK in august 2010. -DUNICODE has been added later, and Win32 API calls also have been modified in tkWinDialog.c.

  Note : this bug might not be reproducible under Vista / 7.


tkt_uuid: 2507326fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: build problem with amsn and 8.6b1
comment:
  This artifact is meant to fix the build problem in amsn,
  as discussed in:
  <http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/3685995>

  After studying the aMSN code, aMSN assumes that Tk makes
  an internal copy of formatPtr->name, although Tk documents
  that formatPtr->name must be available during the full
  lifetime of the thread.

  Making a copy, as Tk 8.5.5 and earlier did, adds only
  4 lines of code to Tk, so it is much simpler to implement
  than any other solution. Will do that.


tkt_uuid: 1055974fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: -dashofset option doesnt work on ms windows build
comment:
   Refering to Bug 1051589 in the tcl section:
  canvas -dashoffset option dosen't work on windows 
  The general canvas option "-dashoffset" has no
  influence in windows releases. Please test the attached
  script (improved for windows test). 
  You will see moving dashes on Linux OS but static ones
  on windows. I already tested all current releases, it
  doesnt work. 

  cheers,
  konrad.lustig@gmx.de     


tkt_uuid: c81b1544ce435d96a2df98dd32c66e498f42f8fe
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
severity: Minor
foundin: 8.6.1
private_contact: 55805032f00760ddf84eb3f8acb077da7bef1411
resolution: Invalid
title: Changing cursor in ttk::checkbutton changes state
comment:
  Build MinGW 64, Win7;

  Run following code:
  ttk::checkbutton .cb1
  .cb1 state !alternate
  pack .cb1

  Now the button state is emtpy. Change the cursor:
  .cb1 configure -cursor arrow

  Now the buttons state has changed and is in "alternate"!


tkt_uuid: 3480471fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.10
resolution: Fixed
title: tk_getOpenFile crashes on Win64
comment:
  On Windows x64, when running a 64bit wish 8.5.10 and after allocating and using lots of memory (above 2GB), wish crashes immediately when selecting a File in a tk_getOpenFile dialog. We tracked the problem down to the function OFNHookProcW in  tkWinDialog.c.

  Referencing tk 8.5.10, in line 1035-1040 of tkWinDialog.c, there is the following piece of code:

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

  The crash is caught by the debugger in the line
  buffer += dirsize;
  but the mistake resides in the lines above and below:
  The last argument of SendMessageW is declared  as LPARAM
  (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx), which is defined as LONG_PTR which is defined as __int64 when building with 64bit (see http://msdn.microsoft.com/en-us/library/aa383751(v=VS.85).aspx)

  When buffer starts above 2GB adress (this makes it a little difficult to reproduce this error), the cast to int cuts the upper part of the adress and things become very wrong and wish crashes.

  Changing those lines to 
  SendMessageW(hdlg, CDM_GETFOLDERPATH, dirsize, (__int64) buffer);
  buffer += dirsize;
  SendMessageW(hdlg, CDM_GETSPEC, selsize, (__int64) buffer);

  makes everything fine.
  The correct all-platform fix should cast to (LONG_PTR), imho.

  This error also occours in tk 8.5.11 (although these lines are different, but PTR2INT makes the same mistake as the int-cast) and in tk 8.6b2


tkt_uuid: 3503317fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: XParseColor speedup
comment:
  Looking at the XParseColor, there are possibilities
  for speedup which cost nothing (except time to
  implement it)

  - The binary search algorithm keeps track of 3 state
    variables (l, u and i), which can be reduced to 2
    (step and p).
  - The color table contains entries for both entries
    like "aliceBlue" and "alice blue". When we write
    a custom strcasecmp, in which a capital in the
    table matches a space+character in the color
    spec, those two table entries can be combined
    to one.
  - inline FindColor, it's just a small function.

  The measured speedup is about 5%. The color
  table size is reduced from 752 to 657 entries


tkt_uuid: 3486474fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Fixed
title: Inconsistent color scaling
comment:
  The Tk_GetColor() man page states: "When fewer than 16 bits are provided for each color, they represent the most significant bits of the color. For example, #3a7 is the same as #3000a0007000."  The [photo] man page references the Tk_GetColor() man page regarding how color names are interpreted.

  I just tested this in MS-Windows XP by putting the color #3a7 into a photo image and into a widget background.  I then took a screenshot using The GIMP and read back the color values.  The photo contained #33aa77, but the widget background contained #30a070.  The colors are visibly different when compared side-by-side.  I'm not sure how this inconsistency is possible, unless not everything is calling Tk_GetColor().

  I prefer the bit replication technique used by photo, even though it's contrary to the man page.  It makes #fff map to white, not light gray.


tkt_uuid: 3102739fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Fixed
title: de.msg misses %OK used by tk_messageBox
comment:
  Under Linux (or any platform using the Tcl-Implementation of tk_messageBox) :
  % package require Tk
  % proc ::msgcat::mcunknown args {
  puts "mcunknown $args"
  return [lrange $args 1 end]
  }
  % tk_messageBox
  mcunknown de_de %OK
  ok

  Thus the line 
  ::msgcat::mcset de "&OK"
  is missing in
  lib/tk8.5/msgs/de.msg


tkt_uuid: 3604914fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: current: 8.6.0
resolution: Duplicate
title: cocoa 8.6.0 Text <<Paste>> not bound to tk_textPaste
comment:
  Should 
  bind Text <<Paste>>
  return 
  tk::TextScrollPages %W 1
  ?

  It seems like it should be
  tk_textPaste %W

  is there a reason for this change?


tkt_uuid: 1627732fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 7 High
foundin: obsolete: 8.5a6
resolution: Fixed
title: CONST: tkButton.c: optionSpecs with TkpButtonSetDefaults
comment:
  The recent change to the const'ness of optionSpecs seems to be causing issues:

  ..\generic\tkButton.c(639) : error C2220: warning treated as error - no 'object' file generated
  ..\generic\tkButton.c(639) : warning C4090: 'function' : different 'const' qualifiers


tkt_uuid: 3555324fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: Ctrl+A for select-all
comment:
  Tk binds Ctrl+A to start-of-line instead
  of select-all, which many other applications
  do. See:
  <http://www.computerhope.com/shortcut.htm>

  Suggestion: Introduce a virtual event
  <<SelectAll>>


tkt_uuid: 3543050fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 9 Immediate
foundin: obsolete: 8.6b3
resolution: Fixed
title: segfault in ClipboardHandler
comment:
  While running the Tk test suite, I can (sometimes) trigger
  a segfault during test clrpick-3.1 by moving the mouse
  rapidly so that focus is rapidly changing between several
  non-Tk windows.  Catching it in the debugger produces
  this partial backtrace:

  0x00000000004e74ba in ClipboardHandler (clientData=0xe2d2c0, offset=0,
      buffer=0x7fffffffa5d0 "\001", maxBytes=4000)
      at /home/dgp/fossil/tk/unix/../generic/tkClipboard.c:74
  74              if (scanned + cbPtr->length > offset) {

  #0  0x00000000004e74ba in ClipboardHandler (clientData=0xe2d2c0, offset=0,
      buffer=0x7fffffffa5d0 "\001", maxBytes=4000)
      at /home/dgp/fossil/tk/unix/../generic/tkClipboard.c:74
  #1  0x00000000004cf0bd in ConvertSelection (winPtr=0xfeaab0, eventPtr=0xfb0ad0)
      at /home/dgp/fossil/tk/unix/../unix/tkUnixSelect.c:927
  #2  0x00000000004ceb69 in TkSelEventProc (tkwin=0xfeaab0, eventPtr=0xfb0ad0)
      at /home/dgp/fossil/tk/unix/../unix/tkUnixSelect.c:709
  #3  0x00000000004f22e9 in Tk_HandleEvent (eventPtr=0xfb0ad0)
      at /home/dgp/fossil/tk/unix/../generic/tkEvent.c:1327
  #4  0x00000000004f296e in WindowEventProc (evPtr=0xfb0ac0, flags=-3)
      at /home/dgp/fossil/tk/unix/../generic/tkEvent.c:1753
  #5  0x000000000060c5de in Tcl_ServiceEvent (flags=-3)
      at /home/dgp/fossil/tcl-only/generic/tclNotify.c:670
  #6  0x000000000060c8e3 in Tcl_DoOneEvent (flags=-3)
      at /home/dgp/fossil/tcl-only/generic/tclNotify.c:907

  At the time of the segfault, cbPtr holds a value that is
  not a valid pointer.


tkt_uuid: 3519917fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: Fixed
title: Snow Leopard unix/Makefile `make test` fail
comment:
  Building with the unix/Makefile on Snow Leopard
  (so that I"m doing an X Windows build of Tk), I see:

  $ make test    
  make: *** No rule to make target `test.o', needed by `test'.  Stop.

  Strangely enough, both `make test-classic` and `make test-tk` work fine.


tkt_uuid: 2809525fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: Abort on overlong color name
comment:
  . configure -bg [string repeat x 65536]

  causes the interpreter to abort with:

  X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
    Major opcode of failed request:  92 (X_LookupColor)
    Serial number of failed request:  3231
    Current serial number in output stream:  3231


tkt_uuid: 3562426fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 8
foundin: obsolete: 8.5.12
resolution: Fixed
title: Context menu goes out of edge of screen
comment:
  OS: Debian 6.0.5
  DE: Xfce
  App.: Tkabber 0.11.1

  Context menu (or tray menu) of application, invoked near the edge of screen, goes out of it, but must not I suppose. Found out that this bug in file "generic/tkMenuDraw.c" in function TkPostTearoffMenu, see lines 884-895.


tkt_uuid: 3020677fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: wish can't link reg1.2
comment:
  Tk cvs head
  ms vc++2010
  ms vista sp2

  When building wish, the linker can't find the reg package lib file. rule.vc has the wrong version (1.2) - tcl cvs head builds 1.3

  Index: rules.vc
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/rules.vc,v
  retrieving revision 1.25
  diff -r1.25 rules.vc
  562c562
  < TCLREGLIB     = "$(_TCLDIR)\lib\tclreg12$(SUFX:t=).lib"
  ---
  > TCLREGLIB     = "$(_TCLDIR)\lib\tclreg13$(SUFX:t=).lib"
  575c575
  < TCLREGLIB     = "$(_TCLDIR)\win\$(BUILDDIRTOP)\tclreg12$(SUFX:t=).lib"
  ---
  > TCLREGLIB     = "$(_TCLDIR)\win\$(BUILDDIRTOP)\tclreg13$(SUFX:t=).lib"


tkt_uuid: 2190619fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 8
foundin: obsolete: 8.6a3
resolution: Fixed
title: Warnings due to Tk_SmoothMethod name constness change
comment:
  the constness change to the name field of Tk_SmoothMethod in
  http://fisheye.categorifiedcoder.info/browse/Tk/tk/generic/tk.h?r2=1.119&r1=1.118
  leads to the following warning:
  tk/generic/tkCanvUtil.c: In function 'TkSmoothPrintProc':
  tk/generic/tkCanvUtil.c:825: warning: return discards qualifiers from pointer target type

  either the return value of TkSmoothPrintProc() needs to be made const, and thus all functions of type Tk_OptionPrintProc, as well as that type itself; or the change above needs to be reverted; or TkSmoothPrintProc() needs to copy its return string into a temporary buffer


tkt_uuid: 3516768fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 8
foundin: obsolete: 8.5.10
resolution: Invalid
title: Latest Tk head fails to compile in debug mode
comment:
  Compiling in Win XP, MinGW, Latest Tcl and Tk head 8.5.11;
  The release compiles fine, but when using debug switch --enable-symbos it fails using the stdint.h.

  gcc -c -g -Wall  -I"./../generic" -I"." -I"./../xlib" -I"./../bitmaps" -I"/e/CM.git/tcltk85/dcompile/tcl/generic" -I"/e/
  CM.git/tcltk85/dcompile/tcl/win" -pipe -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRIN
  G=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_ST
  AT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -D
  HAVE_UNISTD_H=1 -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_UXT
  HEME_H=1 -DTCL_CFG_DEBUG=1  -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPA
  CKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -DTCL_CFGVAL_ENCODING=\"cp1252\" -DHAVE_SYS_T
  YPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=
  1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_NO_SEH=1 -DEXCEPTION_DISPOSITION=int -DHAVE_WINNT_IGNORE_VOID=1 -DHAVE_CAST
  _TO_UNION=1 -DHAVE_INTPTR_T=1 -Duintptr_t=unsigned\ int -DTCL_CFG_DEBUG=1  -DUSE_TCL_STUBS -DBUILD_tk -DBUILD_ttk "./../
  generic/tkMain.c" -o tkMain.o
  In file included from d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/include/stdint.h:3:0,
                   from d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/process.h:18,
                   from e:/CM.git/tcltk85/dcompile/tcl/win/tclWinPort.h:61,
                   from e:/CM.git/tcltk85/dcompile/tcl/generic/tclPort.h:21,
                   from e:/CM.git/tcltk85/dcompile/tcl/generic/tclInt.h:36,
                   from ./../generic/tkMain.c:17:
  d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/stdint.h:75:24: error: duplicate 'unsigned'
  d:\programs\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/stdint.h:75:24: error: two or more data types in decl
  aration specifiers
  make: *** [tkMain.o] Error 1


tkt_uuid: 3019363fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: `make genstubs` failure
comment:
  $ make genstubs
  /usr/bin/tclsh8.4 /home/dgp/cvs/tcl-only/tools/genStubs.tcl /home/dgp/cvs/tk/unix/../generic \
                  /home/dgp/cvs/tk/unix/../generic/tk.decls /home/dgp/cvs/tk/unix/../generic/tkInt.decls
  Emitting tk
  Emitting tkInt
  Emitting tkIntPlat
  Emitting tkIntXlib
  Emitting tkPlat
  /usr/bin/tclsh8.4 /home/dgp/cvs/tk/unix/../generic/ttk/ttkGenStubs.tcl /home/dgp/cvs/tk/unix/../generic/ttk /home/dgp/cvs/tk/unix/../generic/ttk/ttk.decls
  Emitting ttk
  syntax error in expression "$name in $hooks($intf)": extra tokens at end of expression
      ("if" test expression)
      while compiling
  "if {$name in $hooks($intf)} {
  ...


  The tool script tk/generic/ttk/ttkGenStubs.tcl uses the
  "in" operator, a feature of Tcl 8.5 and later.  The script
  needs a [package require Tcl 8.5].

  Once that is in place the failure will be a  bit tidier, but
  the remaining failure is that if the tool scripts used
  in developing Tk need Tcl 8.5, then the Makefile definitions
  for the rules -- and the configure machinery that sets up
  all the pieces of those definitions --  need to make sure
  those needs are met.

  Either the TCL_EXE should be required to be a Tcl
  shell executable of at least version 8.5, and the
  machinery to set that value should enforce that,
  or we need another Makefile variable to hold a
  different executable which meets that requirement
  and then revise the "genstubs" target to make use
  of it.


tkt_uuid: 2265860fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.6a4
resolution: Fixed
title: new test failures
comment:
  ==== imgPhoto-4.10 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      image create photo photo2 -file $teapotPhotoFile
      photo1 configure -width 0 -height 0 -palette {} -gamma 1
      photo1 copy photo2
      list [image width photo1] [image height photo1] [photo1 get 100 100]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.10 FAILED



  ==== imgPhoto-4.15 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2
      photo1 copy photo2 -from 0 70 60 120 -shrink
      list [image width photo1] [image height photo1] [photo1 get 20 10]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.15 FAILED



  ==== imgPhoto-4.16 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2 -from 60 120 0 70 -to 20 50
      list [image width photo1] [image height photo1] [photo1 get 40 80]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -from 60 120 0 70 -to 20 50"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.16 FAILED



  ==== imgPhoto-4.17 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2 -from 0 120 60 70 -to 0 0 100 100
      list [image width photo1] [image height photo1] [photo1 get 80 60]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -from 0 120 60 70 -to 0 0 100 100"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.17 FAILED



  ==== imgPhoto-4.18 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2 -from 60 70 0 120 -zoom 2
      list [image width photo1] [image height photo1] [photo1 get 100 50]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -from 60 70 0 120 -zoom 2"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.18 FAILED



  ==== imgPhoto-4.19 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2 -from 0 70 60 120 -zoom 2
      list [image width photo1] [image height photo1] [photo1 get 100 50]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -from 0 70 60 120 -zoom 2"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.19 FAILED



  ==== imgPhoto-4.20 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2 -from 20 20 200 180 -subsample 2 -shrink
      list [image width photo1] [image height photo1] [photo1 get 50 30]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -from 20 20 200 180 -subsample 2 -shrink"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.20 FAILED



  ==== imgPhoto-4.21 ImgPhotoCmd procedure: copy option FAILED
  ==== Contents of test case:

      photo1 copy photo2
      set result [list [image width photo1] [image height photo1]]
      photo1 conf -width 49 -height 51
      lappend result [image width photo1] [image height photo1]
      photo1 copy photo2
      lappend result [image width photo1] [image height photo1]
      photo1 copy photo2 -from 0 0 10 10 -shrink
      lappend result [image width photo1] [image height photo1]
      photo1 conf -width 0
      photo1 copy photo2 -from 0 0 10 10 -shrink
      lappend result [image width photo1] [image height photo1]
      photo1 conf -height 0
      photo1 copy photo2 -from 0 0 10 10 -shrink
      lappend result [image width photo1] [image height photo1]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.21 FAILED



  ==== imgPhoto-4.71 ImgPhotoCmd procedure: copy with -compositingrule FAILED
  ==== Contents of test case:

      # Tests default compositing rule
      photo1 blank
      photo2 blank
      photo1 put white -to 0 0 2 2
      photo2 put white -to 0 0 2 2
      photo2 transparency set 0 0 true
      photo1 copy photo2 -to 1 1
      checkImgTrans photo1

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -to 1 1"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.71 FAILED



  ==== imgPhoto-4.72 ImgPhotoCmd procedure: copy with -compositingrule FAILED
  ==== Contents of test case:

      photo1 blank
      photo2 blank
      photo1 put white -to 0 0 2 2
      photo2 put white -to 0 0 2 2
      photo2 transparency set 0 0 true
      photo1 copy photo2 -to 1 1 -compositingrule overlay
      checkImgTrans photo1

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -to 1 1 -compositingrule overlay"
      ("uplevel" body line 7)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.72 FAILED



  ==== imgPhoto-4.73 ImgPhotoCmd procedure: copy with -compositingrule FAILED
  ==== Contents of test case:

      photo1 blank
      photo2 blank
      photo1 put white -to 0 0 2 2
      photo2 put white -to 0 0 2 2
      photo2 transparency set 0 0 true
      photo1 copy photo2 -to 1 1 -compositingrule set
      checkImgTrans photo1

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "photo2" doesn't exist or is not a photo image
      while executing
  "photo1 copy photo2 -to 1 1 -compositingrule set"
      ("uplevel" body line 7)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.73 FAILED



  ==== imgPhoto-12.1 Tk_PhotoPutZoomedBlock FAILED
  ==== Contents of test case:

      image create photo p3 -file $teapotPhotoFile
      set result [list [p3 get 50 50] [p3 get 100 100]]
      p3 copy p3 -zoom 2
      lappend result [image width p3] [image height p3] [p3 get 100 100]

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "p3" doesn't exist or is not a photo image
      while executing
  "p3 copy p3 -zoom 2"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-12.1 FAILED



  ==== imgPhoto-16.1 copying to self doesn't access freed memory FAILED
  ==== Contents of test case:

      # Bug 877950 makes this crash when trying to copy out of a deallocated
      # area.
      $i put red -to 0 0 1000 1000
      $i copy $i -from 0 0 1000 1000 -to 500 0

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "image8" doesn't exist or is not a photo image
      while executing
  "$i copy $i -from 0 0 1000 1000 -to 500 0"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-16.1 FAILED


tkt_uuid: 2636558fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk_DefineBitmap and Tk_GetBitmapFromData signature problem
comment:
  The current signatures of those two functions result
  in a type cast needed for every call. In tkBitmap.c
  there are 10 such calls. The reason for this is
  that standard the bitmap data is defined as
  const unsigned char[], while the function
  requires a const char[].

  Proposed solution: change the
    const char *source
  parameter to
    const void *source.

  This is fully binary and source
  compatible, only it prevents the
  need for the type cast.


tkt_uuid: 2021525fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: missing definitions for ms vc 8 builds
comment:
  the tcl.m4 file was missing -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE from the cflags defintion required for building on windows using ms vc 8

  attached is patch to fix

  (copied form the tcl verison...)


tkt_uuid: 3512824fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: Duplicate
title: Tk and dual/multihead on windows
comment:
  Hi...

  As already posted to the mailinglist 
  (see: https://sourceforge.net/mailarchive/message.php?msg_id=29056120)

  Tk on windows appears to have a problem with screen dimensions on dual/multihead
  system. This is the bug report as suggested by Jan Nijtmans.

  Thanks,

  Roland


tkt_uuid: 3069480fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: [w64] The app was unable to start correctly (0xc000007b)
comment:
  I get this error launching wish (8.5.x, 8.6_HEAD)
  TITLE: wish85.exe/wish86.exe - Application Error
  TEXT:  The application was unable to start correctly (0xc000007b). Click OK to close the application.

  platform is windows x64, built with mingw64 for w64

  any hint on how to inspect what's failing there?


tkt_uuid: 3519111fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Minor
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: f27550a48f3507e089b5ec174bd709ec0cccbf77
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
severity: Important
foundin: Tcl/Tk 8.6 (pl10)
private_contact: 9b7155594aadef44d10a978838b8fe108cdafdd1
resolution: None
title: Loss of first Alt-KeyPress
comment:
  Please try this script:
  --------------------------------------------------------------
  bind . <Alt-KeyPress-s> { puts "Alt-S pressed" }
  bind . <Alt-KeyRelease-s> { puts "Alt-S released" }
  --------------------------------------------------------------

  If you press Alt-s the first time, the KeyPress is lost.
  If you press Alt-s the second time, the KeyPress will be shown.

  This problem is serious, if the user is typing Alt-h after start
  of the application, to open the help menu, nothing happens.

  This is tested under X11.


tkt_uuid: 3532186fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.5.11
resolution: Fixed
title: pkgIndex.tcl file complexity that's unwarranted
comment:
  On the 8.5 and trunk branches, the pkgIndex.tcl file
  for Tk just grew much more complex, and the need for
  it is not apparent to me.

  There is no need for the installed pkgIndex.tcl file to
  account for all the possible DLLs and installation conventions
  that might have been used.  At the time you install a
  pkgIndex.tcl file, you know which kind of DLL you installed,
  and where you're putting it, so you should install just the
  right simple pkgIndex.tcl file that matches what you've done.
  There should be no need to sort these things out again at
  run time.


tkt_uuid: 3601782fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 9 Immediate
foundin: current: 8.6.0
resolution: Fixed
title: checkin dc77a27c54 fails badly
comment:
  Starting with Tk trunk checkin

    http://core.tcl.tk/tk/info/dc77a27c54

  Tk 8.6.* rejects pre-8.6.0 Tcl.  The wisdom
  of this is questionable, since it at least complicates
  if not impedes bisecting Tcl across the pre-stable
  to stable boundary searching for Tcl changes that
  break Tk -- the task I'm currently on.

  Still, I recognize the value in nudging people to
  throw out their alphas and betas, so assuming
  we keep this in place, it ought to at least fail
  better.  I see just a crash.  A panic with an useful
  error message is the better way to go.

  The stack trace I see (no I don't understand it yet)
  is:

  Program received signal SIGABRT, Aborted.
  0x00000033dd630285 in raise () from /lib64/libc.so.6
  (gdb) bt
  #0  0x00000033dd630285 in raise () from /lib64/libc.so.6
  #1  0x00000033dd631d30 in abort () from /lib64/libc.so.6
  #2  0x0000000000418886 in Tk_MainEx (argc=1, argv=0x7fffffffdd08,
      appInitProc=0x418755 <Tcl_AppInit>, interp=0x965d70)
      at /home/dgp/fossil/tk/unix/../generic/tkMain.c:192
  #3  0x000000000041874e in main (argc=1, argv=0x7fffffffdd08)
      at /home/dgp/fossil/tk/unix/../unix/tkAppInit.c:74


tkt_uuid: 3288113fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.6b2
resolution: Fixed
title: Missing marks when searched through mark next
comment:
  I have a text widget with a peer. I set a mark in it and later I need to find out the list of marks the text widget contains. I need to be able to do this from any peer.

  In the documentation, marks are advertised to be shared between peers so that they can be manipulated on an equal basis from any peer.

  I have found this to be true for
    [$w mark names]
  but apparently not for
    [$w mark next $ind]

  [$w mark names] correctly returns all mark names, regardless of $w being the "initial" text widget, or the peer.

  However, when scanning through the widget using [$w mark next $ind], I have found marks to be missing.

  The following script demonstrates the problem:

  ------------

  text .t
  .t insert end "Hello\nworld\n"
  .t peer create .pt
  .t mark set mymark 2.0

  # the text widget and its peer now have three marks:
  # insert current mymark

  # all three marks are found for both the text widget
  # and its peer - OK!
  tk_messageBox -message "[.t mark names]\n[.pt mark names]"

  proc getmks {w} {
    set lstmks [list ]
    set mk [$w mark next 1.0]
    while {$mk ne ""} {
      lappend lstmks $mk
      set mk [$w mark next $mk]
    }
    return $lstmks
  }

  # all three marks are found ONLY for the text widget
  # BUT NOT for its peer - BUG?
  tk_messageBox -message "[getmks .t]\n[getmks .pt]"

  ------------

  This is on Windows XP with Tcl/Tk 8.5.9, and it happens also on Vista with 8.6b1.


tkt_uuid: 3480634fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: PNG Images missing in menus on Mac
comment:
  The TK function ImgPhotoDisplay is used to display transparent or non-transparent images. If an image is transparent, the code combines it with a window background. It first calls XGetImage to get the background (presumably another image) then combines the results with the image. Using XQuartz  2.6.3 (Mac OS X 10.7) many PNG images are not displayed in TK menus because XGetImage fails (10.6 with an older version of XQuartz seems to work). PNG images frames seem to work fine. Perhaps this is a timing issue since TK menus are mapped and them immediately drawn (?). This appears to be a bug in XQuartz. To work around the problem, I changed ImgPhotoDisplay to check for an error and use the non-transparent section of the code. This means the background will not be combined with the image. However, for our use case (TK menus), there is no background image (it is just a solid background) so this seems to solve the problem. We are build tcl/tk 8.5.6 for Unix (not Coco or Carbon) on Mac OS.


tkt_uuid: 1630271fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5.10
resolution: Fixed
title: segfault/infinite loop when a mark is before -startline
comment:
  Normally you can't access characters before -startline because "1.0" refers to the beginning of -startline. But marks get around that little hindrance!

  pack [text .t] -side top
  .t insert end "1\n2\n3\n"
  .t mark set insert 1.0
  .t conf -startline 2

  # This gives a weird result, "0.0"
  .t index insert

  # This will segfault
  .t index insert-1c

  # This will infinite loop and gobble up all yer memory
  .t get insert


tkt_uuid: 3529745fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.6b2
resolution: Fixed
title: trunk build broken
comment:
  Starting with checkin 578f0bf246 Tk does not build on unix.

  gcc -O2  -pipe    -Wl,--export-dynamic  tkAppInit.o -L/home/dgp/fossil/tk/unix -ltk8.6 \
                  -L/home/dgp/fossil/tcl-only/unix -ltcl8.6  -lpthread -lXft -lXrender -lfontconfig -lfreetype -lX11   -L/usr/lib64 -lX11 -lXss -lXext -ldl -lz  -lpthread -lieee -lm  -Wl,-rpath,/home/dgp/x86_64/linuxoldld/lib:/usr/lib64 -o wish
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc58): undefined reference to `TkClipBox'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc60): undefined reference to `TkCreateRegion'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc68): undefined reference to `TkDestroyRegion'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc70): undefined reference to `TkIntersectRegion'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc78): undefined reference to `TkRectInRegion'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc80): undefined reference to `TkSetRegion'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xc88): undefined reference to `TkUnionRectWithRegion'
  /home/dgp/fossil/tk/unix/libtk8.6.a(tkStubInit.o):(.data.rel.ro+0xd58): undefined reference to `TkSubtractRegion'

  Shoved broken commits to a mistake branch to preserve bisectability of
  the trunk.


tkt_uuid: 2999889fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: TkCopyAndGlobalEval obsolete
comment:
  In the Changelog I see (see below)...

  Would it not be better just to remove it from
  the stub table?
  =======================================
  2009-07-23  Donal K. Fellows  <dkf@users.sf.net>
      ....
      (LostSelection, Tk_SelectionObjCmd): Stop using the vastly inefficient
      TkCopyAndGlobalEval; better to use Tcl_Obj refcount management.


tkt_uuid: 3472539fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Moving the cursor in elided text freezes Tk
comment:
  The attached patch fixes item 3021557:

  Moving the cursor in elided text freezes Tk:
  https://sourceforge.net/tracker/?func=detail&aid=3021557&group_id=12997&atid=112997

  The patch is against the latest Fossil sources.

  The existing text.test suite passes with no failure (but one completely unrelated: text-33.11).
  I have added one test item for issue 3021557 that the patch is fixing.


tkt_uuid: 3380684fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk 8.5.10 XEmptyRegion prototype doesn't match usage
comment:
  xlib/X11/Xutil.h:367 gives a declaration for XEmptyRegion() that returns (void), however unix/tkUnixDraw.c:94 expects to get and use a return value -- this causes build failure when those headers are used.  Another system's X11 headers specify an (int) return value.

  $ grep -n XEmptyRegion xlib/X11/Xutil.h unix/tkUnixDraw.c
  xlib/X11/Xutil.h:367:extern void XEmptyRegion(
  unix/tkUnixDraw.c:94:    if (XEmptyRegion((Region) damageRgn)) {


tkt_uuid: 2257424fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Invalid
title: screenwidth incorrect on multiple monitors
comment:
  The winfo screenwidth . returns 1920 on Windows XP SP2 with dual monitors and the screen spread across both monitors (and the . in the second monitor) whereas winfo geom . returns 200x200+2717+546. The geometry is correct but the screenwidth is not. How do I get the correct screen width in this case. Windows handles this as a single screen (at least it appears to).


tkt_uuid: 3600390fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: current: 8.6.0
resolution: Fixed
title: tk_strictMotif not tested for
comment:
  library/tk.tcl

  The text widget has "emacs-like bindings", some of which have been combined with other bindings to trigger virtual events.

  For example, on X11 the "emacs-like binding" event <Control-Key-b> and the event <Left> each trigger the virtual event <<PrevChar>>.

  Before the bindings were combined, they had slightly different code: the "emacs-like bindings" all tested $::tk_strictMotif, and did nothing if this value was true.

  The bug is that this test of $::tk_strictMotif has not been preserved.

  I don't know if any users still want ::tk_strictMotif; however, if we want to keep it, the "emacs-like bindings" will need to be added and removed from their virtual events by the command ::tk::EventMotifBindings, which traces ::tk_strictMotif.


tkt_uuid: 533519ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Fixed
title: Window placement with multiple screens
comment:
  Using multiple screens under MS Windows there are a
  number of minor issues to do with window placement.

  Firstly there is no way to find out from Tk the real
  screen area. Windows arranges multiple monitors as a
  single large desktop. In my case I have two 1152x864
  screens. The primary monitor to the right and the
  secondary monitor to the left. With this setup my
  available desktop geometry goes from -1152 to +1152 and
  0 to 864. In other words under MS Windows and window
  may have a negative placement. This is currently
  handled OK by the wm geometry command. To place a
  toplevel on the left hand monitor I can do wm geometry
  . 100x100+-1152+0 and it is placed in the top lefthand
  corner of the secondary monitor.

  However, placing . on monitor 2 and creating a second
  toplevel (.t) places the new window on the primary
  monitor. Calling tk::PlaceWindow .t widget . places .t
  at the corrent vertical position but on the wrong monitor.
  This is because of the bounds checking in the
  PlaceWindow function. We can fix this by not doing the
  bounds checking for Windows except that it would be
  better to do the bounds checking. But we cannot find
  out the extent of the desktop from Tk. The attached
  program (multimon.c) shows a Windows way to get the
  information but I'm not sure where within Tk it should
  be placed. Possibly the winfo vrootwidth and
  vrootheight but that doesn't give us the offsets. In my
  case vrootwidth is going to be 2*1152 but I need to be
  able to find out that my coordinates go from -1152 to
  +1152.


tkt_uuid: 3505465fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5.10
resolution: Invalid
title: Error with "selection get"
comment:
  I'm using TkDND for dropping (X11 lib), and if I'm dropping files from Konqueror with "selection get -type text/plain..." I get the error message 'bad format for selection: wanted "32", got 8"'. I think that in case of 8 bit formats the function TkSelEventProc() should convert to a string in the system encoding, because throwing an error is inadequate, especially while "text/plain" is one of the most common drag types under X11. If the Tk library cannot handle "text/plain" (or other important string types), dropping files from other applications seems to be impossible.


tkt_uuid: 1353416fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.4.11
resolution: Fixed
title: tk_popup posts menu at the wrong place
comment:
  The bug occurs when tk_popup tries to post a menu at 
  a position that does not allow to display the full menu 
  height on screen.

  The problem can be reproduced with this simple script 
  to launch in wish:

  menu .m
  for {set i 0} {$i<15} {incr i} {
      .m add command -label "hello $i"
  }
  bind . <Button-1> { \
      tk_popup .m \
              [winfo pointerx .] \
              [winfo pointery .] \
  }

  Enlarge or move the . window so as its lower border is 
  near the lower border of the screen and click button-1 in 
  this area.

  Since the menu is too tall to fit in the screen if the first 
  line is placed at the cursor position, Tk computes a new 
  placement point of the menu.

  This computation must be incorrect since the menu is 
  posted much too far away upwards.

  Note however that the behaviour appears to be OK wrt 
  the right side of the screen.

  This is with Tck/Tk 8.4.11.
  It is OK with 8.5 alpha release.


tkt_uuid: 1513517fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 4
foundin: obsolete: 8.4.15
resolution: Wont Fix
title: .text search -regexp wraps despite stopIndex is specified
comment:
  The help page for the text widget states that (.text 
  search command):

  If stopIndex is omitted, the entire text will be 
  searched: when the beginning or end of the text is 
  reached, the search continues at the other end until 
  the starting location is reached again; if stopIndex 
  is specified, no wrap-around will occur.

  However, the following demonstrates that wraparound 
  occurs when start and stop indices are both equal to 
  [.t index end]

  text .t
  pack .t
  .t insert end "hello1\n"
  .t insert end "hello2\n"
  .t insert end "hello3\n"
  .t insert end "hello4\n"
  set ind [.t index end]

  # WRONG: returns 1.0 -> it wraps!
  .t search -regexp -- "^" $ind $ind

  # CORRECT: returns 5.0
  .t search -regexp -- "^" $ind-1c $ind

  # WRONG: returns 1.2 -> it wraps!
  .t search -- "llo" $ind $ind           

  # CORRECT: returns ""
  .t search -- "llo" $ind-1c $ind


  Therefore, contrary to the claims of the manual, the 
  search wraps if the start and stop indices are both 
  equal to [.t index end] (which is not so uncommon 
  during a search for all the occurrences of a string 
  in a text).


  Francois


tkt_uuid: 3476698fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: None
resolution: Fixed
title: Patch for failing test text-31.11
comment:
  The attached patch fixes item 3475627:

  https://sourceforge.net/tracker/index.php?func=detail&aid=3475627&group_id=12997&atid=112997

  The patch is against the latest core-8-5-branch.


tkt_uuid: 1169429fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: insertofftime 0 should not hide the cursor in text widgets
comment:
  Background:
  A text widget with a blinking cursor.

  Issue:
  After the widget is created, using -insertofftime 0 to stop 
  the cursor blinking stops it in the state the cursor is at 
  the time the above command is processed. The cursor 
  can therefore be off, depending on when insertofftime 0 
  was processed.

  What it should be (IMHO):
  Using -insertofftime 0 should stop blinking the cursor 
  and always display it.

  To reproduce the issue:
  In a wish session, type:
  text .t -insertofftime 500 -insertontime 500
  pack .t
  .t insert insert "This is a blinking cursor test.     "
  bind Text <Shift-Button-3> { %W configure -
  insertofftime   0 }
  bind Text <Button-3> { %W configure -insertofftime 500 }
  focus .t

  Now play with mouse button 3 and with the shift key to 
  stop the blinking and start it again.

  You can easily show that the cursor stops blinking in 
  the state it is in when tk processes the insertofftime 0.

  If you make it stop blinking when it is on, then it 
  remains visible in the widget, otherwise it is hidden and 
  does not reappear until blinking is restored using button-
  3 (try typing text in the widget, or click button1 for 
  instance).


tkt_uuid: 3487407fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Weird indices
comment:
  text .t
  pack .t
  for {set i 1} {$i < 10} {incr i} {
    .t insert end "Line $i\n"
  }
  .t mark set insert 1.0
  .t configure -start 5 -end 5
  .t index insert

  This returns:
  *    -3.0 in Tk 8.5.9
  *    0.6 in core-8-5-branch
  *    "bad text index" error in bug-1630262 branch

  The question is what the correct output should be for this text widget showing ZERO lines (since -startline == -endline).

  Indices should be clamped to the -startline/-endline range of the text widget, so that no negative (or larger than the number of lines) index is ever returned. The two first answers are therefore both wrong.

  Also in core-8-5-branch is the fix for bug 1630271 (commit 61a3685ac2), which makes the "bad text index" error in branch bug-1630262: marks located outside the -startline/-endline range being not reachable from the considered peer, an error is thrown.

  I think "bad text index" is the right answer in this "corner" case.

  The problem then is consistency, since:

  .t mark names            ;# --> insert current
  .t index current         ;# --> 1.0


tkt_uuid: 1273358fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Ask a text widget for the depth of its undo and redo stacks
comment:
  I would like to have a way to query the current depth of 
  the undo and redo stacks of a text widget.

  This would allow to enable/disable contextually Undo 
  and Redo commands in applications.

  Whether the undo stack is empty or not can be known 
  by querying the modified flag (although this is not 
  equivalent, but I can set the modified flag manually in 
  such a way that it is).

  I have however no solution for the redo stack depth. How 
  can I know if it's zero or not? Currently I have to track 
  manually any editing in my text widget, this is 
  cumbersome and greatly lowers the interest of using the 
  embedded .text edit commands.

  In summary please add a command that gives the 
  current depth of each stack, or at least a command that 
  says if the depths are zero or not.

  Thanks,
  Francois


tkt_uuid: 3554081fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.12
resolution: Fixed
title: Test bind-22.10 fails
comment:
  In core-8-5-branch and core-8-4-branch as well:

  ==== bind-22.10 HandleEventGenerate FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Key> {set x "%s %K"}
      set x {}
      event gen .b.f <Control-Key-1>
      set x

  ---- Result was:
  5 1
  ---- Result should have been (exact matching):
  4 1
  ==== bind-22.10 FAILED


  This was fixed a long time ago in trunk. See the bottommost comment in bug 2307387.
  Citing what was said there:
  "bind-22.10: it is due to the test case using a numeric character ("1") which has different layouts depending on keyboard locale. Using a more consensual key makes it universal."

  Consensual key chosen in the trunk version of this test is space, which seems to be a clever choice indeed.

  I will fix bind-22.10 accordingly in both core-8-5-branch and core-8-4-branch.


tkt_uuid: 1236306fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: TraverseToMenu error with alt binding to toplevel destroy
comment:
  Consider the following three-line script:

  toplevel .t
  bind .t <Alt-a> {destroy .t}
  bind .t <Alt-b> {after 0 destroy .t}
  bind .t <Alt-c> {destroy .t;break}

  Pressing Alt-a displays an error message:

  bad window path name ".t"
  bad window path name ".t"
      while executing
  "winfo class $w"
      (procedure "tk::TraverseToMenu" line 6)
      invoked from within
  "tk::TraverseToMenu .t a"
      (command bound to event)

  while Alt-b or Alt-c does not.

  This occurs on Linux, not on Windows, for Alt bindings 
  only (not for Control, Shift... bindings).


  Analysis of the problem:

  % toplevel .t
  .t
  % bindtags .t
  .t Toplevel all
  % bind all
  <<PrevWindow>> <Key-Tab> <Key-F10> <Alt-Key>
  % bind all <Alt-Key>
   tk::TraverseToMenu %W %A

  The bindtags are processed in turn. <Alt-a> binding 
  for .t is executed first. There is no matching binding for 
  Toplevel, but there is a binding for the Alt key for the all 
  bindtag. So this one is executed after the toplevel is 
  destroyed.

  The bug is therefore that tk::TraverseToMenu doesn't 
  check that the toplevel still exists.


tkt_uuid: f476e3d654b760c7626f1863b6e62294155f35c0
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
severity: Critical
foundin: trunk
resolution: Fixed
title: Tk trunk fails to build/link
comment:
  Starting with checkin

  http://core.tcl.tk/tk/info/ac37b02622

  a default (--enable-shared) build of Tk fails 
  to link building on a CentOS 5 linux x86_64 system:

  gcc -shared -O2  -pipe    -Wl,--export-dynamic  -o libtk8.6.so tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkBusy.o tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o tkStyle.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o tkImgPNG.o tkImgPPM.o tkImgPhoto.o tkImgPhInstance.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o tkStubInit.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 tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o  tkUnixRFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o   -lpthread -lXft -lXrender -lfontconfig -lfreetype -lX11   -L/usr/lib64 -lX11 -lXss -lXext -ldl -lz  -lpthread -lieee -lm -L/home/dgp/fossil/tcl/unix -ltclstub8.6  -Wl,-rpath,/home/dgp/x86_64/linuxoldld/lib:/usr/lib64
  /usr/bin/ld: tkWindow.o: relocation R_X86_64_PC32 against `tkStubs' can not be used when making a shared object; recompile with -fPIC
  /usr/bin/ld: final link failed: Bad value
  collect2: ld returned 1 exit status


tkt_uuid: 1638905fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Duplicate
title: Accented characters mess up underline shortcuts in menues
comment:
  Accented characters mess up underline shortcuts (accelerators) in menues

  If a menu label has accented characters located before the -underline position in the label, then the displayed label is correct (namely the underline is at the correct place) but the -command proc associated is not triggered when the item is invoked using the keyboard accelerator. Instead, the menu is simply unposted.

  Example code:

  menu .m
  menu .m.m1
  .m add cascade -menu .m.m1 -label "My menu" -underline 3
  .m.m1 add cascade -label "Aligne a gauche" -underline 9 \
    -command {tk_messageBox -message "OK with no accent"}
  .m.m1 add cascade -label "Aligné à gauche" -underline 10 \
    -command {tk_messageBox -message "NOK with accent"}
  . configure -menu .m


  Invoke the first item "Aligne a gauche" of the menu using the keyboard: Alt-m followed by Alt-g: the messageBox opens. Correct.

  Invoke the second item "Aligné à gauche" of the menu using the keyboard: Alt-m followed by Alt-a: the messageBox does NOT open. BUG.

  However, the messageBox that is supposed to open for Alt-a actually opens with Alt-Space (WRONG) ?!?

  This does not happen if the underline is before the first accented character.

  I tried this on Windows 2000 and XP SP2, with Tcl/Tk 8.4.14 binaries from ActiveState.

  However, when using Tcl/Tk 8.5 cvs version compiled by myself (using VS8), this issue does not show up.

  Francois


tkt_uuid: 1275237fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
foundin: obsolete: 8.4.11
resolution: Fixed
title: modified flag not managed when undoing certain text inserts
comment:
  The modified flag of the text widget is not well managed 
  by Tk when certain changes are undone.

  Example 1 (works OK):
  text .t -undo 1
  pack .t
  .t insert 1.0 "Hello world!   "
  .t edit reset
  .t edit modified false
  .t insert 1.14 "Goodbye!"
  puts [.t edit modified]
  .t edit undo
  puts [.t edit modified]

  The output in the console is:
  1
  0
  which is correct: the modified flag has been reset to 
  false by the undo.

  Example 2 (wrong results):
  text .t -undo 1
  pack .t
  .t insert 1.0 "Hello world!   "
  .t edit reset
  .t edit modified false
  .t insert 1.14 ""
  puts [.t edit modified]
  .t edit undo
  puts [.t edit modified]

  The only difference is that instead of 
  inserting "Goodbye!" the script inserts an empty 
  string "".

  The output in the console is in this case:
  1
  1
  i.e. the modified flag was not reset by the undo 
  operation.

  The undo has been correctly performed since a further .t 
  edit undo spits:
  nothing to undo

  This problem therefore concerns only the modified flag.


tkt_uuid: 1224330fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.4.13
resolution: Fixed
title: Bug in menu delete
comment:
  The following code shows a bug in the windows menu 
  implementation:

  menu .menu
  for {set i 0} {$i<20} {incr i} {
    .menu add command -label "Entry $i" -command \
    "tk_messageBox -message \"Entry $i!\""
  }
  .menu delete 10
  pack [menubutton .m -menu .menu -text Menu]

  Menu entries below the deleted item are not selectable. 
  If clicked, the last entry before the deleted one is 
  executed.

  I submit this bug as a new one because I don't know 
  how to reopen bug 525111.

  This happens on Win XP SP2 with the ActiveState 
  binary distribution of Tcl/Tk 8.4.10.


tkt_uuid: 3554052fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: None
title: Test textTag-15.1 fails
comment:
  In core-8-5-branch, on Windows Vista, test textTag-15.1 fails when it is executed after test text-36.* in a combined run.


  To demonstrate the issue, run the entire test suite of Tk, or just the tests such that "-file text*.test", or more minimally:

  set MYTCL="<path>\tcltk-fossil\tcl-fossil"
  set MYTK="<path>\tcltk-fossil\tk-fossil"
  cd %MYTK%\win
  nmake -f makefile.vc test OPTS=symbols TCLDIR=%MYTCL% TESTFLAGS="-file text{,Tag}.test"

  This will run the tests from files text.test and testTag.test in turn, and only those from these files, in the local fossil repositories.

  Then you get the failure:

  ==== textTag-15.1 TkTextBindProc FAILED
  ==== Contents of test case:

      bind .t <ButtonRelease> {lappend x up}
      .t tag bind x <ButtonRelease> {lappend x x-up}
      .t tag bind y <ButtonRelease> {lappend x y-up}
      set x {}
      .t tag add x 2.0 2.4
      .t tag add y 4.3
      event gen .t <Button> -x $x1 -y $y1
      event gen .t <Motion> -x $x1 -y $y1
      event gen .t <ButtonRelease> -x $x1 -y $y1
      event gen .t <Button> -x $x1 -y $y1
      event gen .t <Motion> -x $x2 -y $y2
      event gen .t <ButtonRelease> -x $x2 -y $y2
      event gen .t <Button> -x $x2 -y $y2
      event gen .t <Motion> -x $x3 -y $y3
      event gen .t <ButtonRelease> -x $x3 -y $y3
      bind .t <ButtonRelease> {}
      set x

  ---- Result was:
  up up up
  ---- Result should have been (exact matching):
  x-up up up y-up up
  ==== textTag-15.1 FAILED


  Running textTag.test alone does not trigger the problem: textTag-15.1 passes in this case.

  The problem shows up however when text.test is run before textTag.test.

  Trimming down:
    - not running just text-36.1 (nor 36-2 nor 36-3) makes textTag-15.1 pass
    - the issue is then in the interaction between those tests when run all in a row

  Further narrowing down, I've come up with the following script to demonstrate the problem:


  pack [text .t1]
  event generate .t1 <1>
  destroy .t1

  pack [text .t -width 20 -height 10]
  .t insert 1.0 "Line 1"
  update

  set c [.t bbox 1.1]
  set x1 [expr [lindex $c 0] + [lindex $c 2]/2]
  set y1 [expr [lindex $c 1] + [lindex $c 3]/2]
  bind .t <ButtonRelease> {lappend x up}
  .t tag bind x <ButtonRelease> {lappend x x-up}
  set x {}
  .t tag add x 1.0 1.4
  event generate .t <Button> -x $x1 -y $y1
  event generate .t <Motion> -x $x1 -y $y1
  event generate .t <ButtonRelease> -x $x1 -y $y1

  set x

  #  x-up up   is expected,  however most of the time (but not always) simply
  #  up        is output, which is wrong

  destroy .t


  This script seems to be minimal.

  To show the issue, launch wish, and paste the script in in at once. The output should be:

  x-up up

  but is is:

  up

  most of the time, although not always!


  The trimmed test case above demonstrates the problem at least in 8.5 from core-8-5-branch, or core-8-4-branch, or 8.5.9 precompiled binaries from Activestate.
  I could not reproduce the problem in trunk so far.


  Clueless...


tkt_uuid: 52ca3e7f551a249e48cea9217adbfb8f15d681fc
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
severity: Minor
foundin: 8.5.15
private_contact: e6e0da3db38bd7f7aaef501760314ad0221f3e23
resolution: Fixed
title: XkbOpenDisplay macro incorrect when HAVE_XKBKEYCODETOKEYSYM is not defined
comment:
  When HAVE_XKBKEYCODETOKEYSYM is not defined, unix/tkUnixEvent.c defines a macro:
  #  define XkbOpenDisplay(D,V,E,M,m,R) (V),(E),(M),(m),(R),(NULL)
  I think the intention was that all terms are evaluated and NULL is returned. However, the comma operator (,) has a lower precedence than the assignment operator (=) (Thanks to Arjen Markus for spotting that). So when lateron the following command is executed:
  display = XkbOpenDisplay(displayNameStr, &event, &error, &major, &minor, &reason);
  display gets the address of event, instead of NULL. As a result the wrong path is taken, which eventually leads to a SEGFAULT.

  Proposed solution: Add an extra pair of parentheses to the define:
  #  define XkbOpenDisplay(D,V,E,M,m,R) ((V),(E),(M),(m),(R),(NULL))


tkt_uuid: 1517768fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: wish does not know about tcl_wordchars
comment:
  tcl_wordchars and tcl_nonwordchars are unknown to 
  wish:

  1 % info patchlevel
  8.4.13
  2 % puts $tcl_wordchars
  can't read "tcl_wordchars": no such variable
  3 % catch {tcl_endOfWord}
  1
  4 % puts $tcl_wordchars
  \S


  Though catch {tcl_endOfWord} make wish aware of these 
  variables, this is only a workaround. These variables 
  should be auto-loaded along with the commands they 
  control.

  See also:
  http://groups.google.fr/group/comp.lang.tcl/browse_thr
  ead/thread/659fd6c1f41d9a81/4a3c30d2c97604cc

  Francois


tkt_uuid: 3469780fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Additional options for text widget tags
comment:
  Proposals for implementation of  Tk Feature Request #1759972

  https://sourceforge.net/tracker/?func=detail&aid=1759972&group_id=12997&atid=362997


tkt_uuid: 3479498fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: None
resolution: Fixed
title: no limit to -blockcursor width
comment:
  The attached patch fixes items 1754043 and 2321450 (which really are dups):

  no limit to -blockcursor width:
  https://sourceforge.net/tracker/?func=detail&aid=1754043&group_id=12997&atid=112997

  Text widget block cursor problem:
  https://sourceforge.net/tracker/?func=detail&aid=2321450&group_id=12997&atid=112997

  The patch is against core-8-5-branch.


tkt_uuid: 1217762fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.10
resolution: Invalid
title: panedwindow geom manager bug when sash was moved
comment:
  I try to make a button visible at all times at the bottom 
  of a window containing a panedwindow with two panes 
  and a frame containing a button.

  When I resize the window by dragging its lower border, 
  everything seems to go well *if the sash was not moved 
  before*. Otherwise the button gets clipped.

  I read in the man panedwindow that the panedwindow 
  resizes its last pane to fill its allocated space, and this 
  is what's actually happening *only when the sash was 
  never moved before*. If the sash has been moved, then 
  the wm clips first the button and only after that it 
  resizes the last pane.

  I believe this is a bug of the geometry manager.

  Here is a snippet to reproduce:

  #########
  wm resizable . 1 1
  panedwindow .pw -orient vertical
  label .pw.x1 -text Upper -fg orange -bg black
  label .pw.x2 -text Lower -fg white -bg red
  .pw add .pw.x1 -minsize 150
  .pw add .pw.x2 -minsize 100
  pack .pw -fill both -expand yes
  frame .f
  button .f.b -text "hello!"
  pack .f.b
  pack .f
  update
  wm minsize . [winfo width .] [winfo height .]
  set initminh [lindex [wm minsize .] 1]
  bind . <Configure> { \
    set sashcoord [.pw sash coord 0];\
    set madedown [expr [lindex $sashcoord 1] - 154];\
    set newminheight [expr $initminh + $madedown];\
    wm minsize . 200 $newminheight; \
  }
  #########

  Run this in a wish session, and try to resize the 
  window -> the button is never clipped.

  Now move the sash down, then move it up, and try to 
  resize again -> the button gets clipped!!

  The geometry manager should first remove the extra 
  space in .pw.x2 before it clips the frame. I found no way 
  to manually set the height of .pw.x2

  Note that I use Tcl/Tk 8.4.10 (patch 1124198 is 
  therefore already in use).

  Francois


tkt_uuid: 1357575fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Fixed
title: Unclear defn of result of text widget index with modifiers
comment:
  Index computation results in text widget depends on 
  the modifiers order.
  This simple script reproduces the problem:

  text .t
  pack .t
  .t insert 1.0 "this is a test text\n"
  .t insert 2.0 "this is the second line\n"
  .t insert 3.0 "this is the last line."
  puts [.t compare "1.0 - 1l + 1l" == "1.0"]
  puts [.t compare "1.0 + 1l - 1l" == "1.0"]
  puts [.t compare "1.0 - 1c + 1c" == "1.0"]
  puts [.t compare "1.0 + 1c - 1c" == "1.0"]
  puts [.t compare "3.0 + 2l - 2l" == "3.0"]
  puts [.t compare "3.0 - 2l + 2l" == "3.0"]
  puts [.t compare "4.0 + 1c - 1c" == "4.0"]
  puts [.t compare "4.0 - 1c + 1c" == "4.0"]

  All the comparison results should be 1 since 
  (mathematically) there is no preferred order in 
  adding/substracting one line or character.

  I believe Tcl analyzes the index string "base 
  modifier modifier..." by taking each modifier once at 
  a time, computes the new resulting index, and checks 
  for the text widget bounds at each iteration.
  It should check for bounds only at the end of the 
  index computation.

  The text widget man page tells that modifiers are 
  applied from left to right, that's OK, but it doesn't 
  tell that the boundaries are checked for each 
  intermediate result.

  The boundaries should be checked only when all the 
  modifiers have been applied. If this is not possible, 
  at the very least the man page should warn that the 
  widget checks bounds after applying each modifier.

  Occurs on Tcl/Tk 8.5 alpha and 8.4.11 as well.


tkt_uuid: 1192323fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: panedwindow resize problem with minsize
comment:
  The last pane of a panedwindow can get clipped even if -
  minsize option is given.

  This happens when the toplevel in which the 
  panedwindow is packed is resized.

  Consider the following:

  wm resizable . 1 1
  wm minsize . 80 260
  panedwindow .pw -orient vertical
  label .pw.x1 -text Upper -fg orange -bg black
  label .pw.x2 -text Lower -fg white  -bg red
  .pw add .pw.x1 -minsize 150
  .pw add .pw.x2 -minsize 100
  pack .pw -fill both -expand yes
  set compt 0
  set initialminheight [lindex [wm minsize .] 1]
  bind . <Configure> { \
   set sashcoord [.pw sash coord 0];\
   set madedown [expr [lindex $sashcoord 1] - 154];\
   set newminheight [expr $initialminheight + 
  $madedown];\
   wm minsize . 80 $newminheight; \
   incr compt ; \
   .pw.x1 configure -text \
     "$compt\nwm minsize .: [wm minsize .]\n\
     winfo height .:[winfo height .]\n\
     .pw.x2 -minsize: [.pw panecget .pw.x2 -minsize]\n\
     .pw.x2 -height: [.pw panecget .pw.x2 -height]" ; \
  }

  Then:

  1. Resize the window (increase its height by dragging 
  down the lower border).
  2. Move the sash down as far as possible. -minsize is 
  used for pane 2, wich is OK
  3. Move the sash up as far as possible. -minsize for 
  pane 1 is OK
  4. Resize the window by decreasing its height (drag up 
  the lower border), until to the wm minsize is hit
  5. Move the sash down. And... it moves and reduces 
  size of pane 2 without to take its minsize into account!!! 
  This is WRONG behavior.
  6. (optional) Now, if you just click on the window border 
  so that a further Configure event is fired, you can see 
  the window size increasing (thanks to the binding), and 
  again taking toplevel minsize into account (but not 
  panes minsize).

  Besides, panecget -height is always empty. Is this 
  normal?


tkt_uuid: 3554273fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: None
resolution: Fixed
title: Test textDisp-32.2 (elide and tags) fails
comment:
  In both core-8-5-branch and trunk:


  ==== textDisp-32.2 elide and tags FAILED
  ==== Contents of test case:

      pack [text .tt -height 30 -width 100 -bd 0  -highlightthickness 0 -padx 0]
      .tt insert end  {test text using tags 1 and 3 }  {testtag1 testtag3}  {[this bit here uses tags 2 and 3]}  {testtag2
   testtag3}
      update
      # indent left margin of tag 1 by 20 pixels
      # text should be indented
      .tt tag configure testtag1 -lmargin1 20 ; update
      #1
      set res {}
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      # hide tag 1, remaining text should not be indented, since
      # the indented tag and character is hidden.
      .tt tag configure testtag1 -elide 1 ; update
      #2
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      # reset
      .tt tag configure testtag1 -lmargin1 0
      .tt tag configure testtag1 -elide 0
      # indent left margin of tag 2 by 20 pixels
      # text should not be indented, since tag1 has lmargin1 of 0.
      .tt tag configure testtag2 -lmargin1 20 ; update
      #3
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      # hide tag 1, remaining text should now be indented, but
      # the bbox of 1.0 should have zero width and zero indent,
      # since it is elided at that position.
      .tt tag configure testtag1 -elide 1 ; update
      #4
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      # reset
      .tt tag configure testtag2 -lmargin1 {}
      .tt tag configure testtag1 -elide 0
      # indent left margin of tag 3 by 20 pixels
      # text should be indented, since this tag takes
      # precedence over testtag1, and is applied to the
      # start of the text.
      .tt tag configure testtag3 -lmargin1 20 ; update
      #5
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      # hide tag 1, remaining text should still be indented,
      # since it still has testtag3 on it.  Again the
      # bbox of 1.0 should have 0.
      .tt tag configure testtag1 -elide 1 ; update
      #6
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      .tt tag configure testtag3 -lmargin1 {} -elide 0
      .tt tag configure testtag1 -elide 1 -lmargin1 20
      #7
      lappend res [list [.tt index "1.0 + 0 displaychars"]  [lindex [.tt bbox 1.0] 0]  [lindex [.tt bbox "1.0 + 0 displayc
  hars"] 0]]
      destroy .tt
      set res

  ---- Result was:
  {1.0 20 20} {1.0 0 0} {1.0 0 0} {1.0 0 0} {1.0 20 20} {1.0 0 0} {1.0 20 20}
  ---- Result should have been (exact matching):
  {1.0 20 20} {1.29 0 0} {1.0 0 0} {1.29 0 20} {1.0 20 20} {1.29 0 20} {1.0 20 20}
  ==== textDisp-32.2 FAILED


tkt_uuid: 8d2727603bb536c27ca459aecdd0587438f12c29
type: Patch
status: Deleted
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Important
foundin: 8.5.15
private_contact: 52df431b9651beac94738e9df4f98b1baf22d28a
resolution: Duplicate
title: ttk::combobox -> popdown menu tip
comment:
  Hi there,

  The idea of this patch is to allow for large string value being displayed correctly, whatever the width of the combobox itself.
  Regards,

  Eloi



  Index: combobox.tcl
  ===================================================================
  --- combobox.tcl        (revision 72244)
  +++ combobox.tcl        (working copy)
  @@ -374,11 +374,19 @@
       }

       set H [winfo reqheight $popdown]
  +    set W [winfo reqwidth $popdown]
       if {$y + $h + $H > [winfo screenheight $popdown]} {
          set Y [expr {$y - $H}]
       } else {
          set Y [expr {$y + $h}]
       }
  +    set values [$cb cget -values]
  +    set font [$cb cget -font]
  +    foreach val $values {
  +      set lval [string len $val]
  +      set mwidth [font measure $font " $val"]
  +      if {$W<$mwidth} { set w $mwidth }
  +    }
       wm geometry $popdown ${w}x${H}+${x}+${Y} }


tkt_uuid: 1217222fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: [.textw edit undo] return ranges of modified characters
comment:
  I would like the text widget command edit undo to return 
  as a result the range(s) of characters in the widget that 
  were modified (impacted) by the undo operation.

  This would allow to apply special processing to these 
  ranges, e.g. colorize these chars, flash them, and so on.

  Same request for redo, of course.

  Thanks,
  Francois


tkt_uuid: 1281228fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a3
resolution: Fixed
title: Text widget -strictlimits option ignored and undocumented
comment:
  The text widget -strictlimits option for search that was 
  part of the already implemented TIP 155 is 
  undocumented.

  Moreover, this option does not spit any error when used, 
  but it is apparently simply ignored.

  Test case:

  text .t
  pack .t
  .t insert 1.0 "Hello world!\n"
  .t insert 2.0 "This is a test\n"
  set match [.t search -strictlimits -- \
      "world" 1.3 1.8]
  puts $match

  The search occurs between positions 1.3 and 1.8, i.e. 
  the search area does not include the full word "world" 
  that is searched for.

  Nevertheless, a match is found, which means that .t 
  search does not check whether the match it finds is 
  entirely included in the search area or not, despite the 
  presence of the -strictlimits option.

  In a clt thread (see 
  http://groups.google.fr/group/comp.lang.tcl/browse_threa
  d/thread/e80f2586408ab598/2a3660c107cd21ba?
  lnk=st&q=search+unexpected+group:comp.lang.tcl&rnu
  m=1&hl=fr#2a3660c107cd21ba) I was told that some of 
  the implementation of -strictlimits was forgotten, e.g. for 
  regexps. The example above is however no regexp, and 
  the scope of this bug is probably not limited to this sort 
  of search.

  Francois


tkt_uuid: 1871474fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: <<Modified>> does not trigger
comment:
  The <<Modified>> event is sometimes not generated when the text widget changes state, despite what the man states.

  It looks like the fix for bug 1799782 (and 687522) that made it into 8.5.0 at the last minute seems to have created this bug.

  For instance:

  1 % info patchlevel
  8.5.0
  2 % text .t
  .t
  3 % pack .t
  4 % bind .t <<Modified>> {puts "EVENT"}
  5 % .t edit modified
  0
  6 % .t insert end "Hello"
  EVENT
  7 % .t edit modified
  1
  8 % .t edit modified false
  9 % .t edit modified
  0
  10 % 

  The modified flag is correctly automatically set to true when text is inserted.

  Then the modified flag is manually reset to false.

  This latter action should generate a <<Modified>> event, which does not happen. The manual indeed says that "Whenever the flag changes state a <<Modified>> virtual event is generated."


  Francois


tkt_uuid: 1ce993240c082f85b8226a6d60d0d76590c83a47
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
severity: Minor
foundin: GNU/Linux
private_contact: 15b50f662a7123351188edad1af5b78d43719726
resolution: None
title: set wm geometry fails from a script
comment:
  Version #1 SMP Mon Nov 11 03:23:58 EST 2013
  <p>
  All my widgets started popping up at +0+0 a while back. I have a simple example that fails on my Linux.
  <pre>
  #!/bin/sh
  # \
  exec /usr/bin/wish "$0" ${1+"$@"}

  wm geometry . 300x200+500+200
  wm title . "The tk_wm problem!"
  </pre>
  This window pops ups at +0+0.
  <p>
  However, the above commands work from a wish command line, as follows:
  <pre>
  Linux -> /usr/bin/wish
  % wm geometry . 300x200+500+200
  % wm title . "The tk_wm problem!"
  </pre>
  This window pops up at +500+200.


tkt_uuid: 3475627fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Test text-31.11 fails
comment:
  ==== text-31.11 peer widget -start, -end FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      for {set i 1} {$i < 100} {incr i} {
          .t insert end "Line $i\n"
      }
      set res [.t index end]
      lappend res [catch {.t configure -start 5 -end 15}]
      lappend res [.t index end]
      lappend res [catch {.t configure -start 10 -end 40}]
      lappend res [.t index end]
      .t configure -start {} -end {}
      lappend res [.t index end]
      set res

  ---- Result was:
  101.0 0 97.0 0 92.0 101.0
  ---- Result should have been (exact matching):
  101.0 0 11.0 0 31.0 101.0
  ==== text-31.11 FAILED


  Happens on both core-8-5-branch and trunk


tkt_uuid: 3545457fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 8
severity: Minor
foundin: obsolete: 8.4.19
resolution: Fixed
title: Crash on packing a menubutton with Tk 8.4.19
comment:
  Crash on packing a menubutton with Tk 8.4.19 (core-8-4-branch)

  Test case:

  menubutton .mb
  pack .mb  ;  # crash!


  Happens with 8.4 only, not with 8.5 or trunk.

  The issue is missing initialization of variables width and height inTkpDisplayMenuButton in file unix/tkUnixMenubu.c

  This problem has been fixed on 2007-04-25 19:08 by:
    9c8837c194 * unix/tkUnixMenubu.c (TkpDisplayMenuButton): init width/height to 0
  but apparently only in the trunk (of this time, which is now core-8-5-branch).


tkt_uuid: 3f456a5bb980e9db5e5dd39db2f40b8021fb428f
type: Patch
status: Open
subsystem: 09. [listbox]
priority: 7 High
severity: Minor
foundin: 8.6
resolution: None
title: Patches for listbox right justify
comment:
  I created patches for listbox right justify (reused patches from 8.4):
  https://bitbucket.org/tombert/tcltk/src/38880b7dbf1e/patches/tcltk86/?at=master


tkt_uuid: 1626415fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Text widget documentation bug
comment:
  The text widget documentation says:

  Command-Line Name: -inactiveselectionbackground 
  Database Name: inactiveSelectionBackground 
  Database Class: Foreground 
  Specifies the colour to use for the selection (the sel tag) when the window does not have the input focus. If empty, {}, then no selection is shown when the window does not have the focus. 


  Actually the -inactiveselectionbackground does not exist.

  Correct spelling is -inactiveselectbackground

  Don't know whether the database name is correct or not.

  Francois


tkt_uuid: 1281243fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Wont Fix
title: panedwindow sash coord documentation bug
comment:
  Documentation for .panedwindow sash coord says:

  Return the current x and y coordinate pair for the sash 
  given by index. Index must be an integer between 0 and 
  1 less than the number of panes in the panedwindow. 
  The coordinates given are those of the top left corner of 
  the region containing the sash.

  1.
  "between 0 and 1" is clearly wrong and should be 
  suppressed.

  2.
  In what coordinate system are these x and y returned?


  Francois


tkt_uuid: 1578519fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5b2
resolution: Invalid
title: tk_getOpenFile -multiple 1 fails the first times
comment:
  tk_getOpenFile -multiple 1  fails the first times 
  (WinXP)

  The above instruction correctly opens the (native) 
  WinXP dialog, and allows the user to select more than 
  one file as expected.

  A problem happens however when the user, before 
  selecting his files, clicks on the "Desktop" shortcut 
  icon located in the left pane of the dialog. In such 
  a case, on clicking on the Open button from the 
  dialog, a popup window shows up saying that the file 
  cannot be found and that the user should check the 
  filename.

  Further observations:

  a. Navigating by hand to the same location as the 
  shortcut points to (usually C:\Documents and 
  Settings\<USER>\Desktop) does not produce the same 
  problem.

  b. It does not happen when the -multiple 1 option is 
  not set.

  This happens again and again until tk_getOpenFile 
  returns at least one filename. To repeat the bug, 
  you'll have to start a new wish session.

  Francois


tkt_uuid: 1626419fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: Text widget documentation bug -inactiveselectionbackground
comment:
  The text widget documentation says:

  Command-Line Name: -inactiveselectionbackground 
  Database Name: inactiveSelectionBackground 
  Database Class: Foreground 
  Specifies the colour to use for the selection (the sel tag) when the window does not have the input focus. If empty, {}, then no selection is shown when the window does not have the focus. 


  Actually the -inactiveselectionbackground does not exist.

  Correct spelling is -inactiveselectbackground

  Don't know whether the database name is correct or not.

  Francois


tkt_uuid: 2045553fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.6a1
resolution: None
title: tk_getSaveFile -defaultextension disagrees with its man page
comment:
  The man page for -defaultextension in tk_getSaveFile states that:

  -defaultextension extension
  Specifies a string that will be appended to the filename if the user enters a filename without an extension. The default value is the empty string, which means no extension will be appended to the filename in any case. This option is ignored on Mac OS X, which does not require extensions to filenames, and the UNIX implementation guesses reasonable values for this from the -filetypes option when this is not supplied.

  So, if I read this correctly, *on Windows* using -defaultextension "" or without this option should provide the same result: a file with no extension (when the user does not force the extension in the filename it enters).

  However, on Win XP with 8.6a0 I get (I only type myfile in the dialog using the keyboard, with no extension):

  tk_getSaveFile -defaultextension "" -filetypes {{"xyz type" "*.xyz"}}
    ---> myfile.xyz
  tk_getSaveFile -filetypes {{"xyz type" "*.xyz"}}
    ---> myfile

  The latter should spit myfile.txt and not only myfile. On Windows, this is therefore a bug.

  On Linux, I get myfile.xyz for both commands, which is consistent with the man page.

  Can't test on Mac, sorry.

  Francois


tkt_uuid: 3553311fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.12
resolution: Fixed
title: Test spinbox-3.70 fails (core-8-5-branch)
comment:
  In core-8-5-branch, on Windows Vista:

  ==== spinbox-3.70 SpinboxWidgetCmd procedure, "xview" widget command FAILED
  ==== Contents of test case:

      .e xview moveto 0.5
      format {%.6f %.6f} {*}[.e xview]

  ---- Result was:
  0.505376 0.720430
  ---- Result should have been (exact matching):
  0.505376 0.72043
  ==== spinbox-3.70 FAILED


  My understanding is that the expected results are wrong, and that the output really should be 
  0.505376 0.720430
  exactly as it is.

  This test passes in core-8-4-branch because there is no format %.6f in this test in that branch.

  This test passes in trunk because the expected test result matches the output (i.e. 0.505376 0.720430) that I think is correct.

  I will fix the test in core-8-5-branch.


tkt_uuid: 3279221fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 12. Unix Menus
priority: 7 High
severity: Minor
foundin: None
resolution: Fixed
title: Popup menu disappears immediately
comment:
  Consider the following code:

    pack [label .l -text label]
    menu .m
    .m add command -label foo
    bind .l <3> {after 500; tk_popup .m %X %Y}

  Now, when right-clicking on the label, the popup menu appears but disappears immediately. The "after 500" is there to simulate some work that needs to be done before the menu can be drawn.

  Investigation shows that the menu disappears when the mouse button is released before the menu is drawn. This is caused by the fact that, even though the menu is not yet drawn, the <ButtonRelease> event is directed to it, and it comes before the <Enter> event which sets the Priv(window) variable in menu.tcl.

  I would propose to set Priv(window) also when the popup is drawn.

  This seems correct since, when drawing a popup menu, you at least want it to stay visible initially, even when the mouse cursor is not over it (note that this behavior is also consistent with Windows).

  See the attached patch, which solves this issue.


tkt_uuid: d01ec103c0a87efb1ea6204eb9a7c0be4c981d0d
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
severity: Important
foundin: 8.6.1
private_contact: 0f366eb3e9e2fcab52b8ebacd197db9047186a5f
resolution: None
title: After "wm withdraw .;wm state . iconic", "wm state ." always returns "withdrawn"
comment:
  <H1>Issue</H1>
  When a tk window is started by the sequence "wm wtihdraw .;wm state . iconic", the command "wm state ." will return "withdrawn" and not "iconic".

  <H1>Environment</H1>

    *  Linux CentOS 6.5 64 bit
    *  WM: Gnome
    *  Tk 8.5.7, 8.6.0, 8.6.1

  <H1>Demonstration</H1>

  Having a file "wmt.tcl" like:
  <verbatim>
  package require Tk
  proc showstate {} {
      puts [wm state .]
      after 1000 showstate
  }
  wm withdraw .
  wm state . iconic
  after 1000 showstate
  </verbatim>

  And starting by:
  <verbatim>
  wish wmt.tcl
  </verbatim>

  The printed result of "wm state ." is constantly "withdrawn".

  Even if the window state is changed by the user by deiconifying the window, it still shows "withdrawn". Only an explicit command "wm state . normal" will change the returned state.


tkt_uuid: 337acf42099d60219a7da61ba5b78ed1267d4918
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
severity: Severe
foundin: 8.6.1
private_contact: c87daa5a3b838b80cd68514d76b9263940f02cee
resolution: Duplicate
title: tk_popup disappears
comment:
  This is a bug reported on the Tk sourceforge page, but since it was from 2011 and nothing was done with it, I thought it best to report it here as well: 
  https://sourceforge.net/p/tktoolkit/patches/315/

  This affects me (and others in our company) as well.


tkt_uuid: 3606644fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 8
severity: Important
foundin: current: 8.6.0
resolution: Fixed
title: Static build misses fontconfig
comment:
  After configuring with --disable-shared, compilation fails due to missing symbols provided by fontconfig. The config.log file is attached. The resulting error is:

  gcc -O2  -pipe    -Wl,--export-dynamic  tkAppInit.o -L/home/taylor/Source/Tcl-Tk/tk8.6.0/unix -ltk8.6 -L/home/taylor/Source/Tcl-Tk/tcl8.6.0/unix -ltcl8.6  -lpthread -lXft  -lX11 -lXss -lXext -ldl -lz  -lpthread -lieee -lm  \
          -Wl,-rpath,/usr/local/lib -o wish
  /usr/bin/ld: /home/taylor/Source/Tcl-Tk/tk8.6.0/unix/libtk8.6.a(tkUnixRFont.o): undefined reference to symbol 'FcCharSetDestroy'
  /usr/bin/ld: note: 'FcCharSetDestroy' is defined in DSO /usr/lib/libfontconfig.so.1 so try adding it to the linker command line
  /usr/lib/libfontconfig.so.1: could not read symbols: Invalid operation
  collect2: error: ld returned 1 exit status
  make: *** [wish] Error 1

  Editing the Makefile to add "-lfontconfig" to the definition of XFT_LIBS causes it to work.

  In a non-static build, everything is fine. This is on Arch Linux, with fontconfig 2.10.2 installed.


tkt_uuid: 31cd33dbf0af9600f9f13b03f07b7dbf0a42d1f4
type: Bug
status: Open
subsystem: (unused)
priority: 5 Medium
severity: Important
foundin: 8.6.1
private_contact: 5312fcfb57a92ddd64553c14c04a390a9032b63f
resolution: None
title: Cocoa Tk widgets do detect invalid -bitmap values
comment:
  When a non-existant bitmap file is given to a widget with X11 or Aqua Carbon Tk 8.4 on OS X, an exception is returned.  But with Cocoa Tk 8.5 or 8.6 on OS X, the error is not detected by Tk but does result in an OS X error message.

  With X11 Tk (MacPorts 8.6.1)

  <verbatim>
  $ /macports/bin/wish8.6
  % if [catch {button .b -bitmap "blah"} result] {
      puts "Failed: $result"
  } else {
      puts "passed"
  }
  Failed: bitmap "blah" not defined)
  </verbatim>

  With Cocoa Tk 8.6.1 or 8.5.15:
  <verbatim>
  $ /usr/local/bin/wish8.6
  % if [catch {button .b -bitmap "blah"} result] {
      puts "Failed: $result"
  } else {
      puts "passed"
  }
  2014-01-31 14:58:07.134 Wish[9555:507] CFURLCopyResourcePropertyForKey failed because it was passed this URL which has no scheme: blah
  passed
  </verbatim>


tkt_uuid: f214b8ad5b9a92e9476734ade445abf8cdecea21
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 8
severity: Important
foundin: 8.6.1
resolution: Fixed
title: shutdown woes
comment:
  In a "big wish" program that embeds Tk, when built against
  (thread-enabled) Tcl/Tk 8.6.1, I get a panic on exit.  No such
  trouble with (thread-disabled) Tcl/Tk 8.5.15.  Here's the stack
  trace:

  alloc: invalid block: 0xdc1a10: 50 0

  Program received signal SIGABRT, Aborted.
  0x0000003dda430265 in raise () from /lib64/libc.so.6
  (gdb) bt
  #0  0x0000003dda430265 in raise () from /lib64/libc.so.6
  #1  0x0000003dda431d10 in abort () from /lib64/libc.so.6
  #2  0x000000000045eaf9 in CustomPanic(char*, ...) ()
  #3  0x00002aaaaafc4ff7 in Tcl_PanicVA (
      format=0x2aaaab046a00 "alloc: invalid block: %p: %x %x",
      argList=0x7fffffffd070) at /home/dgp/fossil/tcl8.6.1/generic/tclPanic.c:99
  #4  0x00002aaaaafc5167 in Tcl_Panic (
      format=0x2aaaab046a00 "alloc: invalid block: %p: %x %x")
      at /home/dgp/fossil/tcl8.6.1/generic/tclPanic.c:153
  #5  0x00002aaaaafea3c9 in Ptr2Block (ptr=0xdc1a20 "")
      at /home/dgp/fossil/tcl8.6.1/generic/tclThreadAlloc.c:780
  #6  0x00002aaaaafe99db in TclpFree (ptr=0xdc1a20 "")
      at /home/dgp/fossil/tcl8.6.1/generic/tclThreadAlloc.c:406
  #7  0x00002aaaaaf88f59 in Tcl_DeleteHashEntry (entryPtr=0xdc1a20)
      at /home/dgp/fossil/tcl8.6.1/generic/tclHash.c:467
  #8  0x00002aaaaab02711 in Tk_FreeFont (tkfont=0xe3af70)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkFont.c:1439
  #9  0x00002aaaaab027a2 in Tk_FreeFontFromObj (tkwin=0xffc4c0, objPtr=0x6fe840)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkFont.c:1480
  #10 0x00002aaaaaaf9ed8 in FreeResources (optionPtr=0x712190, objPtr=0x6fe840,
      internalPtr=0x0, tkwin=0xffc4c0)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkConfig.c:1639
  #11 0x00002aaaaaaf9d3b in Tk_FreeConfigOptions (
      recordPtr=0x1045690 "\300\304\377", optionTable=0x711f90, tkwin=0xffc4c0)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkConfig.c:1568
  #12 0x00002aaaaab43324 in DestroyMenuInstance (menuPtr=0x1045690)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkMenu.c:1235
  #13 0x00002aaaaab43464 in TkDestroyMenu (menuPtr=0x1045690)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkMenu.c:1317
  #14 0x00002aaaaab4a1fe in TkMenuEventProc (clientData=0x1045690,
      eventPtr=0x7fffffffd4a0)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkMenuDraw.c:762
  #15 0x00002aaaaaafe5a8 in Tk_HandleEvent (eventPtr=0x7fffffffd4a0)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkEvent.c:1341
  #16 0x00002aaaaab2a5a9 in Tk_DestroyWindow (tkwin=0xffc4c0)
  ---Type <return> to continue, or q <return> to quit---
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkWindow.c:1433
  #17 0x00002aaaaab2a462 in Tk_DestroyWindow (tkwin=0x70c170)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkWindow.c:1374
  #18 0x00002aaaaab2c26d in DeleteWindowsExitProc (clientData=0x716a20)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkWindow.c:2822
  #19 0x00002aaaaaaff225 in TkFinalizeThread (clientData=0x0)
      at /home/dgp/fossil/tk8.6.1/unix/../generic/tkEvent.c:2104
  #20 0x00002aaaaaf69d85 in Tcl_FinalizeThread ()
      at /home/dgp/fossil/tcl8.6.1/generic/tclEvent.c:1296
  #21 0x00002aaaaaf69b77 in Tcl_Exit (status=0)
      at /home/dgp/fossil/tcl8.6.1/generic/tclEvent.c:986
  #22 0x00002aaaaaebc049 in Tcl_ExitObjCmd (dummy=0x0, interp=0x6c0060, objc=2,
      objv=0xa113d0) at /home/dgp/fossil/tcl8.6.1/generic/tclCmdAH.c:833


tkt_uuid: 3141377fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 6
severity: Minor
foundin: 8.6.1
resolution: None
title: [winfo screenwidth/height] fail to track resolution changes
comment:
  Hi!

  After I change a screen resolution on my Debian GNU/Linux system (by xrandr, e.g. xrandr -s 800x600) [winfo screenwidth .] and [winfo screenheight .] are still reporting the old width and height values.

  I've tried 8.4.19 and 8.5.9 (didn't 8.6 or HEAD though).


tkt_uuid: 3604346fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 8
severity: Minor
foundin: current: 8.6.1
resolution: None
title: Checkin [a7eee0499a] broke Ttk docs.
comment:
  Ever since checkin [a7eee0499a], the "::" in Ttk manpage names is replaced with an underscore upon install.
  This breaks prior assumptions about manpage names and makes manpages hard to find unless one knows the secret.

  $ apropos ttk | grep treeview
  ttk::treeview (n) - hierarchical multicolumn data display widget
  $ man ttk::treeview
  man: no entry for ttk::treeview in the manual.

  Also, the manpage brought up with 'man ttk_treeview' makes no mention of 'ttk_treeview', only 'ttk::treeview'.

  Not cool. Why was this done? For huge base of Cygwin users?


tkt_uuid: df09b0665cfb22b4bdfc41e34fc466739d488d65
type: Bug
status: Open
subsystem: 55. [focus]
priority: 5 Medium
severity: Important
foundin: 8.6.1
private_contact: c1589a2fa4fc7951c4aba10439d3b95af55c3a63
resolution: None
title: entry can't get the focus after tk_getSaveFile or tk_getOpenFile is called
comment:
  ~ Code

  ttk::combobox .c
  ttk::entry .e # either ttk::entry or entry
  pack .c .e
  tk_getOpenFile # either this or tk_getSaveFile

  ~ Steps to Reproduce

  0. Save the code above as a script file
  1. Run it
  2. Deal with the "Open File" stuff. Try to click on the entry; nothing happens
  3. Click on combobox's button
  4. Then click on the entry; it gets the focus

  ~ Actual Results

  The entry can't get the focus before we click on the combobox

  ~ Expected Results

  The entry should always be responsible for user's clicks.

  ~ Additional Information

  Windows 7 x64.

  Adding [focus .e] doesn't help.


tkt_uuid: 2a6c62afd9c0d1d84ec0ef8407eb5613686a8b52
type: Bug
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Minor
foundin: 8.6.1
private_contact: 4fc15a9fd36528d4bf38dcb7fcef28bbd405fde3
resolution: None
title: ttk::treeview <<TreeviewSelect>> event bug
comment:
  Tcl/Tk version 8.6.1

  I just noticed while experimenting with the ttk::treeview that the treeview widget does not fire a <<TreeviewSelect>> event when an item that is presently selected is deleted.

  Is this an intended outcome?  The manpage says:

         <<TreeviewSelect>>
             Generated whenever the selection changes.

  It would seem that deleting an item that is selected is also a change to the selection, which should have fired a TreeviewSelect event.

  Demo code:

    #!/usr/bin/wish

    ttk::treeview .t

    pack .t

    for {set i 1} {$i < 6} {incr i} {
      .t insert {} end -text "Item # $i"
    }

    bind .t <<TreeviewSelect>> show

    proc show {} {
      puts "TreeviewSelect fired"
      puts "Current selection is '[ .t selection ]'"
    }

    button .b1 -text "Clear Selection" -command {.t selection set ""}
    button .b2 -text "Delete Selected" -command {.t delete [.t selection]}

    pack .b1 .b2 -side top

  Run the demo from a terminal so you can see the output of the puts.  Select one or more items with the mouse, notice the event fires.  While one or more items are selected, clear the selection using the "Clear Selection" button.  Notice that the event fires.

  Now select one or more items and push the "delete selected" button.  Notice the items are deleted (and the selection disappears, because the selected items no longer exist) but no event fires.


tkt_uuid: 7ffb9e554cc4c84c9866eeb0136467fe560ca4ab
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 7 High
severity: Minor
foundin: 8.6.1
resolution: None
title: Cannot expand tabs
comment:
  When you configure the <tt>-tabminwidth</tt> option of a style, you get a <i>very</i> wrong behaviour of tab layout, with the first tab expanding into the space occupied by the other tabs (which shrink), rather than the other tabs also increasing in size. This cannot possibly be right!
  <p>
  <a href="http://stackoverflow.com/q/20918625/301832">Context link</a> (including images of what is desired and what has been tried to achieve it).


tkt_uuid: 3e4c64c8b198a99d815bdcd4255d22fe55c19259
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
severity: Important
foundin: 8.5
private_contact: 09f26ab1279ab226c19c5290bba4327d2ad9ec82
resolution: Duplicate
title: crash for untrusted X connections (for ssh: ForwardX11Trusted no)
comment:
  Changing the InterpRegistry atom on the root window is not allowed for untrusted clients. One way to work around this might be to install xlib error handler which ignores these errors. This fixes the problem for me.

  In unix/tkUnixEvent.c


   *----------------------------------------------------------------------
   *
   * XlibErrorHandler --
   *
   *      This function is called for non-fatal X errors. 
   *
   * Results:
   *      None.
   *
   * Side effects:
   *      Calls default error handler for most errors.
   *
   *----------------------------------------------------------------------
   */

  static XErrorHandler OldXlibErrorHandler = NULL;
  static int XlibErrorHandler(Display *d, XErrorEvent *e)
  {
          /* Don't fail for BadAccess errors caused by XChangeProperty.
           * Changing the "InterpRegistry" atom on the root window fails 
           * for untrusted connections. */

          // X_ChangePropery = 18
          if ((BadAccess == e->error_code) && (18 == e->request_code))
                  return 0;


          if (NULL != OldXlibErrorHandler)
                  OldXlibErrorHandler(d, e);

          return 0;
  }


  And just install it before opening the display:

  TkDisplay *
  TkpOpenDisplay(
      CONST char *displayNameStr)
  {
      TkDisplay *dispPtr;

      OldXlibErrorHandler = XSetErrorHandler(XlibErrorHandler);

      Display *display = XOpenDisplay(displayNameStr);

  ....


tkt_uuid: e9a842a3c584d6e709398529863fb8f798c83e3c
type: Patch
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
severity: Minor
private_contact: 4fb5bbb7d15276f0d13ca60f056c19796b1b9a5b
resolution: None
title: TkCanvas events search for all objects , even they are not displayed
comment:
  All the events of TkCanvas are searching the entire linked list nextPtr/prevPtr, irrespective of whether they are displayed or not .

  This has become a major overhead for my application , which draws 3million+ objects and frequently user performs panning/zooming .

  Sol :
  while rendering objects on canvas we can create a new linked list which actually save's the objects which are displayed on screen and also rejecting objects which are less than 1pixel and some more optimizations .

  I've used nextPtr1 as a original clone for nextPtr  and prevPtr1 for prePtr .
  and got a huge improvements in canvas rendering .
  my modified TkCanvas http://www.youtube.com/watch?feature=player_embedded&v=HmAmXoTo5Uc 

  If Tk community is interested in this enhancement 
  I would like to share my code , so that it will be merged in future releases .

  Regards
  Nataraja G


tkt_uuid: 0aa5e852dc27ba9516858b6bd8d35f203bf8b7de
type: Bug
status: Closed
subsystem: 57. [option]
priority: 5 Medium
severity: Important
foundin: 8.5.14 and other
private_contact: 720cbbf8ba21fd6982dfd8639b4ecf45d5cf11a3
resolution: Fixed
title: Accept newline characters as value in Tk option files
comment:
  Tk does not honour newline characters in values specified in a resource file. Traditional X resources allow \n for this. Here is a modification for the function tkOption.c:AddFromString that supports this feature for the option value. This patch works for older Tk versions and for 8.6.X as well!

  static int
  AddFromString(
      Tcl_Interp *interp,		/* Interpreter to use for reporting results. */
      Tk_Window tkwin,		/* Token for window: options are entered for
  				 * this window's main window. */
      char *string,		/* String containing option specifiers. */
      int priority)		/* Priority level to use for options in this
  				 * string, such as TK_USER_DEFAULT_PRIO or
  				 * TK_INTERACTIVE_PRIO. Must be between 0 and
  				 * TK_MAX_PRIO. */
  {
      register char *src, *dst;
      char *name, *value;
      int lineNum;

      src = string;
      lineNum = 1;
      while (1) {

  	/*
  	 * Skip leading white space and empty lines and comment lines, and
  	 * check for the end of the spec.
  	 */

  	while ((*src == ' ') || (*src == '\t')) {
  	    src++;
  	}
  	if ((*src == '#') || (*src == '!')) {
  	    do {
  		src++;
  		if ((src[0] == '\\') && (src[1] == '\n')) {
  		    src += 2;
  		    lineNum++;
  		}
  	    } while ((*src != '\n') && (*src != 0));
  	}
  	if (*src == '\n') {
  	    src++;
  	    lineNum++;
  	    continue;
  	}
  	if (*src == '\0') {
  	    break;
  	}

  	/*
  	 * Parse off the option name, collapsing out backslash-newline
  	 * sequences of course.
  	 */

  	dst = name = src;
  	while (*src != ':') {
  	    if ((*src == '\0') || (*src == '\n')) {
  		char buf[32 + TCL_INTEGER_SPACE];

  		sprintf(buf, "missing colon on line %d", lineNum);
  		Tcl_SetResult(interp, buf, TCL_VOLATILE);
  		return TCL_ERROR;
  	    }
  	    if ((src[0] == '\\') && (src[1] == '\n')) {
  		src += 2;
  		lineNum++;
  	    } else {
  		*dst = *src;
  		dst++;
  		src++;
  	    }
  	}

  	/*
  	 * Eliminate trailing white space on the name, and null-terminate
  	 * it.
  	 */

  	while ((dst != name) && ((dst[-1] == ' ') || (dst[-1] == '\t'))) {
  	    dst--;
  	}
  	*dst = '\0';

  	/*
  	 * Skip white space between the name and the value.
  	 */

  	src++;
  	while ((*src == ' ') || (*src == '\t')) {
  	    src++;
  	}
  	if (*src == '\0') {
  	    char buf[32 + TCL_INTEGER_SPACE];

  	    sprintf(buf, "missing value on line %d", lineNum);
  	    Tcl_SetResult(interp, buf, TCL_VOLATILE);
  	    return TCL_ERROR;
  	}

  	/*
  	 * Parse off the value, squeezing out backslash-newline sequences
  	 * along the way.
  	 */

  	dst = value = src;
  	while (*src != '\n') {
  	    if (*src == '\0') {
  		char buf[32 + TCL_INTEGER_SPACE];

  		sprintf(buf, "missing newline on line %d", lineNum);
  		Tcl_SetResult(interp, buf, TCL_VOLATILE);
  		return TCL_ERROR;
  	    }
  	    if ((src[0] == '\\') && (src[1] == '\n')) {
  		src += 2;
  		lineNum++;
  /* START CHANGES */
  	    } else if ((src[0] == '\\') && (src[1] == 'n')) {
  		src += 2;
  		*dst++ = '\n';
  /* END CHANGES */
  	    } else {
  		*dst = *src;
  		dst++;
  		src++;
  	    }
  	}
  	*dst = 0;

  	/*
  	 * Enter the option into the database.
  	 */

  	Tk_AddOption(tkwin, name, value, priority);
  	src++;
  	lineNum++;
      }
      return TCL_OK;
  }


tkt_uuid: 3414089fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: None
title: Grab interaction problem on Windows-XP
comment:
  The attached script demonstrates a grab interaction
  problem on Windows-XP. It creates a pop-up
  transient dialog, and uses grab to make it modal,
  waiting until the user clicks OK before interaction
  with the rest of the application continues.  For
  demonstration the script is kept very simple.

  Whilst the pop-up dialog is visible, click right on
  some empty space in the Windows-XP taskbar and
  select "Show Desktop".  This minimises all open
  application windows.  It is then impossible for the
  user to restore the minimised Tk application
  window.  The application has to be killed using the
  task manager.

  This problem appears to be another unintended
  consequence of bug fix 1847002 (also see
  #2896605).  Using wish 8.5.6 works as expected,
  after the "Show Desktop" the user can click on the
  minimised application window in the task bar in
  order to restore it.


tkt_uuid: fb4f5e38b12d1e8a1e57acaf1891ad79d769fabe
type: Bug
status: Deleted
subsystem: 10. Generic Menus
priority: 5 Medium
severity: Important
foundin: 8.5.13
private_contact: 21e680c66afc6863cbbaf0aa5b26c9e8a4429339
resolution: None
title: ".menu index active" always returns "none"
comment:
  Trying to use ".menu index active" as described in the documentation. I created a menu and put some entries in it, then bound a procedure to <<MenuSelect>> for it. When I traversed the menu, this procedure was called several times, but if I try to get the index of the active menu element with ".menu index active" inside the procedure the result is always "none". It is also "none" if called from the procedure associated with a command entry, or from the postcommand procedure of a menu in a cascade entry.


tkt_uuid: 2046267fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 3 Low
severity: Minor
foundin: None
resolution: None
title: Ttk::button -takefocus option influences <Button-1>
comment:
  A ttk::button which has -takefocus 1, will get the focus on a <ButtonPress-1> event. This is inconsistent with normal -takefocus behaviour, which only governs keyboard traversal with <Tab>.

  Even if this is intentional for ttk, it is inconsistent with the ttk documentation which says:

  -takefocus: Determines whether the window accepts the focus during keyboard traversal. Either 0, 1, a command prefix (to which the widget path is appended, and which should return 0 or 1), or the empty string. See options(n) in the Tk reference manual for the full description.

  Note that fixing this would also fix [1904322] and [1936220].

  See also [http://wiki.tcl.tk/20050].


tkt_uuid: 1632447fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 43. Photo Image|PPM
priority: 6
severity: Minor
foundin: obsolete: 8.4.12
private_contact: c39c633bc9fd2fa3639a14e104fd770241e1fea2
resolution: Fixed
title: bad PPM maxval
comment:
  If maxval in PPM file header is greater than 255 then the
  following will happen:

  $ wish
  % image create photo f -file x.ppm
  PPM image file "x.ppm" has bad maximum intensity value 65535

  and no image will be created.

  Create x.ppm:
  $ xwd -root | xwdtopnm >x.ppm
  The maxval depends on the X servers display depth value.


tkt_uuid: 1520742fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 37. [tk_get*File]
priority: 8
severity: Cosmetic
foundin: TIP Implementation
private_contact: 03b828ee59ccfe48c5bce0078ae5858736202947
resolution: None
title: Windows-style Open and Save file dialog on Unix
comment:
  Email:matthew.middleton@ansys.com
  An attachment with the necessary source files is 
  attached.

  The tk_getOpenFile and tk_getSaveFile have been 
  greatly improved to function much like a windows 
  dialog taken from Windows 2000, when the default 
  dialogs are overridden.
  This is most useful on Unix systems where the 
  application is wanted to have a Windows-like 
  appearance, but it will also function on Windows.
  I have not been able to test on Macintosh.
  This also affects tk_chooseDirectory when the default 
  dialogs are overridden since it runs off of 
  tkfbox.tcl.

  The dialogs will work without the BWidget package, 
  but it will have more functionality and look more 
  like a windows dialog if BWidgets are included.
  The only thing it really needs from BWidgets is the 
  ComboBox widget.  If this were included in regular 
  Tk, then BWidgets would not be needed.
  It also uses the balloon messages of the "Button" 
  widget from BWidgets.

  This new file dialog widget requires two of the new 
  widgets included -- ResizeButs and tk_fileProperties.
  I added these lines to the file "tclIndex" to get it 
  to find these commands:
  set auto_index(ResizeButs) [list source [file join 
  $dir ResizeButs.tcl]]
  set auto_index(tk_fileProperties) [list source [file 
  join $dir tkfprops.tcl]]

  The two tcl files that define these widgets are 
  included (ResizeButs.tcl and tkfprops.tcl), along 
  with documentation on each one.

  The file choosedir.tcl is also included.  It is 
  needed to work with the modified tkfbox.tcl.


  Added functionality of the file dialog:
        1. Back directory button
        2. Create directory button
        3. Details button
        4. Delete button
        5. You can type the directory path at the top 
  (requires BWidgets).  Selecting "desktop" expands 
  what's available on the desktop if used on Windows.
        Right mouse clicking on a file gives these 
  options:
              1.  Cut
              2.  Copy
              3.  Delete
              4.  Rename
              5.  Properties (uses tk_fileProperties 
  widget)
        Right mouse clicking in open white space gives 
  these options:
              1.  View
                    1. List
                    2. Details
              2.  Arrange Icons
                    1. By Name
                    2. By Size
                    3. By Type
                    4. By Date
              3.  Refresh
              4.  Paste (ungreys if Cut or Copy were 
  previously selected on files)
              5.  New Folder
              6.  Properties (uses tk_fileProperties 
  widget)
        6. Recent selected files can be shown by 
  pressing the down arrow in the entry field of the 
  selected file name (requires BWidgets).  Recent file 
  names are saved to a file named 

  .tk_recent_selections in the users home directory.
        7. Box selecting of files can be done with 
  the "multiple 1" option.  Left mouse click and hold 
  and drag a box over files.
        8. The busy was improved to actually block 
  mouse clicks instead of just showing an hourglass 
  widget.
        9. Popup button descriptions. (requires 
  BWidgets)
        10. Icons shade as well as text when selected.

  Details view
        The Details button grids 4 columns (name, file 
  type, size, and modified date). (uses ResizeButs 
  widget)
        Moving the mouse over the border between two 
  buttons of the top column headings and left mouse 
  clicking while dragging will allow the user to change 
  the size of the columns.
        Pressing one of the heading buttons changes the 
  order of the data between increasing and decreasing 
  and displays a triangle in the button to indicate the 
  order.

  Additional Arguments to the tk_getOpenFile and 
  tk_getSaveFile commands
        The dir_leaf arguments allow a folder to be 
  selected as a file to select it as a project.  
  Providing a -dir_leaf_check procedure defines the 
  file dialog as a special type that only 

  lists folders, but the folder that passes the -
  dir_leaf_check procedure can be selected as a file.
        1. -dir_leaf_check -- This is the name of a 
  procedure which checks if the directory qualifies as 
  the kind that can be selected as a project file. It 
  returns a non-zero number if it 

  qualifies, otherwise it returns zero. The directory 
  name to check will be appended as an argument to the 
  procedure.
        2. -dir_leaf_image -- an image to use for the 
  folder types that will be treated as files.  It 
  should be an image created with "image create photo"
        3. -dir_leaf_label -- text that appears at the 
  left of the entry for the selected file when the 
  dialog is defined as a project folder selection type 
  (when the -dir_leaf_check 

  procedure is defined).


tkt_uuid: c0cc9fd15347a1ac3524d171e1deb6535c90b02a
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
severity: Cosmetic
foundin: 8.6.1
private_contact: 62dff5c8d9ba8f3898c9109ff74421ecb893d66c
resolution: Fixed
title: PNG parser does not support uppercase format string (using -format)
comment:
  The format string used by the -format option of "image create photo" can be uppercase or lowercase when using GIF and PPM formats. The PNG parser accepts only lowercase.

  BTW: The Img extension allows upper- and lowercase, too.


tkt_uuid: 2780147fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 76. Widget Tour
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: Demo - dir browser tree fails
comment:
  The directory browser tree fails on my windows system with the Tcl error:

  -------- snip ----------
  could not read "C:/~AVINSTL": no such file or directory
  could not read "C:/~AVINSTL": no such file or directory
      while executing
  "file type $f"
      (procedure "populateTree" line 8)
      invoked from within
  "populateTree $tree [$tree insert {} end -text $dir  -values [list $dir directory]]"
      (procedure "populateRoots" line 3)
      invoked from within
  "populateRoots $w.tree"
      (file "D:/Tcl/demos/Tk8.6/tree.tcl" line 81)
      invoked from within
  "source D:/Tcl/demos/Tk8.6/tree.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list source [file join $tk_demoDirectory $demo.tcl]]"
      (procedure "invoke" line 12)
      invoked from within
  "invoke [.t index {@95,377}]"
      (command bound to event)

  ------------- snap -----------

  This bug can be fixed by normalizing the file paths in the proc populateTree. See attachment.


tkt_uuid: 2930718fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 3 Low
severity: Minor
foundin: obsolete: 8.6b1.1
resolution: None
title: Undocumented API: Tk_Outline
comment:
  Entries 221-226 in tk.decls (the Tk_Outline function API) have no documentation anywhere in Tk. As part of the public API, this should be fixed.

      void Tk_CreateOutline(Tk_Outline *outline)
      void Tk_DeleteOutline(Display *display, Tk_Outline *outline)
      int Tk_ConfigOutlineGC(XGCValues *gcValues, Tk_Canvas canvas,
              Tk_Item *item, Tk_Outline *outline)
      int Tk_ChangeOutlineGC(Tk_Canvas canvas, Tk_Item *item,
              Tk_Outline *outline)
      int Tk_ResetOutlineGC(Tk_Canvas canvas, Tk_Item *item,
              Tk_Outline *outline)
      int Tk_CanvasPsOutline(Tk_Canvas canvas, Tk_Item *item,
              Tk_Outline *outline)


tkt_uuid: 579885ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
severity: Minor
foundin: None
resolution: Out of Date
title: Add _MOTIF_WM_HINTS support
comment:
  Tk should support setting the _MOTIF_WM_HINTS property
  as part of [wm attributes] on Unix/X; IIRC many window
  managers (aside from mwm and dtwm/CDE) support this
  nowadays as a way of getting client-specified styles
  going, and the structure is easy enough to figure out
  given a set of Motif header files.

  (submitted so the idea doesn't get lost.)


tkt_uuid: 61e81fe8223528ded8276b51535291a2b6f32fba
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: 8.5.9
private_contact: 44f0d4e92e7e2037cdf5be7eda1b4afd9c9efaaf
resolution: Fixed
title: Incorrect mouse events under OSX (Aqua)
comment:
  Under x11 right mouse button generate <Button-3> and middle button generate <Button-2> events. But under OSX events are reversed: <Button-2>, <ButtonPress-2>, <ButtonRelease-2> generates on right, and <*-3> on middle button.
  Using Tcl/Tk bundled with OS X 10.8


tkt_uuid: 3607215fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Minor
foundin: current: 8.6.0
resolution: Out of Date
title: ./configure --enable-aqua=carbon
comment:
  `./configure --help` describes an option "--enable-aqua=carbon".

  Is this option still supported?  ./configure fails when looking for files in a non-existent directory named "carbon".


tkt_uuid: 1630251fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5a6
resolution: Fixed
title: -endline is never displayed
comment:
  According to the docs the -endline is the last line to be displayed, but it isn't. Setting -startline equal to -endline for example results in an empty widget.


  pack [text .t] -side top -pady {0 6}
  .t insert end "1\n2\n3\n"
  pack [.t peer create .peer -startline 2 -endline 2] -side top


  This does provide a way of having zero lines displayed, which may be a good thing rather than enforcing a minimum of 1 line, in which case only the docs need updating.


tkt_uuid: 53f7a1b5532d0e037106b9245274359d1b233c58
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Critical
foundin: 8.5.15
private_contact: 5312fcfb57a92ddd64553c14c04a390a9032b63f
resolution: Fixed
title: Aqua Cocoa Tk multi-window apps redraw problems on OS X 10.9 Mavericks
comment:
  There appears to be refresh problems when using current Aqua (Cocoa) Tk 8.5.x or 8.6.x builds on the newly released OS X 10.9.  I first noticed the problem using Python IDLE (linked with a Tk 8.5.x) but the problem can be easily reproduced using a current Wish "Basic editable text" widget demo. 

  The following two screenshots demonstrate the problem.

  [https://www.dropbox.com/s/b517eq09x816d4h/tk85_15_mavericks_1.jpg]

  [https://www.dropbox.com/s/6xe4hptm5e53tk5/tk85_15_mavericks_2.jpg]

  Clicking back and forth between the two Tk windows using the mouse, neither the window gaining focus nor the window losing focus gets updated properly.  In the first, note the incomplete black border around the text widget: it was created by moving the mouse randomly over the border without hovering over the scroll bar on the right or without using the keyboard.  In the second, note the incompletely highlight text and the misplaced text in the bottom border of the foreground window with focus and how the border is still displayed around the text field in the background window that no longer has focus.  If the mouse is hovered over the scroll bar on the right or if the keyboard is used to enter a character, the windows are then updated properly.

  Caveats: I have been unable to reproduce the problem with the Tcl/Tk 8.5.9 shipped by Apple in OS X 10.9.  I can reproduce the problem with recent various versions of ActiveTcl 8.5.x and 8.6.x for OS X.  And I can reproduce the problem with versions of 8.5.15 and 8.6.1 built from the release tarballs.  I also discovered by accident that the problem appears to only happen when the Cocoa Tk is running in 64-bit mode (the default on 64-bit capable Macs), but not in 32-bit mode.  This can be demonstrated using the ActiveTcl wish8.5 by forcing the execution architecture:

  <verbatim>
  cd /Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS
  arch -x86_64 ./Wish  # text widget demo exhibits the problem
  arch -i386 ./Wish  # no problem
  </verbatim>

  This leads me to speculate that there might be some legacy 32-bit Carbon API being used that is skipped in 64-bit mode.  Or perhaps there is simply some arch-related code bug.  It might also be useful to examine what source and patches Apple uses for the system Tk 8.5.  The 10.9 versions should eventually get published here: [http://opensource.apple.com]

  Also, note that while the problem is reproducible on 10.9 with most versions of the Python IDLE application that link with a non-Apple Cocoa Tk 8.5, it is not reproducible by clicking on the IDLE.app icon of the current python.org 2.7 binary installer, e.g. the equivalent of:

  <verbatim>open /Applications/Python\ 2.7/IDLE.app</verbatim>

  For arcane reasons, that causes Tk to always be launched in 32-bit mode (that's how I discovered the dependency).  The problem can be demonstrated by launching the same Python and IDLE via:

  <verbatim>/Library/Frameworks/Python.framework/Versions/2.7/bin/idle2.7</verbatim>

  [http://www.python.org/download/releases/2.7.5/]

  [http://www.activestate.com/activetcl/downloads]

  Current versions of Python 3.x IDLE.app launch in 64-bit mode and do show the problem with ActiveTcl 8.5 installed in /Library/Frameworks.


tkt_uuid: 1630262fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: segfault when deleting a line which is a -startline
comment:
  text .t
  .t insert end "1\n2\n3\n"
  .t peer create .peer
  .t configure -startline 3
  .peer delete 2.0 end


  I tracked this down to tkTextBTree.c:AdjustStartEndRefs(),
  change 2 lines from this...

  treePtr->startEndRef[count] = treePtr->sharedTextPtr->peers;

  to this ...

  treePtr->startEndRef[count] = textPtr;


tkt_uuid: 3602582fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
severity: Minor
foundin: current: 8.6.0
resolution: Invalid
title: text widget wrapping oddly
comment:
  I'm not totally sure if this is a bug or intended behaviour:

  pack [text .t -wrap word -width 80]
  .t insert end [string repeat "la " 28]
  puts [.t count 1.0 "1.0 display lineend";# 77

  The text widget wraps so that the second line contains "la la", despite the first line being only 77 characters long - long enough that the penultimate "la" would fit. This may well be deliberate - if the extra "la" was shown on the first line, it would mean that either the second line would start with a space (which never looks good), or that there would be no visual indication that the last word wasn't "lala" and it was wrapped per-char (which could be confusing). But a couple of people using an app have reported it as weird behaviour, so I thought I'd run it up the flagpole to you guys to double-check.


tkt_uuid: 2321450fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Text widget block cursor problem
comment:
  When the -blockcursor option is set to 1, the cursor appears as a blinking bar which expands to the right edge of the widget.

  The problem is there for Tk 8.5.4 on X11 (tested by me) and HEAD (confirmed by dkf on the tcler's chat).


tkt_uuid: 1630254fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5a6
resolution: Fixed
title: problem configuring -startline in a peer
comment:
  Configure a peer to have -startline == -endline as below, it will show no lines. Then setting -startline to the empty string doesn't seem to have any effect on the lines displayed.


  pack [text .t] -side top -pady {0 6}
  .t insert end "1\n2\n3\n"
  pack [.t peer create .peer -startline 2 -endline 2] -side top

  Now try clearing -startline; the display should show us line 1:

  .peer configure -startline {}


tkt_uuid: 1754043fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: no limit to -blockcursor width
comment:
  When -blockcursor is true, the block cursor takes up the entire width of the character to the right of the cursor.  When the cursor is positioned at a whitespace character such as tab or newline, or at the end of a display line, this can be distracting, e.g. at newline the cursor expands to the right-hand boundary of the widget.

  I suggest that, when the block cursor covers whitespace, its width should not exceed a preset value, e.g. the em-width of the font.


tkt_uuid: 3588824fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
severity: Minor
foundin: current: 8.6.0
resolution: Fixed
title: Text widget: bug in image index handling
comment:
  The [$text index $image] subcommand fails with images which contains "+", "-"  or spaces in their names.

  Sample script:

  package require Tk
  text .t
  .t image create 1.0 -image [image create photo ::foo]
  .t image create 1.1 -image [image create photo ::foo-1]
  puts [.t image names]
  foreach img [.t image names] {
      puts [.t index $img]
  }

  Output:

  ::foo ::foo-1
  1.0
  bad text index "::foo-1"

  The source code in generic/tkTextIndex.c checkes first for a mark name
  alone before trying to parse the provided input as "base+modifier", thus
  allowing mark names with spaces or "+- " chars.

  The attached patch solves the issue simply performing the same check
  for an image name after the one for marks.


tkt_uuid: 3603436fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 8
severity: Minor
foundin: current: 8.6.0
resolution: Fixed
title: png save has wrong component indexes in Tk8.6
comment:
  I create a new PNG photo image from Tk and then fill it from C with Tk_PutPhotoBlock. Writing it to file then results in wrong color component indexes. It seems to put the RGBA indexes (blockPtr->offset) in function EncodePNG as 1 2 3 3 when after some tracing into the code should really be 1 2 3 0. (not sure why it is not (0 1 2 3) though


tkt_uuid: 1615425fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: [tag add] segfaults if index out of range of peer
comment:
  pack [text .t] -side top
  .t insert end "1\n2\n3\n4\n5\n"
  .t tag configure tagA -font {Courier 10 bold}
  pack [.t peer create .t2 -startline 3] -side top
  .t tag add tagA 1.0 1.end
  update


  Adding a tag to a range of characters before -startline of a peer causes a segfault.
  I think this is because [tag add] calls TkTextRedrawTag() with non-NULL indices.


tkt_uuid: 3601601fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
severity: Minor
foundin: current: 8.6.0
resolution: Invalid
title: tk_textCopy copies elided text
comment:
  The tk_textCopy (and tk_textCut) commands copy elided text from a text widget. While there are certainly some cases where this is desirable, I would imagine they are the minority. It's very minor to change the behaviour, just requires adding the -displaychars option to [$textWidget get].


tkt_uuid: 3529885fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 6
severity: Minor
foundin: obsolete: 8.6b2
resolution: Fixed
title: negative resolution confuses scale widget
comment:
  A negative resolution is used to indicate that the value should not be rounded, but then clicking in the trough causes the slider to move away from the mouse pointer instead of towards it.


tkt_uuid: 415415ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.3.3
resolution: None
title: Long callback: One click -> Two steps
comment:
  Evaluate the demo script in wish.

  Click once in the trough of the scale.  Do
  not hold the button down.

  Watch the scale advance two steps.

  This problem can be worked around by configuring
  the -repeatdelay of the scale, but that's not
  obvious from the documentation pages.

  Documentation improvements are probably sufficient
  to close this bug.


tkt_uuid: 0953f30d0be7d9141010905de29044d9d6c9119e
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
severity: Severe
foundin: 8.6.3rc
private_contact: e9a1155c7c4ca1060406a8ab1a1d79963f5424e7
resolution: None
title: Buttons are not displaying on OSX because of hard-coded values
comment:
  Buttons are checking hard coded pixel offset boundaries which prevent them from displaying in valid situations.

  Here is a patch to fix it:

  Index: macosx/tkMacOSXButton.c
  ==================================================================
  --- macosx/tkMacOSXButton.c
  +++ macosx/tkMacOSXButton.c
  @@ -51,29 +51,29 @@
   	    MacDrawable* macWin = (MacDrawable *)butPtr;
   	    NSRect Tkframe = TkMacOSXGetButtonFrame(butPtr);
   	    Tk_Window tkwin = butPtr->tkwin;
   	    /* Do not draw if the widget is misplaced or unmapped. */
   	    if ( NSIsEmptyRect(Tkframe) || 
  -		 ! macWin->winPtr->flags & TK_MAPPED ||
  +		 ! (macWin->winPtr->flags & TK_MAPPED) ||
   		 ! NSEqualRects(Tkframe, [self frame]) 
   		 ) {
   		return;
   	    }
  -	     /* Do not draw if the widget is completely outside of its parent, or within 20 pixels of the lower border; this prevents buttons from being drawn on peer widgets as scrolling occurs. */
  +	     /* Do not draw if the widget is completely outside of its parent; this prevents buttons from being drawn on peer widgets as scrolling occurs. */
   	    if (tkwin) {
   		int parent_height = Tk_Height(Tk_Parent(tkwin));
   		int widget_height = Tk_Height(tkwin);
   		int y = Tk_Y(tkwin);
  -		if ( y > parent_height - 20 || y + widget_height < 0 ) {
  +		if ( y > parent_height || y + widget_height < 0 ) {
   		    return;
   		}
   
  -	    /* Do not draw if the widget is completely outside of its parent, or within 50 pixels of the right border; this prevents buttons from being drawn on peer widgets as scrolling occurs. */
  +	    /* Do not draw if the widget is completely outside of its parent; this prevents buttons from being drawn on peer widgets as scrolling occurs. */
   		int parent_width = Tk_Width(Tk_Parent(tkwin));
   		int widget_width = Tk_Width(tkwin);
   		int x = Tk_X(tkwin);
  -		if (x > parent_width - 50 || x < 0) { 
  +		if (x > parent_width || x < 0) { 
   		    return;
   		}
   	    }
   	[super drawRect:dirtyRect];
       }


tkt_uuid: 0434d28bdbb47f56bc4a27995d6b25b4f80d4d20
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
severity: Severe
foundin: 8.6.3rc
private_contact: e9a1155c7c4ca1060406a8ab1a1d79963f5424e7
resolution: None
title: Too many nested evaluations recursion for OSX/TK events
comment:
  On OSX, the expose events/OSX drawing events enter an infinite recursion.

  Here is a patch which prevents this (infinite) recursion:

  Index: macosx/tkMacOSXPrivate.h
  ==================================================================
  --- macosx/tkMacOSXPrivate.h
  +++ macosx/tkMacOSXPrivate.h
  @@ -324,10 +324,11 @@
      #if 0
       id _savedSubviews;
       BOOL _subviewsSetAside;
       #endif
       NSString *privateWorkingText;
  +    BOOL _in_event;
   }
   @end
   
   @interface TKContentView(TKKeyEvent)
   - (void) deleteWorkingText;

  Index: macosx/tkMacOSXWindowEvent.c
  ==================================================================
  --- macosx/tkMacOSXWindowEvent.c
  +++ macosx/tkMacOSXWindowEvent.c
  @@ -829,11 +832,15 @@
   
   	r.origin.y = height - (r.origin.y + r.size.height);
   	HIShapeUnionWithRect(drawShape, &r);
       }
       if (CFRunLoopGetMain() == CFRunLoopGetCurrent()) {
  -	[self generateExposeEvents:drawShape];
  +	if (!_in_event) {
  +	    _in_event = true;
  +	    [self generateExposeEvents:drawShape];
  +	    _in_event = false;
  +	}
       } else {
   	[self performSelectorOnMainThread:@selector(generateExposeEvents:)
   		withObject:(id)drawShape waitUntilDone:NO
   		modes:[NSArray arrayWithObjects:NSRunLoopCommonModes,
   			NSEventTrackingRunLoopMode, NSModalPanelRunLoopMode,


tkt_uuid: 22c9fe06235f1512e2f611c1516a0a38c265b814
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
severity: Critical
foundin: 8.6.3rc
private_contact: e9a1155c7c4ca1060406a8ab1a1d79963f5424e7
resolution: None
title: Balloon help implementations bind Leave functionality broken on OSX
comment:
  Implementations of tooltips/balloon help usually use help style but assume that bind Leave functionality is enabled.  This patch enables that functionality so that they work properly:

  Index: macosx/tkMacOSXWindowEvent.c
  ==================================================================
  --- macosx/tkMacOSXWindowEvent.c
  +++ macosx/tkMacOSXWindowEvent.c
  @@ -465,19 +465,22 @@
       TkWindow *winPtr,		/* Root X window for event. */
       int activeFlag)
   {
       XEvent event;
   
  +#ifdef FILTER_HELP_FOCUS
       /*
        * Don't send focus events to windows of class help or to windows with the
        * kWindowNoActivatesAttribute.
        */
  +    /* Note that this breaks most balloon help implementations */
   
       if (winPtr->wmInfoPtr && (winPtr->wmInfoPtr->macClass == kHelpWindowClass ||
   	    winPtr->wmInfoPtr->attributes & kWindowNoActivatesAttribute)) {
   	return false;
       }
  +#endif
   
       /*
        * Generate FocusIn and FocusOut events. This event is only sent to the
        * toplevel window.
        */

  Index: macosx/tkMacOSXWm.c
  ==================================================================
  --- macosx/tkMacOSXWm.c
  +++ macosx/tkMacOSXWm.c
  @@ -343,14 +343,18 @@
   
   @implementation TKWindow(TKWm)
   - (BOOL) canBecomeKeyWindow
   {
       TkWindow *winPtr = TkMacOSXGetTkWindow(self);
  -
  +#ifdef FILTER_HELP_FOCUS
  +    /* Note that this breaks most balloon help implementations */
       return (winPtr && winPtr->wmInfoPtr && (winPtr->wmInfoPtr->macClass ==
   	    kHelpWindowClass || winPtr->wmInfoPtr->attributes &
   	    kWindowNoActivatesAttribute)) ? NO : YES;
  +#else
  +    return YES;
  +#endif
   }
   @end
   
   #pragma mark -


tkt_uuid: c60758248980500471516784a10a530517ce6660
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
severity: Severe
foundin: 8.5.9, 8.6.1, 8.6.2
private_contact: 75d5f3d55226dc81ffedf23fbdf280e0b41fb709
resolution: None
title: Tk crashes X server drawing multi-segment dashed lines
comment:
   Tk crashes when drawing multi-segment dashed lines that extend
   outside the visible area of the canvas. This crash is observed
   running Linux (opensuse 13.1) on intel i5-2500k with on-chip
   graphics. The crash occurs with both KDE and icewm. The actual
   crash is termination of the X server with a segfault.
   
   The crash does not occur if the default intel video driver is
   replaced by the (slow) fbdev driver. This suggests a bug in the
   driver, but
   a) No other program has ever caused a similar crash on this computer
   b) The crash can be prevented by seemingly trivial changes in the Tk code.
   
   The crash can be generated by the script below. It does not occur
   every time a line is drawn, hence the loop. After a crash, the file
   crash_count indicates how many times the loop ran successfully.
   Typically less than 100 loop iterations are required for a crash.
   
   If _any_ of the following modifications are made to this script, no
   crashes occur:
   a) Change canvas dimensions to 600 x 600
   b) Change -dash value to {}
   c) Change -width value to 2
   d) Lines with < 20 segments don't crash (not exhaustively tested)
   
   ------------------------------- Cut here -----------------------------
   #! /usr/bin/env tclsh
   
   # WARNING THIS WILL DESTROY ANY FILE NAMED crash_count
   
   package require Tk
   
   set pts {
      229 229 223 234 217 240 211 246 205 252 200 258 195 264 189 270 184
      276 179 282 174 288 169 294 164 300 160 306 155 312 151 318 146 324
      142 330 138 336 134 341 130 347 126 353 123 358 119 364 116 370 113
      375 109 381 106 386 104 391 101 397 98 402 96 407 93 412 91 417 89
      422 87 427 86 432 84 436 82 441 81 445 80 450 79 454 78 458 77 462
      77 466 76 470 76 474 76 478 76 481 76 485 77 488 77 491 78 494 79
      497 80 500 81 502 82 505 84 507 86 509 88 512
   }
   
   proc main {} {
      global pts
      puts "tcl version: [info patch]"
      flush stdout
      
      canvas .c -width 400 -height 400 -bg white
      pack .c -fill both -expand 1
      
      file delete crash_count
      
      set N 5000
      for {set i 0} {$i < $N} {incr i} {
         
        .c create line $pts -fill blue -dash {3 3} -width 1
   
         update idletasks
         set f [open crash_count w]
         puts $f $i
         close $f
         .c delete all
      }
      puts "done $N cycles"
   }
   
   main


tkt_uuid: 1347712fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 7 High
severity: Minor
foundin: obsolete: 8.5a4
resolution: Invalid
title: tearoff menu title ignored
comment:
  From the menu man page, I can read about the -title 
  option:
  "The string will be used to title the window created when 
  this menu is torn off."

  So running the following snippet:

  menu .m -tearoff 0 -title "Nice menu"
  .m add command -label "hello world"
  .m add command -label [.m cget -title]
  .m clone .m.cl tearoff
  .m.cl post 150 200

  I would expect that the torn-off menu title be "Nice menu".

  I observe that it is "cl", which I believe is a bug.


tkt_uuid: b2462158c3f85c443f9d79f4ae7b15ac44789798
type: Bug
status: Open
subsystem: 16. [scrollbar]
priority: 5 Medium
severity: Severe
foundin: 8.6.3rc
private_contact: e9a1155c7c4ca1060406a8ab1a1d79963f5424e7
resolution: None
title: Scrollbars are not appearing on OSX
comment:
  Scrollbars are not displaying for nested widgets.

  Here is a patch which fixes it:

  Index: macosx/tkMacOSXScrlbr.c
  ==================================================================
  --- macosx/tkMacOSXScrlbr.c
  +++ macosx/tkMacOSXScrlbr.c
  @@ -48,14 +48,18 @@
   	    MacDrawable* macWin = (MacDrawable *)scrollPtr;
   	    Tk_Window tkwin = scrollPtr->tkwin;
   	    NSRect Tkframe = TkMacOSXGetScrollFrame(scrollPtr);
   	    /* Do not draw if the widget is misplaced or unmapped. */
   	    if ( NSIsEmptyRect(Tkframe) || 
  -		 ! macWin->winPtr->flags & TK_MAPPED ||
  -		 ! NSEqualRects(Tkframe, [self frame]) 
  +		 ! (macWin->winPtr->flags & TK_MAPPED)
   		 ) {
   		return;
  +	    }
  +	    for (Tk_Window parent_win = tkwin; parent_win != NULL;parent_win = Tk_Parent(parent_win)) {
  +		if (!Tk_IsMapped(parent_win)) {
  +		    return;
  +		}
   	    }
   
   	    /*
   	     * Do not draw if the widget is completely outside of its parent.
   	     */


tkt_uuid: 46827143b4df57e496893fd68c862174a34bde0f
type: Patch
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Important
foundin: 8.6.3rc
private_contact: e9a1155c7c4ca1060406a8ab1a1d79963f5424e7
resolution: None
title: Allow picking all file types on OSX by having panel accessory view option
comment:
  On OSX, the public.data UTI is not mapped to a a particular filetype but is needed to let users select 'All Files' like they can on other platforms.

  There is a current feature request for something similar at: http://sourceforge.net/p/tktoolkit/feature-requests/248/

  The following patch allows adding an -allbutton option to the arguments for tk_getOpenFile.  The value given to -allbutton should be the text to display for a checkbox to allow selecting any (public.data) file.  A second option, -allbuttontip, allows specifying the tooltip text for the checkbox.

  Index: macosx/tkMacOSXDialog.c
  ==================================================================
  --- macosx/tkMacOSXDialog.c
  +++ macosx/tkMacOSXDialog.c
  @@ -22,16 +22,16 @@
   };
   
   static const char *const openOptionStrings[] = {
       "-defaultextension", "-filetypes", "-initialdir", "-initialfile",
       "-message", "-multiple", "-parent", "-title", "-typevariable",
  -    "-command", NULL
  +    "-command", "-allbutton", "-allbuttontip", NULL
   };
   enum openOptions {
       OPEN_DEFAULT, OPEN_FILETYPES, OPEN_INITDIR, OPEN_INITFILE,
       OPEN_MESSAGE, OPEN_MULTIPLE, OPEN_PARENT, OPEN_TITLE,
  -    OPEN_TYPEVARIABLE, OPEN_COMMAND,
  +    OPEN_TYPEVARIABLE, OPEN_COMMAND, OPEN_ALLBUTTON, OPEN_ALLBUTTONTIP
   };
   static const char *const saveOptionStrings[] = {
       "-defaultextension", "-filetypes", "-initialdir", "-initialfile",
       "-message", "-parent", "-title", "-typevariable", "-command",
       "-confirmoverwrite", NULL
  @@ -218,10 +218,39 @@
   	Tcl_DecrRefCount(callbackInfo->cmdObj);
   	ckfree(callbackInfo);
       }
   }
   @end
  +
  +@interface TKOpenDialog : NSControl 
  +@property(assign) NSOpenPanel *openPanel;
  +@property(assign) NSMutableArray *openFileTypes;
  +- (void)openUnrecognizedFiles:(id)sender;
  +@end
  +
  +@implementation TKOpenDialog
  +- (id)init {
  +    self = [super init];
  +    if (self) {
  +	_openPanel = nil;
  +	_openFileTypes = nil;
  +    }
  +    return self;
  +}
  +
  +- (void)openUnrecognizedFiles:(id)sender
  +{
  +    if ([sender state]) {
  +	self.openPanel.allowedFileTypes = [NSArray arrayWithObjects:@"public.data", nil];
  +    } else {
  +	self.openPanel.allowedFileTypes = self.openFileTypes;
  +    }
  +    [self.openPanel setDirectoryURL:self.openPanel.directoryURL];
  +    [self.openPanel validateVisibleColumns];
  +}
  +
  +@end
   
   #pragma mark -
   

   /*
    *----------------------------------------------------------------------
  @@ -364,15 +393,18 @@
       Tcl_Obj *cmdObj = NULL, *typeVariablePtr = NULL;
       FilePanelCallbackInfo callbackInfoStruct;
       FilePanelCallbackInfo *callbackInfo = &callbackInfoStruct;
       NSString *directory = nil, *filename = nil;
       NSString *message, *title, *type;
  +    NSString *allbutton, *allbuttontip;
       NSWindow *parent;
       NSMutableArray *fileTypes = nil;
       NSOpenPanel *panel = [NSOpenPanel openPanel];
       NSInteger returnCode = NSAlertErrorReturn;
   
  +    allbutton = nil;
  +    allbuttontip = nil;
       TkInitFileFilters(&fl);
       for (i = 1; i < objc; i += 2) {
   	if (Tcl_GetIndexFromObjStruct(interp, objv[i], openOptionStrings,
   		sizeof(char *), "option", TCL_EXACT, &index) != TCL_OK) {
   	    goto end;
  @@ -435,10 +467,18 @@
   	    typeVariablePtr = objv[i + 1];
   	    break;
   	case OPEN_COMMAND:
   	    cmdObj = objv[i+1];
   	    break;
  +	case OPEN_ALLBUTTON:
  +	    allbutton = [[NSString alloc] initWithUTF8String:
  +		    Tcl_GetString(objv[i + 1])];
  +	    break;
  +	case OPEN_ALLBUTTONTIP:
  +	    allbuttontip = [[NSString alloc] initWithUTF8String:
  +		    Tcl_GetString(objv[i + 1])];
  +	    break;
   	}
       }
       if (fl.filters) {
   	fileTypes = [NSMutableArray array];
   	for (FileFilter *filterPtr = fl.filters; filterPtr;
  @@ -470,10 +510,28 @@
   		}
   	    }
   	}
       }
       [panel setAllowsMultipleSelection:multiple];
  +
  +    if (allbutton) {
  +	TKOpenDialog *tkDialog = [TKOpenDialog alloc];
  +	tkDialog.openPanel = panel;
  +	tkDialog.openFileTypes = fileTypes;
  +	
  +	NSButton *openPanelAccessoryView = [[[NSButton alloc] initWithFrame:NSMakeRect(0.0, 0.0, 224.0, 22.0)] autorelease];
  +	if (allbuttontip) {
  +	    [openPanelAccessoryView setToolTip:allbuttontip];
  +	}
  +	[openPanelAccessoryView setButtonType:NSSwitchButton];
  +	[openPanelAccessoryView setBezelStyle:0];
  +	[openPanelAccessoryView setTitle:allbutton];
  +	[openPanelAccessoryView setAction:@selector(openUnrecognizedFiles:)];
  +	[openPanelAccessoryView setTarget:tkDialog];
  +	[panel setAccessoryView:openPanelAccessoryView];
  +    }
  +
       if (cmdObj) {
   	callbackInfo = ckalloc(sizeof(FilePanelCallbackInfo));
   	if (Tcl_IsShared(cmdObj)) {
   	    cmdObj = Tcl_DuplicateObj(cmdObj);
   	}


