# ticket

tkt_uuid: 756952ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Left-compound menu icon positioning fix
comment:
  Positioning of icons in compound menus does not follow
  the normal appearance of Windows menus with both images
  and text, where the image normally appears in the
  margin to the left (i.e., in the same location that a
  check would be were it a checkbutton type menu item). 
  Instead, the icon is left-aligned with the other menu
  items that don't have icons, when all of the text
  should be aligned on the left whether there is an icon
  or not.

  This patch adjusts the text and image offsets for the
  "left" compound menu entries so that the icon appears
  in the margin as long as the entry is not a checkbutton
  or radiobutton.  The same change could probably be
  applied to the other platform menus depending on how
  they "normally" look on those platforms, since the
  offset code appears to be the same in tkUnixMenu.c and
  tkMacMenu.c, but I'm not certain what the "normal" look
  is on those platforms and haven't tested the change there.


tkt_uuid: 2336454fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: new test failures
comment:
  ==== bind-13.1 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind Test <KeyPress> {lappend x "%W %K Test KeyPress"}
      bind all <KeyPress> {lappend x "%W %K all KeyPress"}
      bind Test : {lappend x "%W %K Test :"}
      bind all _ {lappend x "%W %K all _"}
      bind .t.f : {lappend x "%W %K .t.f :"}

      event generate .t.f <Key-:>
      event generate .t.f <Key-+>
      event generate .t.f <Key-_>
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.1 FAILED



  ==== bind-13.4 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind Test : {lappend x "%W %K Test"}
      bind .t.f : {lappend x "%W %K .t.f"}
      foo
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      (procedure "foo" line 3)
      invoked from within
  "foo"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.4 FAILED



  ==== bind-13.7 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind .t.f : {lappend x "%W (.t.f binding)"}
      bind Test : {lappend x "%W (Test binding)"}
      bind all : {bind .t.f : {}; lappend x "%W (all binding)"}
      event generate .t.f <Key-:>
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.7 FAILED



  ==== bind-13.8 Tk_BindEvent procedure FAILED
  ==== Contents of test case:

      bind .t.f : {lappend x "%W (.t.f binding)"}
      bind Test : {lappend x "%W (Test binding)"}
      bind all : {destroy .t.f; lappend x "%W (all binding)"}
      event generate .t.f <Key-:>
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "event generate .t.f <Key-:>"
      ("uplevel" body line 5)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.8 FAILED



  ==== bind-13.13 Tk_BindEvent procedure: valid key detail FAILED
  ==== Contents of test case:

      bind .t.f <Key> "lappend x Key%K"
      bind .t.f <KeyRelease> "lappend x Release%K"
      event generate .t.f <Key> -keysym :
      event generate .t.f <KeyRelease> -keysym :
      return $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: unknown keysym ":"
      while executing
  "event generate .t.f <Key> -keysym :"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-13.13 FAILED



  ==== bind-28.5 keysym names FAILED
  ==== Contents of test case:

          bind .t.f <Key-:> "lappend x \"keysym received\""
          bind .t.f <Key-_> "lappend x {bad binding match}"
          set x [lsort [bind .t.f]]
          event generate .t.f <Key-:> ;# -state 0
          set x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad event type or keysym ":"
      while executing
  "bind .t.f <Key-:> "lappend x \"keysym received\"""
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== bind-28.5 FAILED


tkt_uuid: 1692397fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Wont Fix
title: Poor text widget performance in Tk 8.5a6
comment:
  The following simple script demonstrates a siginificant text widget performance regression in Tk 8.5a6:

  pack [text .t]
  puts [time {
      for {set n 1} {$n <= 100000} {incr n} {
          .t insert end "This is line #$n\n"
      }
  }]

  On my rather slow Linux box (running SuSE Linux 10.0), this script produces the output

  1580878 microseconds per iteration

  Compare this with the time needed by Tk 8.4.13:

  1238126 microseconds per iteration

  This is a rather worrying performance regression, especially taking into account that the text widget implementation has been objectified in Tk 8.5.


tkt_uuid: 220155ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Works For Me
title: make test crashes with Tk and threading
comment:
  OriginalBugID: 1654 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-29'
  LastModified: '1999-08-31'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-08-31'


  Name:
  Larry W. Virden

  Extensions:
  Tk 8.1b2

  CustomShell:
  none

  ReproducibleScript:
      I configured Tk using
      # /vol/tclsrcsol/tcl81/tk8.1b2/unix/configure  --prefix=/usr/tcl81
      --exec_prefix
      =/usr/tcl81/sun4 --enable-threads --enable-shared --with-x
      --enable-tcl-stub
      
      I then did a make test.
      



  ObservedBehavior:
      dbx tktest core
      Reading symbolic information for tktest
      core file header read successfully
      Reading symbolic information for rtld /usr/lib/ld.so.1
      dbx: program is not active
      Reading symbolic information for libtk8.1.so
      Reading symbolic information for libtcl8.1.so
      Reading symbolic information for libsocket.so.1
      Reading symbolic information for libnsl.so.1
      Reading symbolic information for libpthread.so.1
      Reading symbolic information for libX11.so.4
      Reading symbolic information for libdl.so.1
      Reading symbolic information for libm.so.1
      Reading symbolic information for libc.so.1
      Reading symbolic information for libmp.so.2
      Reading symbolic information for libXext.so.0
      Reading symbolic information for libc_psr.so.1
      Reading symbolic information for libthread.so.1
      detected a multithreaded program
      dbx: program is not active
      t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
      (dbx 1) where                                                  
      current thread: t@1
      =>[1] main(0x4, 0xefffd6f4, 0x31bf0, 0x33000, 0x0, 0x0), at 0x1d5fc
      



  DesiredBehavior:
      I expected to see Tk build and run properly.
      




  I cannot reproduce this behavior.  This appears to be a threading problem, and since threading has undergone so much change lately, I think this may be fixed, but let's wait and see...
  I've email Larry and asked him to let me know if this is still a bug.
  04/20/1999 20:35 - hershey -
  --
  Threading is known to have problems with Tk in 8.1.  It could possibly
  work with 8.2 on some platforms, but still needs work. 
  -- 08/31/1999 hobbs


tkt_uuid: 220722ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Need to deiconify parents of transient windows
comment:
  OriginalBugID: 4997 Bug
  Version: 8.3
  SubmitDate: '2000-04-11'
  LastModified: '2000-04-17'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4266 4221
  OS: All Unix
  OSVersion: 6.2
  Machine: SGI O2. Also witnessed on other platforms
  FixedDate: '2000-04-17'
  FixedInVersion: 8.3.1


  Name:

  James Bonfield


  Extensions:

  none


  ReproducibleScript:

  wm iconify . 

  update idletasks 

  tkMessageBox -parent . -message "test"


  ObservedBehavior:

  On _some_ window managers, the message box displayed is not displayed at all. This is because

  the window manager chooses to display the child transient window as iconified as the parent was

  already iconified. Not a good strategy when we go on to do a local grab of that window!


  An example window manager is SGI's 4dwm.


  ICCCM states that this is up to the window manager.


  DesiredBehavior:

  Ideally for the transient window to always be visible. It isn't just enough to require the programmer

  to deal with this case as the problem also arises for Tk error message windows, which may

  therefore have the effect of apparently freezing the application.


  My solution is simply to deiconify the parent window. Crude, but effective.


  Patch:

  *** orig/msgbox.tcl     Fri Dec  3 07:15:02 1999

  --- new/msgbox.tcl      Tue Apr  4 16:52:37 2000

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

  *** 249,254 ****

  --- 249,262 ----

          unsupported1 style $w dBoxProc

        }


  +     # Make sure parent window is deiconified. Good window managers will do

  +     # this anyway, but some (eg SGI's 4dwm) will simply create this child

  +     # window as iconified if the parent is also iconified, which is a very

  +     # bad idea for "grab"bed windows.

  +     if {[wm state [winfo toplevel [winfo parent $w]]] != "normal"} {

  +         wm deiconify [winfo toplevel [winfo parent $w]]

  +     }

  + 

        frame $w.bot

        pack $w.bot -side bottom -fill both

        frame $w.top

  *** orig/dialog.tcl     Wed Jan 12 11:45:14 2000

  --- new/dialog.tcl      Tue Apr  4 16:52:26 2000

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

  *** 63,68 ****

  --- 63,76 ----

          unsupported1 style $w dBoxProc

        }


  +     # Make sure parent window is deiconified. Good window managers will do

  +     # this anyway, but some (eg SGI's 4dwm) will simply create this child

  +     # window as iconified if the parent is also iconified, which is a very

  +     # bad idea for "grab"bed windows.

  +     if {[wm state [winfo toplevel [winfo parent $w]]] != "normal"} {

  +         wm deiconify [winfo toplevel [winfo parent $w]]

  +     }

  + 

        frame $w.bot

        frame $w.top

        if {[string equal $tcl_platform(platform) "unix"]} {


  PatchFiles:

  msgbox.tcl

      dialog.tcl




  I fixed this problem in CVS, and the fix will go out with 8.3.1.  I did not fix it in exactly the same way that you proposed in your patch.  Rather than deiconifying the parent window, I chose to make the dialog/message box not transient if the parent is not viewable.  This acheives the same goal, but is more backwards compatible -- consider the many users who don't use "." in their applications, and who don't set an appropriate parent for their dialogs -- all of a sudden they will get "." popping up in their app, for no good reason.  Thus, Jeff and I felt that the solution I chose is the better one.

  Thanks,

  - eric

  -- 04/17/2000 ericm


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

  Here is a Wish script demonstrating the problem

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

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


tkt_uuid: 219910ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Stack Overrun
comment:
  OriginalBugID: 944 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-14'
  LastModified: '1998-12-15'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: pat
  OS: Windows NT
  OSVersion: 4.0 Service Pack 4
  Machine: X86
  ClosedDate: '1998-12-15'


  Name:
  Tom Halliley

  CustomShell:
  None.

  ReproducibleScript:
  This happens during load time of wish80d.exe, under Windows NT.

  To reproduce, just double-click wish80d.exe.

  ObservedBehavior:

  In file tkWinMenu.c, routine TkpMenuInit, the following call

  GetTextFace(scratchDC, sizeof(menuFontDString), faceName);

  writes beyond the length of faceName.

  I found this using BoundsChecker (by NuMega).

  Also, In file tclExecute.c, routine RecordTracebackInfo, the following line:

  sprintf(buf, "\n    while executing\n\"%.*s%s\"",                numChars, cmd, ellipsis);

  writes beyond the end of buf.

  I found this using BoundsChecker (by NuMega).



  Duplicate of bug 909 (12/15/98 pat)


tkt_uuid: 1067243fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Works For Me
title: canvImg test failures on WinXP
comment:
  Two tests fail with CVS head.


  ==== canvImg-8.29 ImageToArea procedure FAILED
  ==== Contents of test case:

      .c gettags [.c find overlapping 0 105 50 114.999]

  ---- Result was:
  image
  ---- Result should have been (exact matching):

  ==== canvImg-8.29 FAILED


  ==== canvImg-8.33 ImageToArea procedure FAILED
  ==== Contents of test case:

      .c gettags [.c find overlapping 80 0 150 100]

  ---- Result was:
  image
  ---- Result should have been (exact matching):

  ==== canvImg-8.33 FAILED


tkt_uuid: 458858ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: TIP Implementation
resolution: Duplicate
title: TIP #26 patch
comment:
  This patch is an 8.4a2 patch that implements TIP #26.
  It has been tested on Linux and Windows but still
  needs testing on Mac.


tkt_uuid: 760693ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: None
title: menubuttons lockup
comment:
  just compiled tcl/tk 8.4, win98, with bcc 5.5...
  for testing purposes, went through the widgets..

  can anyone confirm the following:

   - widget tour, menu buttons
   -click a few times on different menu buttons,
    drop down some menus (at most about
    5-10 times), after a while you cannot click 
    the other buttons any more,  not even the "x" 
    window close button! you are stuck

  tried this also with the "rolodex" sample,
  same problem, click a few times on the
  menubotton, and other buttons/fields dont react
  anymore (only way is tab/space keys)


tkt_uuid: 220303ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: strange namespace/upvar interaction.
comment:
  OriginalBugID: 5505 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-15'
  LastModified: '2000-05-15'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  ClosedDate: '2000-05-15'


  Name:
  Vince Darley

  ReproducibleScript:
  # weird namespace/upvar problem

  namespace eval foo {}
  namespace eval bar {}
  namespace eval cow {}

  set cow::one 2
  set bar::one 1

  # multiply, ensuring var exists.
  proc safemultiply {var by} { 
      upvar 1 $var local
      if {![info exists local]} { set local 1 }
      set local [expr {$local *$by}] 
  }

  proc foo::test {} { 
      global bar::one cow::one
      safemultiply bar::one 5
      puts "$bar::one $cow::one" 
  }

  # this works fine
  foo::test
  # result is '5 2' printed to stdout
  foo::test
  # result is '25 2' printed to stdout

  # Now unset the variable, and try again.
  # We expect to get '5 2' again, since
  # safemultiply ensures the variable is set.
  unset cow::one
  foo::test
  # but we get an error: 'can't read "cow::one": no such variable'

  ObservedBehavior:
  Behaviour is described in comments above.  I don't really know if it is a bug or not, but it is definitely rather confusing (and occured in my code, where I unfortunately had two variables named global::prefs and alpha::prefs).

  DesiredBehavior:
  I expected the final 'foo::test' to complete successfully.  Can someone explain this (and/or clarify whether it is a bug or not)?



  This is correct.  The user first mis-types the unset of bar::one,
  but even so, always referencing them relatively is the bug in the
  program. 
  -- 05/15/2000 hobbs


tkt_uuid: 628273ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: Duplicate
title: AIX image buffer allocation failure
comment:
  On an AIX 4.3 system the command "image create 
  photo" fails in file tkImgPhoto.c, function, 
  ImgPhotoSetSize, line 2656, when attemptckalloc() is 
  called.  AIX and some other systems (Tru64) return 
  NULL from an alloc call for 0 size.  This problem affects 
  only Tk 8.4.  The fix that I have successfully tested is

  if ((width != masterPtr->width) || (height != masterPtr-
  >height) || (masterPtr->pix24 == NULL) {
      unsigned size;
      size = height * pitch;
      if (size > 0) {
         newPix24 = (unsigned char *) attemptckalloc(size);
        if (newPix24 == NULL) { return TCL_ERROR; }
        }
     else { newPix24 = NULL; }
     }


tkt_uuid: 220221ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Menu bars and widgets will not activate when window is not active
comment:
  OriginalBugID: 2571 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-18'
  LastModified: '1999-08-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  ClosedDate: '1999-08-20'


  Name:
  Kriston J. Rehberg

  Comments:
  I believe this happens with most other widgets on the canvas -- the user
  must first click into the window to make it active... the problem is
  that this click should also activate the widget or pull-down menu
  underneath the pointer, but it does not.
      
  This problem has been around since Tk 4.2 if I recall correctly.  I
  don't think X Windows users would see it since most window managers'
  default behavior is to activate a window under the mouse pointer, making
  this problem hard to duplicate except on MS Windows or in a Unix window
  manager with ClickToFocus turned on.

  ReproducibleScript:
  In the Widget Tour, choose Menus and Cascades.  Try to click one of the
  pull-down menus while the window is not in focus (on Windows, it usually
  isn't in focus).  Nothing will happen unless you click a second time to
  make the window active -- only then will the pull-down menus work.  This
  also happens with the "Dismiss" button and other widgets on the canvas.

  ObservedBehavior:
  The pull-down menu won't activate without clicking a second time.  This
  is unlike any other Windows applicationn which takes the click to
  activate the window as well as an event to click on a pull-down menu or
  widget.

  DesiredBehavior:
  One click should activate the pull-down menu or widget.



  I'm not sure that this is a valid bug.  If you compare the behavior
  of the Tk widget tour with that of Outlook (Outlook 2000 on NT),
  you get pretty much the same behavior.  If Outlook is not the active
  window, and you click into the menus of Outlook, you must click again
  to get the menus to activate.  However, if you aren't clicking into
  the menus but rather into a button (like "Inbox" in the left bar),
  then that will be processed without the need of a second click.

  Tk is the same, menus need the second click, buttons and actions
  for the rest of the interface do not. 
  -- 08/20/1999 hobbs


tkt_uuid: 956681ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: origin depends on highlightthickness
comment:
  Bug or lack in documentation?

  Fact: the topleft origin coordinates of a canvas depends 
  on the value of highlightthickness. As this value defaults 
  to two, the visible origin becomes 2,2.

  The standard documentation does not specifiy the exact 
  coordinates.
  The behaviour as described is tested under Win2K and 
  Win98.

  Rob


tkt_uuid: 220055ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Expecttk doesn't register Tk's stub table
comment:
  OriginalBugID: 4029 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-17'
  LastModified: '2000-05-09'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3646 5341
  OS: All
  ClosedDate: '2000-05-09'


  Name:

  Jan Nijtmans


  Comments:

  Although this problem only occurs in expectk (and possibly other extensions which

  use Tk without calling Tk_Init), the best place to fix it is in Tk. That's what this patch does.


  ReproducibleScript:

  Expecttk cannot load stub-enabled libraries such as Tktable and Img. The cause

  for this problem is that Expecttk doesn't call Tk_Init(), which is the only

  function that registers Tk's stub table in the package database. The

  soltution is straightforward: Just add the necesary initalization to other

  functions, which are called first from Expecttk. Those are Tk_ParseArgv()

  and Tk_CreateFrame(); which of these is called first depends on if Expecttk

  is started with arguments or not.


  ObservedBehavior:

  Try to load a stub-enabled version of Tktable or Img in expectk. The result

  is the error-message: This version of Tk doesn't support stubs.


  Patch:

  *** generic/tkArgv.c.origFri Apr 16 03:51:10 1999

  --- generic/tkArgv.cSun Jan 16 21:05:11 2000

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

  *** 91,96 ****

  --- 91,100 ----

        size_t length;/* Number of characters in current argument. */

        int i;


  +     if (Tcl_InitStubs(interp, "8.1", 0) == NULL) {

  + return TCL_ERROR;

  +     }

  + 

        if (flags & TK_ARGV_DONT_SKIP_FIRST_ARG) {

    srcIndex = dstIndex = 0;

    argc = *argcPtr;

  *** generic/tkFrame.c.origTue Dec 14 07:52:28 1999

  --- generic/tkFrame.cSun Jan 16 21:05:22 2000

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

  *** 241,246 ****

  --- 241,247 ----

     *

     *--------------------------------------------------------------

     */

  + extern TkStubs tkStubs;


    int

    TkCreateFrame(clientData, interp, argc, argv, toplevel, appName)

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

  *** 294,299 ****

  --- 295,304 ----

        unsigned int mask;

        Colormap colormap;

        Visual *visual;

  +     if ((Tcl_InitStubs(interp, "8.1", 0) == NULL) ||

  +     (Tcl_PkgProvideEx(interp, "Tk", TK_VERSION, (ClientData) &tkStubs) != TCL_OK)) {

  + return TCL_ERROR;

  +     }


        if (objc < 2) {

    Tcl_WrongNumArgs(interp, 1, objv, "pathName ?options?");


  PatchFiles:

  tkArgv,c tkFrame.c




  This seems like something that extensions like Expect should fix
  to work with stubs properly, rather than Tk worrying about what
  extensions might otherwise call first and placing hooks there. 
  -- 02/08/2000 hobbs


tkt_uuid: 2860827fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 4
foundin: obsolete: 8.5.7
resolution: Fixed
title: Rendering text of disabled label widgets on Windows
comment:
  Tk 8.5 on Windows started to paint "shadows" for text in disabled labels, checkboxes, buttons in order to give them 3d look. Tk 8.4 didn't do that. Shadow color is determined by calling GetSysColor(COLOR_3DHILIGHT) (see tkWinButton.c). 

  Such behaviour makes it impossible to fully customize appearance of disabled widgets on Tcl level and leads to horrible widget rendering in cases of non-standard background color. See attached Tkabber screenshot.

  Probably, reasonable solution of this problem would be to add either an additional Tk option for this shadow color value (which defaults to what GetSysColor returns) or an option for switching this look-and- feel trick with shadow on and off.


tkt_uuid: 1019100fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: panedwindow-23.2 failure
comment:
  Tk: v8.5a2 HEAD at 30-08-04
  OS: WinXPsp1
  Built with makefile.vc using VC7

  ==== panedwindow-23.2 PanedWindowReqProc, react 
  to slave geometry changes FAILED
  ==== Contents of test case:

      panedwindow .p -orient horizontal -sashpad 0 -
  sashwidth 2
      .p add [frame .f1 -width 10] [frame .f2 -width 10]
      set result [winfo reqwidth .p]
      .f1 configure -width 20
      lappend result [winfo reqwidth .p]
      destroy .p .f1 .f2
      set result

  ---- Result was:
  26 36
  ---- Result should have been (exact matching):
  32 42
  ==== panedwindow-23.2 FAILED

  possibly just needs a '-borderwidth 0' option added 
  to .p, as the window does grow by 10 pixels as 
  expected.

  alternatively, make the expected result 10 and the 
  produced result an expression of 2nd minus 1st


tkt_uuid: 1610236fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: beware FC autoconf fork
comment:
  Not so much a bug as a point
  of information.

  On Fedora 6 system, using
  autoconf-2.59-12, a run of
  autoconf on tk/unix/configure.in
  does not produce tk/unix/configure.

  It seems the FC has a forked version
  of autoconf that supplies a different
  expansion of AC_PATH_X.

  Can anyone comment on whether the
  differences are important enough that
  we need to specify which fork of
  autoconf is to be used to produce
  the tk/unix/configure file?


tkt_uuid: 2876709fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Recreating menu appends duplicate entries
comment:
  In Tk-Cocoa, I've observed that if one tries to reset/recreate a specified menu, the old menu isn't updated in place, but instead has additional, redundant entries appended to the end of the menu. Here's how I reproduce this step:

  1. Run the Tk widget demo in Wish.
  2. Choose the "menu demonstration" demo.
  3. Select the "see code" button from the menu demonstration. 
  4. The menu has these entries: File, Basic, Cascades, Icons, More, Colors.
  5. Click the "see code" button in the demo window.
  6. The code window pops up; select the "rerun demo" window.
  7. Instead of having the menu re-created in place, the menu now appends these entires: Basic, Icons, Colors. The entire menu looks like this: 
   File, Basic, Cascades, Icons, More, Colors, Basic, Icons, Colors. 

  The menu should not behave this way. 

  I first  observed this behavior in IDLE, a Python/Tkinter application, when it's linked to Tk-Cocoa. I originally thought it was a problem with IDLE's code, but after reproducing the behavior in Tk itself, I believe it's something that needs to be addressed in Tk. 


tkt_uuid: 2009788fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.3
resolution: Fixed
title: wm forget crashes on windows
comment:
  The following script crashes wish on windows:

      toplevel .d1
      #update
      wm forget .d1

  Note that it does not crash when run interactively or when 'update' is uncommented. I tried it with ActiveTcl 8.5.2 and etcl-1.0-rc29 (8.5.3).


tkt_uuid: 1713501fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: "dot" radiobutton menu indicator on windows
comment:
  Hello. Thanks for your great work.

  My request is "dot" radiobutton menu indicator.
  the radiobutton menu and checkbutton menu have
  both same "checked" indicator on windows.
  But it seems that many windows applications and
  Tk8.5a6 on linux have "dot" indicator for 
  radiobutton menu.

  I tried to write a patch and tested it on w2k and XP.
  attached file is the screenshot image and the patch 
  for tk8.5a6.

  thanks


tkt_uuid: 1581490fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: None
title: Tk button on Aqua differs between -text and -image
comment:
  The Tk button rendering on Aqua
  differs dramatically between -text and -image options.

  With -image, you get a nice flat button. Using -text
  you get a wide textured button.


tkt_uuid: 820282ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: None
resolution: Fixed
title: Fix for bug #820278
comment:
  This patch fixes bug #820278 which is a problem in the 
  Xlib emulation layer for Windows platforms that causes 
  XFillRectangle() and XFillRectangles() to ignore the 
  graphics context's function if the graphics context's 
  fill_style is non-stippled.

  This patch calls FillRect() if the gc->function is GXcopy 
  as an optimization.  Otherwise, it will need to create an 
  invisible pen and call SelectObject() multiple times to 
  set the pen and brush for the device context.


tkt_uuid: 220836ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.0.4
resolution: None
title: Font {times 14} is larger than {times 15}
comment:
  OriginalBugID: 1809 Bug
  Version: 8.0.4
  SubmitDate: '1999-04-14'
  LastModified: '1999-04-21'
  Severity: LOW
  Status: UnAssn
  Submitter: pat
  ChangedBy: redman
  OS: Linux-Red Hat
  Machine: Other


  Name:
  D. Richard Hipp

  ReproducibleScript:
  See http://www.hwaci.com/private/report.html for a full explanation

  ObservedBehavior:
  On some Unix X-servers, the font named {times 14} is larger than
      the font named {times 15}.  See the URL above for details and
      a fix.

  Patch:
  Provided at the URL above.
  http://www.hwaci.com/private/report.html

  PatchFiles:
  tkUnixFont.c



  4/22/99 - redman - Man, if only all bug reports were this good...
  I'll look at the patch and try it out with 8.1.1. If we have time and it looks good, we'll consider releasing with 8.1.0.


tkt_uuid: 220157ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: The "." window does not respect bindings for the "Toplevel" tag.
comment:
  OriginalBugID: 1702 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-02'
  LastModified: '1999-08-07'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  Tom Hahn

  Comments:
  Broken in both NT and SGI/Irix

  ReproducibleScript:
  The "." window does not respect bindings for the "Toplevel" tag.
      
      If you "bind Toplevel <1> {puts foo}"
      then clicking in newly created toplevels prints "foo", but not in "."



  This is as expected.  The . window will have slightly different
  bindtags than other toplevels as its default class isn't Toplevel,
  but rather the name of the app.  You can add Toplevel with bindtags
  if you wish. 
  -- 08/07/1999 hobbs


tkt_uuid: 220763ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: documentation error in doc/canvas.n
comment:
  OriginalBugID: 6218 Bug
  Version: 8.4a1
  SubmitDate: '2000-09-06'
  LastModified: '2000-09-06'
  Severity: LOW
  Status: Released
  Submitter: angie
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-09-06'
  FixedInVersion: 8.4a2


  Name:  John Ellson

  ObservedBehavior:
  Example of OR operator in advanced tag search expression is incorrect.

  Patch:
  --- doc/canvas.n.origWed Sep  6 12:42:55 2000
  +++ doc/canvas.nWed Sep  6 12:43:15 2000
  @@ -169,7 +169,7 @@
   tags by using operators: '&&', '||', '^' '!', and parenthezised
   subexpressions.  For example:
   .CS
  -      .c find withtag {(a&&!b)|(!a&&b)}
  +      .c find withtag {(a&&!b)||(!a&&b)}
   .CE
   or equivalently:
   .CS




  Fixed in 8.4a2. 
  -- 09/06/2000 hobbs


tkt_uuid: 220182ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Repeated button pressing crashes application.
comment:
  OriginalBugID: 1925 Bug
  Version: 8.0p2
  SubmitDate: '1999-04-23'
  LastModified: '2000-01-21'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: 4.0 (SP 3)
  Machine: X86
  ClosedDate: '2000-01-21'


  Name: Sven Delmas

  ReproducibleScript:
  catch {destroy .b}
  button .b -command call
  pack .b
  bind Button <Key-a> [bind Button <Key-space>]

  proc call {} {
      .b config -text [clock format [clock clicks]]
      update
  }

  ObservedBehavior:
  Run the script and press (and hold the a key... I use a because space
      will automatically select OK in the core dump dialog). The program will
      crash with a stack overflow within 1 or 2 minutes.

  DesiredBehavior:
  It should not crash.

  I can't reproduce this, and neither can Sven.  My guess is that it was an issue with the particular system (badness in NT, perhaps).

  - eric

  -- 01/21/2000 ericm


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: 1032943fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.4.7
resolution: None
title: menubutton indicator always on for aqua tk
comment:
  the menubutton "menu" indicator (controlled by 
  indicatoron) is always present on Aqua tcl/tk (e.g. MacOS X 
  10.3.4, Aqua tcl/tk 8.4.7 but also for every earlier version I 
  tried).

  If one sets indicatoron=0 one sees that the menu becomes 
  narrower (by approximately the width of the menu 
  indicator) but the indicator is still there; the space is taken 
  out of the area used for displaying the text of the 
  menubutton.

  As a consequence, the displayed text may become 
  truncated. This truncation occurs quite reliably if the font 
  size is small (less than 13 point or so), at least for my 
  menubuttons which typically have 3-5 characters in their 
  text.

  -- Russell


tkt_uuid: 220584ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Tk8.2 does not include configure.in's macro definition
comment:
  OriginalBugID: 2595 RFE
  Version: 8.2
  SubmitDate: '1999-08-20'
  LastModified: '2000-01-12'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: FreeBSD-3.2-stable
  Machine: NA
  FixedDate: '2000-01-12'
  FixedInVersion: 8.3b2


  Name:
  Taguchi, Takeshi

  DesiredBehavior:
  I think Tk's configure.in has some external m4 macros, such as
      'SC_PATH_TCLCONFIG' etc.
      But dist tar ball for Tk8.2.0 does not include these macros.
      So I can not enhance configure.in.
      Would you like include them?
      
      And another request.
      Tk8.2.0 does not support XIM.
      I feel sadness, strongly.....;-(
      Would you like support XIM? Please!



  The aclocal.m4 is now included in the distribution.

  As for XIM, with 8.3 we have made it a run-time option, and we
  would be open to better supporting it if we receive patches. 
  -- 01/12/2000 hobbs


tkt_uuid: 1640073fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: change ttk_* to ttk:: in man pages
comment:
  The ttk commands are referrenced in the man pages as ttk_<command> and ttk::<command>  This is confusing and should be changed to use the correct ttk::<command> syntax throughout.

  ttk_button(n)                 Tk Themed Widget                 ttk_button(n)

  ______________________________________________________________________________

  NAME
         ttk_button - Widget that issues a command when pressed
  ^^^^^^^^^^^^
  Note:  here the '_' is used.

  SYNOPSIS
         ttk::button pathName ?options?
  ^^^^^^^^^^^^
  But, here '::' is used.


  I've attached modified man pages with these changes.

  -Brian


tkt_uuid: 523303ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: None
title: Bug in binding non-ascii characters...
comment:
  tk_messageBox has a bug that shows up under unix
  (as it involves the tcl implementation used only under
  unix). When through the message catalog a string in
  a non-english language is retrieved (i.e. greek),
  the code tries to add a binding using:

  bind widget <Alt-[string tolower $key]> ...

  This throughs an error if the key is not recognised as
  a keysym:

  bad event type or keysym "..."

  One of the possible solutions is to check whether the character
  is an ASCII one before it is attempt to place the binding:

  Line 379, library/msgbox.tcl:

    bind $w <Alt-[string tolower $key]>  [list $w.$name invoke]
    bind $w <Alt-[string toupper $key]>  [list $w.$name invoke]

  could be changed to:

    ## We cannot bind characters above the ASCII character set...
    if {[scan $key %c] <= 128} {
      bind $w <Alt-[string tolower $key]>  [list $w.$name invoke]
      bind $w <Alt-[string toupper $key]>  [list $w.$name invoke]
    } else {
      $w.$name configure -underline -1;# Remove also the underline
    }


tkt_uuid: 2886998fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Duplicate
title: -indicatoron no effect on menu radiobuttons
comment:
  When creating a menu with multiple radiobutton entries, using "-indicatoron 1" on one of the entries has no effect.  If the designated variable for the entries is unset, no entries have an indicator on when the menu is displayed.  If the designated variable is set for one of the entries, that entry has its indicator on, even if "indicatoron 1" is set for another entry.

  Example 1:

  set selectedButton Reject
  set m [menu .m -tearoff 0]
  $m add radiobutton -label Accept -indicatoron 1
  $m add radiobutton -label Reject
  $m add radiobutton -label Undecided
  tk_popup $m 0 0

  the menu that appears has the "Reject" entry selected.  The "-indicatoron 1" flag is ignored.

  Example 2:

  destroy .m
  unset selectedButton
  set m [menu .m -tearoff 0]
  $m add radiobutton -label Accept -indicatoron 1
  $m add radiobutton -label Reject
  $m add radiobutton -label Undecided
  tk_popup $m 0 0

  the menu that appears has no entries selected.  The "-indicatoron 1" flag is again ignored.

  version 8.5.5 on Ubuntu Hardy using Gnome.


tkt_uuid: 617392ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: File browser scales wrongly on Unix/Linu
comment:
  On Unix/Linux the file browser scales wrongly if one is 
  using a very long list of file types "that had a
  gazillion *.xxx types attached".

  One needs an option to control the width of the file 
  browser widget in cases like this.


tkt_uuid: 220297ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: Can't find a usable tk.tcl i
comment:
  OriginalBugID: 5173 RFE
  Version: 8.3
  SubmitDate: '2000-04-19'
  LastModified: '2000-04-19'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: solaris 7
  Machine: sun ultra 5
  ClosedDate: '2000-04-19'


  Name: WArren Dodge

  DesiredBehavior:
  Better searching for components needed by tcl/tk

  tcl built this way
  /configure  --prefix=/vol/tcltk/tcl8.3.0/sun5.7 --enable-gcc --verbose --enable-shared

  tk built this way
  ./configure  --prefix=/vol/tcltk/tk8.3.0/sun5.7 --with-tcl=/vol/tcltk/tcl/sun5.7/lib --enable-gcc --verbose --enable-shared

  This all built but when I run wish this comes out

  wish
  Application initialization failed: Can't find a usable tk.tcl in the following directories: 
      /vol/tcltk/tcl8.3.0/sun5.7/lib/tk8.3 /lib/tk8.3 /lib/tk8.3 /library /library /tk8.3/library /tk8.3/library

  This probably means that tk wasn't installed properly.

  It seems odd that wish didn't look in the tk path for the file.



  You just need to install Tk first, or set the TK_LIBRARY path
  in your shell temporarily to test.  The 'make test' will do
  this for you.  Tk is built such that it looks by default in
  the directory you would install it in. 
  -- 04/19/2000 hobbs


tkt_uuid: 1860802fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 9 Immediate
foundin: obsolete: 8.5.0
resolution: Fixed
title: Tk demo fails: mcset invalid command
comment:
  I just installed ActiveTcl 8.5.0 on Windows XP Home and tried to see
  the demos,
  but this failed due to mcset being an invalid command name:

  invalid command name "mcset"
  while executing
  "mcset nl "Widget Demonstration" "Demonstratie van widgets"
  ...
  invoked from within
  "::source -encoding utf-8 c:/tcl85/demos/tk8.5/nl.msg
  ...
  "::msgcat::mcload $tk_demoDirectory" 


tkt_uuid: 220043ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Duplicate
title: Filename Browser displays cryptic file names
comment:
  OriginalBugID: 3514 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-08'
  LastModified: '1999-11-16'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3554
  OS: All Unix
  OSVersion: PowerMax OS 4.3 SVR4 Unix
  Machine: Concurrent PowerHawk
  ClosedDate: '1999-11-16'


  Name:
  Bob Yunk

  CustomShell:
  no changes

  ReproducibleScript:
  The tk filename browser is displaying cryptic symbols for the file names.  I built tcl and tk 8.2.1 on a Unix SVR4 operating system (PowerMax OS 4.3 from Concurrent).  I had to change some parameters in the Makefile to get a successful build.  Where can I start looking to narrow down the problem.  I can debug if possible.


tkt_uuid: 1956566fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 8
foundin: None
resolution: Works For Me
title: Crash bug in Tclkit on MacOS X/Aqua
comment:
  Hopefully this is the right place for this. Running a starpack (Tcl 8.5.1) on MacOS X (10.5.2) under Aqua caused a crash when running a particular procedure, and gave this on the console:

  TkpGetFontAttrsForChar: drawingContext not setup

  and produced the (rather huge) crash report at the bottom. The line of Tcl code that caused the crash was:

    if { [string equal [font actual [$sub.entry cget -font]] [font actual [$sub.entry cget -font] \u25cf]] } {
   #...
  }

  $sub.entry is an entry widget; commenting out the if and just allowing the code inside it to run solved the problem.

  Process:         potato-a [312]
  Path:            /Users/bigmanshawn/potato-a
  Identifier:      potato-a
  Version:         ??? (???)
  Code Type:       X86 (Native)
  Parent Process:  bash [277]

  Date/Time:       2008-05-02 21:58:06.325 -0700
  OS Version:      Mac OS X 10.5.2 (9C31)
  Report Version:  6

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

  Thread 0 Crashed:
  0   libSystem.B.dylib             0x90fa00ea __kill + 10
  1   libSystem.B.dylib             0x910173f2 raise + 26
  2   libSystem.B.dylib             0x910269af abort + 73
  3   potato-a                      0x00077c8f 0x1000 + 486543
  4   potato-a                      0x00077caa 0x1000 + 486570
  5   [Memory Based Bundle]         0x0130e301 Tk_DrawChars + 207
  6   [Memory Based Bundle]         0x0126c4cb Tk_GetFont + 1036
  7   potato-a                      0x000105ad 0x1000 + 62893
  8   potato-a                      0x00048a6e 0x1000 + 293486
  9   potato-a                      0x00082c8e 0x1000 + 531598
  10  potato-a                      0x000105ad 0x1000 + 62893
  11  potato-a                      0x00048a6e 0x1000 + 293486
  12  potato-a                      0x00051192 0x1000 + 328082
  13  potato-a                      0x000135c2 0x1000 + 75202
  14  potato-a                      0x000136cc 0x1000 + 75468
  15  [Memory Based Bundle]         0x01290d22  
  TkToplevelWindowForCommand + 16856
  16  [Memory Based Bundle]         0x013151d3  
  TkMacOSXClearMenubarActive + 138
  17  potato-a                      0x0008cfda 0x1000 + 573402
  18  potato-a                      0x000751f0 0x1000 + 475632
  19  [Memory Based Bundle]         0x01267885 Tk_MainLoop + 37
  20  potato-a                      0x0006e4e0 0x1000 + 447712
  21  potato-a                      0x00004740 0x1000 + 14144
  22  potato-a                      0x0000356c 0x1000 + 9580
  23  potato-a                      0x00003499 0x1000 + 9369

  Thread 1:
  0   libSystem.B.dylib             0x90f6972e select$DARWIN_EXTSN 
  $NOCANCEL + 10
  1   potato-a                      0x000a31d2 0x1000 + 664018
  2   libSystem.B.dylib             0x90f62c55 _pthread_start + 321
  3   libSystem.B.dylib             0x90f62b12 thread_start + 34

  Thread 0 crashed with X86 Thread State (32-bit):
     eax: 0x00000000  ebx: 0x9102696f  ecx: 0xbfffe97c  edx: 0x90fa00ea
     edi: 0x00000002  esi: 0x16af14c0  ebp: 0xbfffe998  esp: 0xbfffe97c
      ss: 0x0000001f  efl: 0x00000282  eip: 0x90fa00ea   cs: 0x00000007
      ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
     cr2: 0x16af1000

  Binary Images:
       0x1000 -    0xf9feb +potato-a ??? (???)  
  <771e005f73b41ee0673d4e12c5f44044> /Users/bigmanshawn/potato-a
     0x1de000 -   0x1ecfeb  libSimplifiedChineseConverter.dylib ???  
  (???) <a506528715475cff6c623675f3a72bf8> /System/Library/CoreServices/ 
  Encodings/libSimplifiedChineseConverter.dylib
     0x6e7000 -   0x6f9fff  libTraditionalChineseConverter.dylib ???  
  (???) <62db211c07419a0432254a86fcc96587> /System/Library/CoreServices/ 
  Encodings/libTraditionalChineseConverter.dylib
    0x1254000 -  0x1342fe7 +[Memory Based Bundle] ??? (???)  
  <0afcd5fd10a997627f138b4a315355e8> [Memory Based Bundle]
  0x15a83000 - 0x15b71fef  com.apple.RawCamera.bundle 2.0.2 (2.0.2) / 
  System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
  0x8fe00000 - 0x8fe2da53  dyld 96.2 (???)  
  <7af47d3b00b2268947563c7fa8c59a07> /usr/lib/dyld
  0x90003000 - 0x900e4ff7  libxml2.2.dylib ??? (???)  
  <450ec38b57fb46013847cce851001a2f> /usr/lib/libxml2.2.dylib
  0x900e5000 - 0x904f5fef  libBLAS.dylib ??? (???) /System/Library/ 
  Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/ 
  Versions/A/libBLAS.dylib
  0x90539000 - 0x90545ff5  libGL.dylib ??? (???) /System/Library/ 
  Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
  0x9054c000 - 0x90d49fef  com.apple.AppKit 6.5.2 (949.26)  
  <bc4593edd8a224409fb6953a354505a0> /System/Library/Frameworks/ 
  AppKit.framework/Versions/C/AppKit
  0x90d4a000 - 0x90d6efff  libxslt.1.dylib ??? (???)  
  <4933ddc7f6618743197aadc85b33b5ab> /usr/lib/libxslt.1.dylib
  0x90da9000 - 0x90e28ff5  com.apple.SearchKit 1.2.0 (1.2.0)  
  <277b460da86bc222785159fe77e2e2ed> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/ 
  Versions/A/SearchKit
  0x90e29000 - 0x90ee3fe3  com.apple.CoreServices.OSServices 224.4  
  (224.4) <ff5007ab220908ac54b6c661e447d593> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/OSServices.framework/ 
  Versions/A/OSServices
  0x90ee4000 - 0x90f13fe3  com.apple.AE 402.2 (402.2)  
  <e01596187e91af5d48653920017b8c8e> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
  0x90f14000 - 0x90f14ffa  com.apple.CoreServices 32 (32)  
  <2fcc8f3bd5bbfc000b476cad8e6a3dd2> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/CoreServices
  0x90f15000 - 0x90f30ffb  libPng.dylib ??? (???)  
  <85ca18172d7a4b5a5be3574e4e879880> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
  Versions/A/Resources/libPng.dylib
  0x90f31000 - 0x91090ff3  libSystem.B.dylib ??? (???)  
  <4899376234e55593b22fc370935f8cdf> /usr/lib/libSystem.B.dylib
  0x91091000 - 0x910eeffb  libstdc++.6.dylib ??? (???)  
  <04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib
  0x910ef000 - 0x9112cff7  libGLImage.dylib ??? (???)  
  <202d73e6a4688fc06ff11b71910c2ce7> /System/Library/Frameworks/ 
  OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
  0x9181d000 - 0x91826fff  com.apple.speech.recognition.framework 3.7.24  
  (3.7.24) <d3180f9edbd9a5e6f283d6156aa3c602> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/ 
  Versions/A/SpeechRecognition
  0x91827000 - 0x91832ff9  com.apple.helpdata 1.0 (14) /System/Library/ 
  PrivateFrameworks/HelpData.framework/Versions/A/HelpData
  0x91851000 - 0x918a1ff7  com.apple.HIServices 1.7.0 (???)  
  <f7e78891a6d08265c83dca8e378be1ea> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  HIServices.framework/Versions/A/HIServices
  0x918a2000 - 0x918a2ff8  com.apple.ApplicationServices 34 (34)  
  <8f910fa65f01d401ad8d04cc933cf887> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/ApplicationServices
  0x91a47000 - 0x91a48ffc  libffi.dylib ??? (???)  
  <a3b573eb950ca583290f7b2b4c486d09> /usr/lib/libffi.dylib
  0x91a49000 - 0x91a71ff7  com.apple.shortcut 1 (1.0)  
  <057783867138902b52bc0941fedb74d1> /System/Library/PrivateFrameworks/ 
  Shortcut.framework/Versions/A/Shortcut
  0x929bc000 - 0x92a33fe3  com.apple.CFNetwork 221.5 (221.5)  
  <5474cdd7d2a8b2e8059de249c702df9e> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/ 
  Versions/A/CFNetwork
  0x92a34000 - 0x92a3cfff  com.apple.DiskArbitration 2.2.1 (2.2.1)  
  <75b0c8d8940a8a27816961dddcac8e0f> /System/Library/Frameworks/ 
  DiskArbitration.framework/Versions/A/DiskArbitration
  0x92a3d000 - 0x92ac6fe3  com.apple.DesktopServices 1.4.5 (1.4.5)  
  <8b264cd6abbbd750928c637e1247269d> /System/Library/PrivateFrameworks/ 
  DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
  0x92ac7000 - 0x92addfe7  com.apple.CoreVideo 1.5.0 (1.5.0)  
  <7e010557527a0e6d49147c297d16850a> /System/Library/Frameworks/ 
  CoreVideo.framework/Versions/A/CoreVideo
  0x92b51000 - 0x92b7efeb  libvDSP.dylib ??? (???)  
  <b232c018ddd040ec4e2c2af632dd497f> /System/Library/Frameworks/ 
  Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/ 
  libvDSP.dylib
  0x92b7f000 - 0x92b81ff5  libRadiance.dylib ??? (???)  
  <b9e04afa91e4b597a00797d67a7268fb> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
  Versions/A/Resources/libRadiance.dylib
  0x92b85000 - 0x92bcafef  com.apple.Metadata 10.5.2 (398.7)  
  <73a6424c06effc474e699cde6883de99> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/Metadata.framework/ 
  Versions/A/Metadata
  0x92bcb000 - 0x92c56fff  com.apple.framework.IOKit 1.5.1 (???)  
  <a17f9f5ea7e8016a467e67349f4d3d03> /System/Library/Frameworks/ 
  IOKit.framework/Versions/A/IOKit
  0x92c57000 - 0x92cb1ff7  com.apple.CoreText 2.0.1 (???)  
  <07494945ad1e3f5395599f42748457cc> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/ 
  Versions/A/CoreText
  0x92d52000 - 0x92d54fff  com.apple.securityhi 3.0 (30817)  
  <dbe328cd62d603a952a4226342711e8b> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/ 
  SecurityHI
  0x92d55000 - 0x933eefff  com.apple.CoreGraphics 1.351.21 (???)  
  <6c93fd21149f389129fe47fa6ef71880> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  CoreGraphics.framework/Versions/A/CoreGraphics
  0x93440000 - 0x93440fff  com.apple.Carbon 136 (136)  
  <9961570a497d79f13b8ea159826af42d> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Carbon
  0x93441000 - 0x93579ff7  libicucore.A.dylib ??? (???)  
  <afcea652ff2ec36885b2c81c57d06d4c> /usr/lib/libicucore.A.dylib
  0x9358a000 - 0x93655fff  com.apple.ColorSync 4.5.0 (4.5.0) /System/ 
  Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ 
  ColorSync.framework/Versions/A/ColorSync
  0x9373e000 - 0x937d1ff3  com.apple.ApplicationServices.ATS 3.2 (???)  
  <cdf31bd0ac7de54a35ee2d27cf86b6be> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/ 
  Versions/A/ATS
  0x938c5000 - 0x93b9eff3  com.apple.CoreServices.CarbonCore 785.8  
  (785.8) <827c228e7d717b397cdb4941eba69553> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/ 
  Versions/A/CarbonCore
  0x93c22000 - 0x93d07ff3  com.apple.CoreData 100.1 (186)  
  <8e28162ef2288692615b52acc01f8b54> /System/Library/Frameworks/ 
  CoreData.framework/Versions/A/CoreData
  0x93d08000 - 0x93d42fff  com.apple.coreui 1.1 (61) /System/Library/ 
  PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
  0x93f08000 - 0x93f3ffff  com.apple.SystemConfiguration 1.9.1 (1.9.1)  
  <8a76e429301afe4eba1330bfeaabd9f2> /System/Library/Frameworks/ 
  SystemConfiguration.framework/Versions/A/SystemConfiguration
  0x93fb3000 - 0x940d7fe3  com.apple.audio.toolbox.AudioToolbox 1.5.1  
  (1.5.1) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/ 
  AudioToolbox
  0x94210000 - 0x9421bfe7  libCSync.A.dylib ??? (???)  
  <482d16ba55f91a5dc05f78cc9db707a7> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
  0x9421c000 - 0x94221fff  com.apple.CommonPanels 1.2.4 (85)  
  <ea0665f57cd267609466ed8b2b20e893> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/ 
  A/CommonPanels
  0x94222000 - 0x945e0fea  libLAPACK.dylib ??? (???) /System/Library/ 
  Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/ 
  Versions/A/libLAPACK.dylib
  0x94630000 - 0x94775ff7  com.apple.ImageIO.framework 2.0.1 (2.0.1)  
  <68ba11e689a9ca30f8310935cd1e02d6> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
  Versions/A/ImageIO
  0x9477e000 - 0x947daff7  com.apple.htmlrendering 68 (1.1.3)  
  <fe87a9dede38db00e6c8949942c6bd4f> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/ 
  Versions/A/HTMLRendering
  0x947db000 - 0x9481dfef  com.apple.NavigationServices 3.5.1 (161)  
  <cc6bd78eabf1e2e7166914e9f12f5850> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/ 
  Versions/A/NavigationServices
  0x9481e000 - 0x9483cfff  libresolv.9.dylib ??? (???)  
  <0629b6dcd71f4aac6a891cbe26253e85> /usr/lib/libresolv.9.dylib
  0x9483d000 - 0x94855fff  com.apple.openscripting 1.2.6 (???)  
  <b8e553df643f2aec68fa968b3b459b2b> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/ 
  Versions/A/OpenScripting
  0x94856000 - 0x94864ffd  libz.1.dylib ??? (???)  
  <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib
  0x94865000 - 0x9486cffe  libbsm.dylib ??? (???)  
  <d25c63378a5029648ffd4b4669be31bf> /usr/lib/libbsm.dylib
  0x9486d000 - 0x9494cfff  libobjc.A.dylib ??? (???)  
  <a53206274b6c2d42691f677863f379ae> /usr/lib/libobjc.A.dylib
  0x9494d000 - 0x949fdfff  edu.mit.Kerberos 6.0.12 (6.0.12)  
  <9e98dfb4cde8b0510fdd972dc9fa1dc9> /System/Library/Frameworks/ 
  Kerberos.framework/Versions/A/Kerberos
  0x949fe000 - 0x94a3ffe7  libRIP.A.dylib ??? (???)  
  <9d42e83d860433f9126c4871d1fe0ce8> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
  0x94aad000 - 0x94e43ff7  com.apple.QuartzCore 1.5.1 (1.5.1)  
  <665c80f6e28555b303020c8007c36b8b> /System/Library/Frameworks/ 
  QuartzCore.framework/Versions/A/QuartzCore
  0x94e44000 - 0x94e44ffd  com.apple.Accelerate.vecLib 3.4.2 (vecLib  
  3.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/ 
  Frameworks/vecLib.framework/Versions/A/vecLib
  0x94e45000 - 0x94e49fff  libmathCommon.A.dylib ??? (???) /usr/lib/ 
  system/libmathCommon.A.dylib
  0x94e57000 - 0x94e5eff7  libCGATS.A.dylib ??? (???)  
  <dd3161e6653fa6400b9ef9c144309fa5> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib
  0x94e5f000 - 0x94e5fffb  com.apple.installserver.framework 1.0 (8) / 
  System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/ 
  InstallServer
  0x94f62000 - 0x94f6ffe7  com.apple.opengl 1.5.5 (1.5.5)  
  <aa08b52d2a84b44dc6ee5d544a53fe8a> /System/Library/Frameworks/ 
  OpenGL.framework/Versions/A/OpenGL
  0x94fa9000 - 0x95223fe7  com.apple.Foundation 6.5.4 (677.15)  
  <6216196287f98a65ddb654d04d773e7b> /System/Library/Frameworks/ 
  Foundation.framework/Versions/C/Foundation
  0x95323000 - 0x95339fff  com.apple.DictionaryServices 1.0.0 (1.0.0)  
  <ad0aa0252e3323d182e17f50defe56fc> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/ 
  DictionaryServices.framework/Versions/A/DictionaryServices
  0x9533a000 - 0x9534eff3  com.apple.ImageCapture 4.0 (5.0.0) /System/ 
  Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ 
  ImageCapture.framework/Versions/A/ImageCapture
  0x95350000 - 0x9537bfe7  libauto.dylib ??? (???)  
  <42d8422dc23a18071869fdf7b5d8fab5> /usr/lib/libauto.dylib
  0x95382000 - 0x95392fff  com.apple.speech.synthesis.framework 3.6.59  
  (3.6.59) <4ffef145fad3d4d787e0c33eab26b336> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  SpeechSynthesis.framework/Versions/A/SpeechSynthesis
  0x95393000 - 0x9539dfeb  com.apple.audio.SoundManager 3.9.2 (3.9.2)  
  <0f2ba6e891d3761212cf5a5e6134d683> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/ 
  A/CarbonSound
  0x9539e000 - 0x953a5fe9  libgcc_s.1.dylib ??? (???)  
  <a9ab135a5f81f6e345527df87f51bfc9> /usr/lib/libgcc_s.1.dylib
  0x953a6000 - 0x953a6ffd  com.apple.Accelerate 1.4.2 (Accelerate  
  1.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/ 
  Accelerate
  0x953bf000 - 0x9543cfef  libvMisc.dylib ??? (???) /System/Library/ 
  Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/ 
  Versions/A/libvMisc.dylib
  0x9543d000 - 0x95463fff  libcups.2.dylib ??? (???)  
  <85ce204da14d62d6a3a5a9adfba01455> /usr/lib/libcups.2.dylib
  0x95464000 - 0x954ebff7  libsqlite3.0.dylib ??? (???)  
  <6978bbcca4277d6ae9f042beff643f7d> /usr/lib/libsqlite3.0.dylib
  0x9569b000 - 0x95866ff7  com.apple.security 5.0.2 (33001)  
  <0788969ffe7961153219be10786da436> /System/Library/Frameworks/ 
  Security.framework/Versions/A/Security
  0x95867000 - 0x95999fef  com.apple.CoreFoundation 6.5.1 (476.10)  
  <d5bed2688a5eea11a6dc3a3c5c17030e> /System/Library/Frameworks/ 
  CoreFoundation.framework/Versions/A/CoreFoundation
  0x9599a000 - 0x95e66ffe  libGLProgrammability.dylib ??? (???)  
  <e8bc0af671427cf2b6279a035805a086> /System/Library/Frameworks/ 
  OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
  0x95e67000 - 0x95e6dfff  com.apple.print.framework.Print 218.0.2  
  (220.1) <8bf7ef71216376d12fcd5ec17e43742c> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
  0x95e7c000 - 0x95e9bffa  libJPEG.dylib ??? (???)  
  <0dd7e9d7fb22174b78205a944144f9c3> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
  Versions/A/Resources/libJPEG.dylib
  0x95e9c000 - 0x95e9ffff  com.apple.help 1.1 (36)  
  <b507b08e484cb89033e9cf23062d77de> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
  0x96127000 - 0x961eeff2  com.apple.vImage 3.0 (3.0) /System/Library/ 
  Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/ 
  Versions/A/vImage
  0x963d6000 - 0x96450ff8  com.apple.print.framework.PrintCore 5.5.2  
  (245.1) <3c9de512e95fbd838694ee5008d56a28> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  PrintCore.framework/Versions/A/PrintCore
  0x96451000 - 0x96490fef  libTIFF.dylib ??? (???)  
  <76301b3506f310fb454b58897c8d0a9f> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
  Versions/A/Resources/libTIFF.dylib
  0x96491000 - 0x9650dfeb  com.apple.audio.CoreAudio 3.1.0 (3.1)  
  <483e0d3879d52ba9ac10b4bcfb0728d6> /System/Library/Frameworks/ 
  CoreAudio.framework/Versions/A/CoreAudio
  0x96520000 - 0x96524fff  libGIF.dylib ??? (???)  
  <b8f61e346fa243a7138910bed3dcdb6b> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
  Versions/A/Resources/libGIF.dylib
  0x96525000 - 0x96525ffc  com.apple.audio.units.AudioUnit 1.5 (1.5) / 
  System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
  0x96526000 - 0x965d8ffb  libcrypto.0.9.7.dylib ??? (???)  
  <330b0e48e67faffc8c22dfc069ca7a47> /usr/lib/libcrypto.0.9.7.dylib
  0x965d9000 - 0x965e9ffc  com.apple.LangAnalysis 1.6.4 (1.6.4)  
  <cbeb17ab39f28351fe2ab5b82bf465bc> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/ 
  LangAnalysis.framework/Versions/A/LangAnalysis
  0x965ea000 - 0x9667dfff  com.apple.ink.framework 101.3 (86)  
  <bf3fa8927b4b8baae92381a976fd2079> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
  0x9667e000 - 0x966d7fff  libGLU.dylib ??? (???) /System/Library/ 
  Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
  0x966d8000 - 0x966d8ffd  com.apple.vecLib 3.4.2 (vecLib 3.4.2) /System/ 
  Library/Frameworks/vecLib.framework/Versions/A/vecLib
  0x9673f000 - 0x96a53fe2  com.apple.QuickTime 7.4.0 (92)  
  <0d674546d12c65dc5c33dca4c81c315b> /System/Library/Frameworks/ 
  QuickTime.framework/Versions/A/QuickTime
  0x96a54000 - 0x96ae0ff7  com.apple.LaunchServices 286.5 (286.5)  
  <33c3ae54abb276b61a99d4c764d883e2> /System/Library/Frameworks/ 
  CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/ 
  Versions/A/LaunchServices
  0x96ae1000 - 0x96b88feb  com.apple.QD 3.11.52 (???)  
  <c72bd7bd2ce12694c3640a731d1ad878> /System/Library/Frameworks/ 
  ApplicationServices.framework/Versions/A/Frameworks/QD.framework/ 
  Versions/A/QD
  0x96c16000 - 0x96f1efff  com.apple.HIToolbox 1.5.2 (???)  
  <7449d6f2da33ded6936243a92e307459> /System/Library/Frameworks/ 
  Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/ 
  HIToolbox
  0xba900000 - 0xba916fff  libJapaneseConverter.dylib ??? (???)  
  <1e92e348e73fc6fce723936c11e4b25c> /System/Library/CoreServices/ 
  Encodings/libJapaneseConverter.dylib
  0xbab00000 - 0xbab21fe2  libKoreanConverter.dylib ??? (???)  
  <2f3be93c8c0872958b681397ee09c9f1> /System/Library/CoreServices/ 
  Encodings/libKoreanConverter.dylib
  0xeab00000 - 0xeab0ffff  libConverter.dylib ??? (???) /System/Library/ 
  Printers/Libraries/libConverter.dylib
  0xfffe8000 - 0xfffebfff  libobjc.A.dylib ??? (???) /usr/lib/ 
  libobjc.A.dylib
  0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???) /usr/lib/ 
  libSystem.B.dylib


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


tkt_uuid: 220438ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: binding to <Destroy> does not work in Windows 95
comment:
  OriginalBugID: 1351 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-07'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-08-07'
  FixedInVersion: 8.2


  Name:
  Chris Alfeld

  Extensions:
  None

  CustomShell:
  No modification.

  ReproducibleScript:
  In windows 95 (4.00.950a)
  Run the script:

  proc HandleDestroy {} {tk_messageBox -message "Bang!"}
  bind . <Destroy> HandleDestroy

  and then click on the closs window button.  

  ObservedBehavior:
  Wish will page fault.
  I have another, more complex program, that generates two page faults.  My guess is that inside that code run inside a destroy handler isn't being run correctly.  The more complex program binds to destroy in order to prompt the user to save the file and involves tk_messageBox, tk_getSaveFile, file io, and extensive variable manipulation.

  DesiredBehavior:
  In the example script, a tk_messageBox saying "Bang!"



  This doesn't page fault with 8.2.  However, the user may want
  to use:
     wm protocol . WM_DELETE_WINDOW HandleDestroy
  if they want to intercept the destroy call for the [X] close
  window button on Windows. 
  -- 08/07/1999 hobbs


tkt_uuid: 487220ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Tk_GetNumMainWindows not as documented
comment:
  Tk_GetNumWindows man page says:

    Tk_GetNumMainWindows returns a count of the number
    of main windows currently open in the process.

  It does not do that; rather it returns the number
  of main windows in the current thread only.

  One effect of this difference can be seen running
  this script in tclsh (--enable-threads):

  # FILE: test.tcl
  package require Thread
  load /usr/local/lib/libtk8.3.so Tk
  set id [thread::create]
  thread::send $id {load {} Tk}
  thread::send $id {
          pack [label .l -text "I'm the created thread"]
  }
  # END FILE test.tcl

  Destroy the toplevel window that does not contain
  the label (the one from the main thread, not the
  created thread), and tclsh will exit.  This is
  because Tk_MainLoop() sees a count of zero main
  windows remaining and exits.


tkt_uuid: 220299ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: block insertion cursor of text widget
comment:
  OriginalBugID: 5217 Bug
  Version: 8.3
  SubmitDate: '2000-04-20'
  LastModified: '2000-04-20'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2811
  OS: All
  ClosedDate: '2000-04-20'


  Name:
  Boris Gontar

  ReproducibleScript:
  text .t -width 40 -height 20 -font fixed
  set w [font measure fixed 0]
  .t config -insertbackground red -insertwidth $w -insertofftime 0 -insertborderwidth 0
  pack .t

  ObservedBehavior:
  The block insertion cursor does not fit to character cells, especially in the beginning of line

  DesiredBehavior:
  insertion cursor should cover the character cell



  The text widget insertion cursor is just that - an insertion
  cursor.  We have another RFE for a true blockcursor in 2811. 
  -- 04/20/2000 hobbs


tkt_uuid: 1015859fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Allow to open non-existing files.
comment:
  Current set of file dialogs in Tk provides only dialogs
  for open of existing file and save to file with
  confirmation of overwriting file. 

  This is enough to implement standard File menu in the
  CUA compatible application, where New command and Open
  command are distinct. 

  But uses of file dialogs are not limiting to opening
  main document to work with. There are some auxiliary
  files which names can be configured in configuration
  dialog for example, and existense/non-existense of
  these files can be handled programmaticaly more clever
  way. At least user should be asked "File doesn't exist,
  create one with default values" rather than "File
  exist, it's ok to overwrite" if we deal with
  configuration file. 

  In some cases (such as log files) file could be
  silently created when it doesn't exist, and appended if
  it exist.

  Current tk_get*File model doesn't provide way to handle
  such situation.

  This patch adds option -allownonexistent to
  tk_getOpenFile, which allows it to return valid
  non-existent filename just as tk_getSaveFile does and
  let application to handle existense of file.

  Patch to the getOpenFile manpage is also included.

  This patch provides implementation only for Unix and
  Windows, since I don't have any Mac handy to debug it.


tkt_uuid: 723856ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: cannot use menu names with spaces
comment:
  Consider the following code:

    set W {.menu test}
    toplevel $W
    set menu "$W.menu"
    menu $menu -relief flat -bd 0
    $W configure -menu $menu
    $menu add cascade -label File -underline 0 -menu
  $menu.file
    menu $menu.file
    $menu.file add command -label Exit -command exit

  Note that if there is a space anywhere in the menu
  name, it causes the following error when posting the menu:

  invalid command name ".menu"
      while executing
  ".menu test.#menu test#menu.#menu test#menu#file post
  593 57"
      invoked from within
  "$menu postcascade active"
      (procedure "tk::MenuMotion" line 15)
      invoked from within
  "tk::MenuMotion .menu\ test.#menu\ test#menu 18 17 256"
      (command bound to event)

  I *believe* that the problem is in the use of
  Tcl_VarEval in line 1001 of tk8.4.2/generic/tkMenuDraw.c :

  result = Tcl_VarEval(interp, name, " post ", string,
  (char *) NULL);

  which does not account for spaces. I totally hacked the
  following replacement line:

  result = Tcl_VarEval(interp, "{", name, "} post ",
  string, (char *) NULL);

  which fixes the problem, but I'm sure there's a proper
  way to do this. Line 978 also suffers from this problem
  ("unpost"), and I expect there may be other places too.

  What's the correct way to fix this? (I'm trying to
  learn more C) Thanks!


tkt_uuid: 220685ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Destroying listbox crashes wish
comment:
  OriginalBugID: 4207 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-03-02'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4218
  OS: All
  FixedDate: '2000-03-02'
  FixedInVersion: 8.3.1


  Name: Andreas Gustafsson

  ReproducibleScript:
  listbox .l
  .l configure -cursor crosshair
  destroy .

  ObservedBehavior:
  Segmentation fault (core dumped)

  Program received signal SIGSEGV, Segmentation fault.
  0x48087653 in FreeResources (optionPtr=0x80c3470, objPtr=0x0, internalPtr=0x8076cb0 "\b", tkwin=0x0)
      at ./../generic/tkConfig.c:1597
  (gdb) where
  #0  0x48087653 in FreeResources (optionPtr=0x80c3470, objPtr=0x0, internalPtr=0x8076cb0 "\b", tkwin=0x0)
      at ./../generic/tkConfig.c:1597
  #1  0x48087455 in Tk_FreeConfigOptions (recordPtr=0x8076c00 "", optionTable=0x80c3400, tkwin=0x0)
      at ./../generic/tkConfig.c:1500
  #2  0x480cc3f9 in DestroyListbox (memPtr=0x8076c00 "") at ./../generic/tkListbox.c:1449
  #3  0x481c441d in Tcl_EventuallyFree (clientData=0x8076c00, freeProc=0x480cc2f0 <DestroyListbox>)
      at ./../generic/tclPreserve.c:313
  #4  0x480cd8f4 in ListboxEventProc (clientData=0x8076c00, eventPtr=0xefbfd248) at ./../generic/tkListbox.c:2365
  #5  0x48089fe6 in Tk_HandleEvent (eventPtr=0xefbfd248) at ./../generic/tkEvent.c:722
  #6  0x480a6b99 in Tk_DestroyWindow (tkwin=0x8076100) at ./../generic/tkWindow.c:1237
  #7  0x480a6ac7 in Tk_DestroyWindow (tkwin=0x804d900) at ./../generic/tkWindow.c:1180
  #8  0x48082d19 in Tk_DestroyObjCmd (clientData=0x804d900, interp=0x804e000, objc=2, objv=0xefbfd3f0)
      at ./../generic/tkCmds.c:420
  #9  0x481bc3f1 in EvalObjv (interp=0x804e000, objc=2, objv=0xefbfd3f0, command=0x8052cea "destroy .\n\n\n",
      length=12, flags=0) at ./../generic/tclParse.c:932
  #10 0x481bcc7c in Tcl_EvalEx (interp=0x804e000,
      script=0x8052cc0 "listbox .l\n.l configure -cursor crosshair\ndestroy .\n\n\n", numBytes=54, flags=0)
      at ./../generic/tclParse.c:1393
  #11 0x481b1a5b in Tcl_EvalFile (interp=0x804e000, fileName=0xefbfd83c "/x/itcl/crash3.tcl")
      at ./../generic/tclIOUtil.c:323
  #12 0x48099127 in Tk_MainEx (argc=1, argv=0xefbfd99c, appInitProc=0x8048a04 <Tcl_AppInit>, interp=0x804e000)
      at ./../generic/tkMain.c:231
  #13 0x80489f2 in main (argc=2, argv=0xefbfd998) at ./tkAppInit.c:77
  #14 0x80487b5 in ___start ()

  DesiredBehavior:
  Successful destruction of the window.



  Was due to ill handling of tkwin being set to NULL.  This is fixed
  for 8.3.1.  The work-around is to unconfig the cursor before
  destroying the listbox. 
  -- 03/02/2000 hobbs


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

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


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


tkt_uuid: 740568ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Duplicate
title: listbox.test failure
comment:
  platform: sparc solaris 8 sunblade 100
  compiler: sun c compiler
  source: 2003-05-19 cvs head from activestate ftp site
  tcl configured as --enable-shared --enable-symbols
  --enable-threads
  tk configured as --enable-shared --enable-symbols 

  make test results in

  listbox.test

  ==== listbox-13.3 ListboxScanTo procedure FAILED
  ==== Contents of test case:

      .l yview moveto 1.0
      .l xview moveto 1.0
      .l scan mark 10 20
      .l scan dragto 5 10
      update
      set x [list [.l xview] [.l yview]]
      .l scan dragto [expr 5+$width] [expr 10+$height]
      update
      lappend x [.l xview] [.l yview]

  ---- Result was:
  {0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}
  ---- Result should have been (exact matching):
  {0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}
  ==== listbox-13.3 FAILED


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

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

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



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

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

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


tkt_uuid: 473411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: None
title: load shared libraries (search path)
comment:
  Hi folks,

  can me anybody explain what is wrong?

  wohnivec@FortForest:~$
  wish8.4                                                               
  % load libpgtcl[info
  sharedlibextension]                                                     
  couldn't load file "libpgtcl.so":
  /home/wohnivec/libpgtcl.so: cannot open shared object
  file:
   není souborem ani
  adresá?em                                                                 
  % load /usr/local/pgsql/lib/libpgtcl[info
  sharedlibextension]                                
  %                                                                                            
  %
  exit                                                                                       
  wohnivec@FortForest:~$ cat
  /etc/ld.so.conf                                                   
  /usr/X11R6/lib/Xaw3d                                                                         
  /usr/X11R6/lib                                                                               
  /usr/lib/libc5-compat                                                                        
  /lib/libc5-compat                                                                            
  /usr/local/pgsql/lib                                                                         
  /usr/local/lib                                                                               
  wohnivec@FortForest:~$                                                                       

  When i load shared libs without full path its OK.
  When normaly "load libpgtcl[info sharedlibextension]",
  libraries are searched in mohe dirctory? CVS
  2001.10.19.

  Thank for comment.

  Michal, mmestan@iol.cz


tkt_uuid: 220799ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tcl/Tk doesn't trap the logoff/reboot/shutdown events on Win
comment:
  OriginalBugID: 1644 RFE
  Version: 8.0.4
  SubmitDate: '1999-03-26'
  LastModified: '2000-05-22'
  Severity: MED
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 789
  OS: Windows NT
  Machine: X86


  Name:
  Stephan Uyttebroeck

  DesiredBehavior:
      With the current Tcl/Tk for Windows it is impossible to perform some
      "cleanup" actions within your TK application (e.g. "Ask the user to save
      before going down") when a user triggered a logoff, reboot or shutdown
      event.
      The WM_QUERYENDSESSION and WM_ENDSESSION events aren't handled.
      



  Patch:
  *** tkWinX.cSat Oct 10 02:30:37 1998
  --- tkWinX.c_newFri Mar 12 11:25:00 1999
  ***************
  *** 50,55 ****
  --- 50,63 ----
        LPARAM lParam));
    static void GetTranslatedKey _ANSI_ARGS_((XKeyEvent *xkey));
    
  + 
  + static void (*fd_tcl_exit_callback_function_ptr)() = NULL;
  + 
  + void fd_tcl_register_exit_callback(void (*func_ptr)())   
  + {   
  +    fd_tcl_exit_callback_function_ptr = func_ptr;
  + }
  + 
    /*
     *----------------------------------------------------------------------
     *
  ***************
  *** 588,593 ****
  --- 596,615 ----
        Tk_PointerEvent(hwnd, (short) LOWORD(lParam),
        (short) HIWORD(lParam));
        return 1;
  + 
  +    case WM_QUERYENDSESSION: {       
  +        *resultPtr = 1;
  +        return 1;
  +    }
  + 
  +    case WM_ENDSESSION: {
  +        if ( wParam == TRUE ) {
  +            if ( fd_tcl_exit_callback_function_ptr != NULL ) {
  +                (*fd_tcl_exit_callback_function_ptr)();
  +            }
  +        } 
  +        return 1;
  +    }
    
    case WM_CLOSE:
    case WM_SETFOCUS:




  PatchFiles:
      win/tkWinX.c
      
      And, you have to modify 'winmain.c'
      
         extern void fd_tcl_register_exit_callback(void (*func_ptr)());
      
         static Tcl_Interp *YOUR_TCL_INTERPRETER;
      
         void fd_logoff_callback()
         {
            char * command = "YOUR_TCL_EXIT_PROC";
            Tcl_Obj * cmdObj = Tcl_NewStringObj(command, -1);
            if ( Tcl_GlobalEvalObj(YOUR_TCL_INTERPRETER, cmdObj) == TCL_ERROR
      ) {
               exit(1);
            }
         }
      
         ...
         /* Just before calling TkMain() */
         fd_tcl_register_exit_callback(fd_logoff_callback);
         ...
      
      YOUR_TCL_EXIT_PROC is the Tcl procedure that will get called when a
      logout, restart or shutdown occurs.
      
      





      To handle the WM_QUERYENDSESSION and WM_ENDSESSION events on Windows, we
      added an 'fd_tcl_register_exit_callback()' function to Tk to 
      register a C callback function.  
      
      When receiving a WM_ENDSESSION event with LogOff == TRUE (which will
      only
      happen when all running applications returned TRUE when receiving the 
      WM_QUERYENDSESSION event) the registered function will be called.
      
      This patch currently fits our needs, but it should be generalized.
      We added a 'hook' to call the registered callback function, but a better
      solution would be to provide a new Tcl builtin on Windows to register a
      Tcl logout procedure.
  --

  It'd be nice to get this to generically work, to allow Tcl code
  to execute.  A short foray into extending this failed to get it
  right. 
  -- 03/30/2000 hobbs
  789 notes that WM_SAVE_YOURSELF is an X-supported protocol that
  would be a good alias for WM_(QUERY)ENDSESSION.  There is also
  WM_TAKE_FOCUS. 
  -- 05/22/2000 hobbs


tkt_uuid: 1567354fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: None
title: [tk scaling] changes
comment:
  Mac OSX 10.4.7 dual 2.2GHz G5

  tk scaling 2.0
  puts [tk scaling]
  update
  puts [tk scaling]
  after 1000 {puts [tk scaling]}

  The first puts shows the correct scaling factor (1.99 etc).

  The second puts sometimes shows that the scaling factor
  changed back to 1.

  Usually, but not always, it has changed to 1 by the time
  the "after" fires.  Once it changes back to 1, if you reset
  it to something else, it won't change on its own again.

  Changing it to a delay of 100, it usually doesn't change
  if it didn't change after the update.

  As best I can tell, it didn't do this in 8.4.7, and it does
  do it in 8.4.13 and the current cvs head.  I have no idea
  if it does this on any other platform.

  I thought at first that it had something to do with the
  console window, but that was just affecting the timing
  and confusing me.

  sep@shout.net


tkt_uuid: 899246ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: Really bizarre [grid] behaviour
comment:
  Run the following short script and then resize the
  window vertically until there is not quite enough space
  to hold buttons b3 and b4.  At that point, b3 suddenly
  becomes much larger; click it to find out what size it
  is requesting at that point.  Isn't this wrong?!

  Problem occurs in 8.4.4 (on Win98) for sure, and is
  reported in both 8.4.5 and 8.5a0 by other people.

  button .b1 -text b1
  text .t2 -height 5
  button .b3 -text b3 -bg red -command {
     puts b3=([winfo reqw .b3]x[winfo reqh .b3])
  }
  button .b4 -text b4
  grid configure .b1 -row 0 -column 0 -sticky newsgrid
  configure .t2 -row 1 -column 0 -sticky news
  grid configure .b3 -row 2 -column 0 -sticky news
  grid configure .b4 -row 3 -column 0 -sticky news
  grid columnconfigure . 0 -weight 1
  grid rowconfigure . 0 -weight 1
  grid rowconfigure . 1 -weight 10000
  I'm not sure what's supposed to happen exactly in this
  case, but not what is happening for sure!


tkt_uuid: 539448ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tk to be ported OpenBeOS ? second try
comment:
  Hi! 
  I know that very few people here use BeOS even for 
  occasional fun, but BeOS and even more new OpenBeOS is 
  just reviving its renaisance. 
  Developmen of OpenBeOS at http://open- 
  beos.sourceforge.net/ is getting faster and faster. 

  Tcl is ported and maintained but there was never a Tk 
  port and this makes a number of great cross-platform 
  applications unaccessible to BeOS users. 

  Would anyone try porting Tk to BeOS? 
  Who would be interested in doing so? 
  Under which conditions? 

  GCC is available from GeekGadgets website... 
  free BeOS is available through www.Bebits.com 


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

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

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

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

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

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


tkt_uuid: 1069997fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: text.n - Unknown character: \"
comment:
  When building winhelp this warning is shown.
  Just needs the backslash removed from before the 
  quotes in the -tabs example added on 16-11-04.


tkt_uuid: 1060547fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Can't specify 'invisible' cursor in Tclet on Unix
comment:
  Logged from the Tcler's Chat:

  [21:28]
  <r4>
  hi, can anybody tell me if it is possible to create own
  cursor in tclet?
  [21:28]
  <r4>
  is it possible ?
  [21:28]
  dkf
  Don't think so. Cursors are messy.
  [21:28]
  dkf

  [21:28]
  snichols
  cursor? That sounds like a DBMS thing.
  [21:29]
  dkf
  snichols: This is a Tk widget thing   The -cursor option.
  [21:29]
  <r4>
  no no mouse cursor i meant
  [21:30]
  snichols
  ok. thanks. I was thinking of the cursor used to
  navigate a result set in a SQL stored procedure.
  [21:30]
  dkf
  Someone sometime needs to sit down and clean that mess
  out so you can define them without external files. But
  that's not been done yet. 
  [21:30]
  dkf
  Sorry.
  [21:32]
  <r4>

  [21:32]
  <r4>
  is any hack possible ?
  [21:32]
  dkf
  Tricky in a tclet
  [21:33]
  <r4>
  am working on some case tool and want to enable it as tclet
  [21:33]
  <r4>
  and mouse cursor is one of important things for this 
  [21:33]
  dgp possibly hasn't really left.
  [21:33]
  dkf
  The most common hack is to hide the cursor and use a
  shaped tiny window
  [21:33]
  <r4>
  and what about replacing data ? in a loaded cursor ?
  could it be done ?
  [21:33]
  dkf
  But you need an extension to do that and it definitely
  won't work in a tclet.
  [21:33]
  <r4>
  yop
  [21:33]
  <r4>
  but how to hide cursor ?
  [21:34]
  dkf
  Try setting it to 'none' first 
  [21:34]
  bschwarz
  -cursor no
  [21:34]
  <r4>
  in unix? (no 'no' cursor defined )
  [21:35]
  dgp saunters in.
  [21:35]
  dkf
  IMO that's a bug (even though it's been that way for a
  long time)
  [21:35]
  bschwarz
  windows
  [21:35]
  <r4>
  none doesnt work too ..
  [21:35]
  <r4>
  m$ sukz 
  [21:36]
  bschwarz
  maybe -cursor {} ?
  [21:36]
  dkf
  Actually MS is worse than that. 
  [21:36]
  <r4>
  i found a trick how to do none cursor in nix, but it
  was through loading empty image .. so nothing for tclet 
  [21:36]
  <r4>
  hehe
  [21:36]
  <r4>
  no way -cursor {} is the default one
  [21:37]
  jenglish
  There's a bug in the manpage:
  [21:37]
  dkf
  Tclet's are a good reason why the current behaviour is
  wrong and insufficient.
  [21:37]
  jenglish
  Under PORTABILITY ISSUES - Windows - "The *no* cursor
  can be specified to eliminate the cursor."
  [21:37]
  <r4>
  ??
  [21:37]
  jenglish
  Which is just plain wrong.  The "no" cursor is a
  slashed circle (meaning "No!")
  [21:37]
  dkf
  Filing a bug...
  [21:38]
  bschwarz
  yeah, it doesn't get rid of it
  [21:38]
  <r4>
  sorry am a quite new in tcl , am c++ native speaker 
  [21:38]
  dkf
  That's OK.
  [21:38]
  dkf
  You've come across a grotty spot where things aren't
  good enough.
  [21:38]
  bschwarz
  couldn't he somehow override the cursor image within
  his Tcl script thought?
  [21:39]
  jenglish
  -cursor {},which is the default, means "inherit the
  cursor from the parent window".


tkt_uuid: 220261ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: toplevels pop up in back of main window
comment:
  OriginalBugID: 3801 Bug
  Version: 8.2.1
  SubmitDate: '1999-12-07'
  LastModified: '1999-12-09'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  ClosedDate: '1999-12-09'


  Name:
  Peter Nye

  Comments:
  If there's a workaround, I'd like to know it!

  ReproducibleScript:
  # Create dialog if id doesn't exist already, otherwise pop it up.
  proc showDialog {} {
     if {![winfo exists .t]} {
        toplevel .t
        label .t.lab -text "Dialog"
        button .t.b -text ok -command "wm withdraw .t"
        pack .t.lab .t.b
        }
     wm deiconify .t
  }

  # Main menu
  menubutton .1 -text {File}
  pack .1 
  .1 config -menu .1.2
  menu .1.2 
  .1.2 add command -label {Show Dialog} -command {showDialog}

  ObservedBehavior:
  The first time you pop up the new toplevel, it comes up in front of the main window.  When you pop it up again (from the menu), it comes up behind the main window.  (Only on the Mac.)

  DesiredBehavior:
  It should come up on top every time.



  Add 'raise .t' after the deiconify.  It is likely that the other
  toplevel is moving higher in the Z order when the other gets
  withdrawn, and raise will correct that. 
  -- 12/09/1999 hobbs


tkt_uuid: 1449027fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: None
title: What does $canvas lower do when 'belowThis' not specified?
comment:
  There seems to be some lacking documentation for what happens if 
  the 'belowThis' parameter, which is marked as optional, is not given to 
  the 'lower' command.


tkt_uuid: 220778ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 5 Medium
foundin: obsolete: 8.0.3
resolution: Wont Fix
title: Tk_Uid memory leaks
comment:
  OriginalBugID: 751 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-22'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Assigned
  Submitter: admin
  ChangedBy: ericm
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  In his paper at the Tcl/Tk Conference, Kevin Kenny talked about the
  memory leaks in Tk caused by the Tk_Uid mechanism.  This mechanism
  was just a bad idea, and it should be removed from Tk.  I don't think
  it will be very hard to replace with something that eliminates the
  potential memory leaks, and I can give more details when the time
  comes.  I'd consider this a moderately high priority bug, maybe
  important enough to fix in 8.1 if time permits.

    -John-

  Tk_Uid doesn't seem to be quite as bad as all that.  When creating lots of widgets, for example, I see very good hit rates on the Tk_Uid's, meaning that I am saving memory and avoiding alloc'ing new strings (although it may be possible to avoid Tk_Uid and avoid alloc'ing new strings too, at the expense of more memory).

  As a test, I tried replacing Tk_GetUid with a "strdup", basically short-circuiting the Uid stuff and just getting a copy of the string back.  This provided no speed up to widget creation.

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 2495740fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: new test failure
comment:
  ==== button-5.5 ConfigureButton - image handling FAILED
  ==== Contents of test case:

      button .b -image image1
      image delete image1
      .b configure -image image2
      image names

  ---- Result was:
  image2 ::tk::dialog::error::image::stop
  ---- Result should have been (exact matching):
  image2
  ==== button-5.5 FAILED


tkt_uuid: 1245475fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: None
title: Using text and image on menu entry - extra space added.
comment:
  Hi,
  When giving a menu entry both text and an image,
  significant extra space (~20 pixels) is added to the
  right, eg with

  menu .m
  .m add command -label entry -image entry -compound center

  I think the problem is with compound, because when
  giving a button image and text and using -compound
  center, you get an extra pixel border all around the
  button.

  Tom


tkt_uuid: 2609839fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: None
title: tk tutorial similar in nature to the tcl tutorial
comment:
  I would like to request that the Tk experts of the community consider working together to create a Tk tutorial of similar nature to that of the tcl tutorial available at http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html . This is something that would be very useful.


tkt_uuid: 1244178fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 4
foundin: obsolete: 8.4.9
resolution: None
title: TkAqua: command-n doesn\'t work when minimized
comment:
  Possibly belongs in events, but: the following code
  sets up a menu and binding for command-n to open a new
  window.  It works if the . toplevel is visible, but if
  you minimize or withdraw it then doesn't.  Pressing
  command-n just causes the background of the "Window"
  menu to flash, and that's it.

  ---

  set unique 0

  proc top {} {
      global unique
      incr unique
      toplevel .t$unique
  }

  menu .m
  .m add cascade -label "Window" -menu .m.window
  menu .m.window
  .m.window add command -label "New" \
      -accelerator "Command-N" -command top

  . config -menu .m

  bind . <Command-n> top


tkt_uuid: 220765ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: file dialog doesn't work with spaces or non-list directory names
comment:
  OriginalBugID: 6365 Bug
  Version: 8.4a1
  SubmitDate: '2000-10-16'
  LastModified: '2000-10-18'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux-Red Hat
  OSVersion: redhat 6.2
  FixedDate: '2000-10-18'
  FixedInVersion: 8.4a2


  Name:

  Vince Darley


  CVS:

  latest


  ReproducibleScript:

  mkdir "{aa"


  Now use tk_getOpenFile to try to go inside that directory


  or, mkdir "space name", and try again.


  ObservedBehavior:

  Either an invalid file is selected ('space' above), or an error is thrown due to a bad list ('{aa' above)


  Patch:

  tkfbox.tcl needs to change:


  proc ::tk::dialog::file::OkCmd {w} {

      upvar ::tk::dialog::file::[winfo name $w] data


      set text {}

      foreach item [tkIconList_Curselection $data(icons)] {

  lappend text [tkIconList_Get $data(icons) $item]

      }


      if {[llength $text] && !$data(-multiple)} {

  set text [lindex $text 0]

  set file [::tk::dialog::file::JoinFile $data(selectPath) $text]

  if {[file isdirectory $file]} {

      ::tk::dialog::file::ListInvoke $w $text

  ...


  so the last line is


      ::tk::dialog::file::ListInvoke $w [list $text]


  PatchFiles:

  tkfbox.tcl




  Nice job finding and fixing this bug.  I've applied your patch, and the fix will go out with 8.4a2.

     Eric Melski                            The Other Tcl Guy
     ericm at ajubasolutions.com            Ajuba Solutions

  -- 10/18/2000 ericm


tkt_uuid: 2356057fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.6a4
resolution: Fixed
title: rotated text with underlined char: underline drawn wrongly
comment:
  sample:

  pack [canvas .c]
  set inr [.c create text 150 100 -text "foo" \
           -font {Helvetica 72} \
           -underline 1 ]
  set tm 100; set d 1
  set x {
     .c itemconf $inr -angle \
        [expr {[.c itemcget $inr -angle] + $d}]
     after $tm $x
  }
  eval $x


  The lower edge of the underline bar rotates 
  in the other direction relativ to the correctly
  placed upper edge. Seemingly just a sign-bug 
  on the angle.

  Also visible in this example: at non-rectangular
  positions, the fill is not entirely solid, but
  this may depend on my config (--enable-xft)


tkt_uuid: 220674ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.2.3
resolution: Fixed
title: wm geometry $toplevel +x+y does not work on iconified window
comment:
  OriginalBugID: 4134 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-07'
  LastModified: '2000-02-07'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  FixedDate: '2000-02-07'
  FixedInVersion: 8.3b2


  Name:
  Stefan Jäger

  ReproducibleScript:
  toplevel .t
  wm geometry .t +100+100
  wm iconify .t
  wm geometry .t +200+200
  wm deiconify .t
  wm geometry .t

  ObservedBehavior:
  .t is still at +100+100

  DesiredBehavior:
  .t at +200+200



  This is already fixed for 8.3b2. 
  -- 02/07/2000 hobbs


tkt_uuid: 3569637fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.12
resolution: Works For Me
title: Crash under Mac OS X
comment:
  I'm getting crash of the application while a call to [update idletasks] under Mac OS X 10.6.
  I've compiled Tcl and Tk by myself from sources - version 8.5.12. Itcl and Itk got from ActiveTcl.
  Note, that the application is quiet big and it's hard to tell what's in the events queue that causes the crash.

  To reproduce the problem you can download MacOSX boundle from: http://sqlitestudio.one.pl/files/free/unstable/osx/sqlitestudio-2.0.902.zip
  To invoke an error create sample database, then create table and then double-click on the table to open it. Then the app crashes.

  Here's a crash stack:
  Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
  0   Tk                            0x0b0cbb2d TkpSetMainMenubar + 2715
  1   Tk                            0x0b04228c TkCreateFrame + 21118
  2   Tk                            0x0b0179b9 TkFontPkgFree + 245
  3   Tk                            0x0b0179c5 TkFontPkgFree + 257
  4   Tcl                           0x0a09f2d8 TclServiceIdle + 61
  5   Tcl                           0x0a081233 Tcl_DoOneEvent + 342
  6   Tk                            0x0b00dd3a TkGetDisplayOf + 424
  7   Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  8   Tcl                           0x0a04e66d TclStackAlloc + 7349
  9   Tcl                           0x0a057b42 TclStackAlloc + 45450
  10  Tcl                           0x0a0133ed TclEvalObjEx + 877
  11  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  12  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  13  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  14  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  15  Tcl                           0x0a04e66d TclStackAlloc + 7349
  16  Tcl                           0x0a057b42 TclStackAlloc + 45450
  17  Tcl                           0x0a0133ed TclEvalObjEx + 877
  18  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  19  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  20  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  21  libitcl3.4.dylib              0x000eaae2 Itcl_EvalArgs + 425
  22  libitcl3.4.dylib              0x000e7b1d Itcl_HandleInstance + 553
  23  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  24  Tcl                           0x0a04e66d TclStackAlloc + 7349
  25  Tcl                           0x0a057b42 TclStackAlloc + 45450
  26  Tcl                           0x0a0133ed TclEvalObjEx + 877
  27  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  28  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  29  libitcl3.4.dylib              0x000e5420 Itcl_InvokeMethodIfExists + 187
  30  libitcl3.4.dylib              0x000e871e Itcl_CreateObject + 1430
  31  libitcl3.4.dylib              0x000dd69e Itcl_HandleClass + 1101
  32  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  33  Tcl                           0x0a04e66d TclStackAlloc + 7349
  34  Tcl                           0x0a057b42 TclStackAlloc + 45450
  35  Tcl                           0x0a0133ed TclEvalObjEx + 877
  36  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  37  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  38  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  39  libitcl3.4.dylib              0x000eaae2 Itcl_EvalArgs + 425
  40  libitcl3.4.dylib              0x000e7b1d Itcl_HandleInstance + 553
  41  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  42  Tcl                           0x0a04e66d TclStackAlloc + 7349
  43  Tcl                           0x0a057b42 TclStackAlloc + 45450
  44  Tcl                           0x0a0133ed TclEvalObjEx + 877
  45  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  46  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  47  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  48  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  49  Tcl                           0x0a04e66d TclStackAlloc + 7349
  50  Tcl                           0x0a057b42 TclStackAlloc + 45450
  51  Tcl                           0x0a0133ed TclEvalObjEx + 877
  52  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  53  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  54  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  55  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  56  Tcl                           0x0a04e66d TclStackAlloc + 7349
  57  Tcl                           0x0a057b42 TclStackAlloc + 45450
  58  Tcl                           0x0a0133ed TclEvalObjEx + 877
  59  Tcl                           0x0a0134f9 Tcl_EvalObjEx + 47
  60  libitcl3.4.dylib              0x000e526d Itcl_EvalMemberCode + 647
  61  libitcl3.4.dylib              0x000e6371 Itcl_ExecMethod + 403
  62  libitcl3.4.dylib              0x000eaae2 Itcl_EvalArgs + 425
  63  libitcl3.4.dylib              0x000e7b1d Itcl_HandleInstance + 553
  64  Tcl                           0x0a011f26 Tcl_CreateInterp + 4965
  65  Tcl                           0x0a012b22 Tcl_CreateInterp + 8033
  66  Tcl                           0x0a012e5a Tcl_EvalEx + 58
  67  Tk                            0x0b00bb24 Tk_BindEvent + 4972
  68  Tk                            0x0b00f20b TkBindEventProc + 295
  69  Tk                            0x0b016638 Tk_HandleEvent + 1523
  70  Tk                            0x0b016707 Tk_HandleEvent + 1730
  71  Tcl                           0x0a080f2f Tcl_ServiceEvent + 160
  72  Tcl                           0x0a081222 Tcl_DoOneEvent + 325
  73  Tk                            0x0b015e20 Tk_MainLoop + 37
  74  Tk                            0x0b023f56 Tk_MainEx + 2041
  75  Wish                          0x00004610 0x1000 + 13840
  76  Wish                          0x0000456d 0x1000 + 13677


tkt_uuid: 487610ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Fail to handle image size limitaion.
comment:
  There is a 16BM limitation in creating a bitmap with 
  Windows 3.1 and 9x. The current Photo Image (in all 
  tk's versions) does not check the returned pixmap from 
  Tk_GetBitmap.  In the function ImgPhotoInstanceSetSize 
  of tkImgPhoto.c, if the bitmap is larger than 16MB, 
  Tk_GetBitmap will return a None.  But this function 
  does not check the newPixmap.  Therefore, a null 
  pixmap may be used later in display which will crash 
  the system.

  In addition, the TkPutImage in tkWinDraw.c does not 
  check any newly created bitmap before copying the 
  bitmap content.  In case there is a null bitmap due to 
  the limitation, the wish program may crash.


tkt_uuid: 220891ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Composing characters in Unicode need support
comment:
  OriginalBugID: 4073 RFE
  Version: 8.2
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-31'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux


  Name:
  Raphael Finkel

  Comments:
  It would be great if Tk supported the full BIDI (bidirectional) algorithm;
  character composition is only one step toward this goal.

  DesiredBehavior:
  There are Unicode combinations formed from stems and composing characters.
  There is, however, no way in Tk in either a text or a canvas to compose
  two Unicode characters.  I would be satisfied to have simple bitwise OR of
  the two glyphs, but even that is not possible so far as I can see.


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

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

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


tkt_uuid: 220917ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Invalid
title: stack trace from motion binding
comment:
  OriginalBugID: 5663 Bug
  Version: 2.0b10
  SubmitDate: '2000-05-23'
  LastModified: '2000-09-06'
  Severity: SER
  Status: UnAssn
  Submitter: shawn
  ChangedBy: hobbs
  OS: SunOS


  I have no id ea how to repruduce this 
  Mouse movement - but I really dont know where the motion was 


  can't read "tkPriv(element)": no such variable
      while executing
  "string equal "entry" $tkPriv(element)"
      (procedure "::tk::spinbox::Motion" line 5)
      invoked from within
  "::tk::spinbox::Motion .post.frame.repeatFrame.delay 24 12
  "
      (command bound to event)

  Hmmm... 
  -- 05/23/2000 redman

  Sorry to punt on this, but this is coming from within the spinbox widget's
  bindings and functions (I believe).  I think Jeff will be better suited
  to look at this.

  Jeff, if you think it is something I am doing wrong (how I am setting
  up the bindings etc.) let me know.  Since the bug report isn't very
  specific, hopefully you will be able to catch this one from inspection
  of the code and the stack trace.

  If I can do anything to help, let me know.

  --Dan 
  -- 05/23/2000 kuchler

  This has a simple work-around, but I don't know if it's worth
  putting into the vu tag for Ajuba2.
  --
  This should apply to vu and the 8.4 spinbox.
  -- Jeff (via Scott)

  Hard to reproduce, fix in 2.1. 
  -- 05/30/2000 redman

  Let it wait until 3.0.
   
  -- 07/27/2000 redman 
  -- 09/06/2000 hobbs


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


tkt_uuid: 220172ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 24. Relief
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_NameOfRelief API
comment:
  OriginalBugID: 1879 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




  04/28/1999 14:25 - kenj - Already documented in GetRelief.3. It's in there.


tkt_uuid: 694534ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Error in makefile.vc (typo?)
comment:
  These lines:

  !if "$(OS)" == "Windows_NT"  || "$(MSVCDIR)" 
  == "IDE"
  $(TKTEST) $(ROOT)/tests/all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !else
  $(TKTEST) $(ROOT)/tests/all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !endif

  Should read like this instead (notice the use of 
  backslashes instead of slashes):

  !if "$(OS)" == "Windows_NT"  || "$(MSVCDIR)" 
  == "IDE"
  $(TKTEST) $(ROOT)\tests\all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !else
  $(TKTEST) $(ROOT)\tests\all.tcl 
  $(TESTFLAGS) | $(CAT32)
  !endif

  The tests will NOT run at all when slashes are used 
  (at least in my environment).

  JJM


tkt_uuid: 817096ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menu text drawing inconsistency
comment:
  Disabled menu entries display its label with disabled 
  foreground and its accelerator etched out.

  Also more generally, should text of disabled label / 
  button ... be displayed etched out ? for all platform ?


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

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


tkt_uuid: 2824538fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: None
resolution: Remind
title: Need to track opaque content in textured windows
comment:
  A toplevel Mac window with the "metal" style applied (via tk::unsupported::MacWindowStyle) should be not be dragabble from a widget with an opaque background, just a transparent background. However, it is draggable from any region on the window. Here is a sample script: 

  toplevel .f

  tk::unsupported::MacWindowStyle style .f document { metal toolbarButton  closeBox collapseBox resizable standardDocument}

  label .f.t -text "Should  be able to drag here" -bg systemTransparent
  pack .f.t -side top -fill both -expand yes

  label .f.b -text "Should not be able to drag here" -bg white
  pack .f.b -side bottom -fill both -expand yes


tkt_uuid: 1576871fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Invalid
title: Option -compound not documented
comment:
  The widgets 'checkbutton', and 'radiobutton' accept the
  option -compound, per the sources, but are not
  documented for them. for the related widgets 'button'
  and 'label' the option is documented.


tkt_uuid: 220428ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: Wrong modifiers detected on NT keyboards
comment:
  OriginalBugID: 1160 Bug
  Version: 8.0.3
  SubmitDate: '1999-02-02'
  LastModified: '2000-04-18'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 947 5088 5144
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '2000-04-18'
  FixedInVersion: 8.3.1


  Name:
  Marco R. Gazzetta

  Extensions:
  None

  CustomShell:
  None

  ReproducibleScript:
  pack [ canvas .c ]
  foreach Mod {Shift Control Alt M1 M2 M3 M4 M5} {
  bind .c <$Mod-Button-1> " puts $Mod "
  }

  ObservedBehavior:
  depending on the keyboard, wrong modifier keys are detected. On my HP Kayak keyboard, for instance, the mapping is:
  Shift    -> Shift
  Control    -> Control
  Alt    -> M2
  NumLock    -> M1
  ScrollLock -> M3

  DesiredBehavior:
  Modifier mapping should be correct



  NumLock and ScrollLock are not really modifiers, and should not be used as such; however, Tk understands additional modifiers past Shift, Control, and Alt (namely M1-M5).  As a convenience, we provided mappings for some of them.  These are arbitrary, of course -- M1 for NumLock, M3 for ScrollLock.  I don't know what you expect to see when you press NumLock + Button1, but the existing behavior seems reasonable.

  There was a problem with the Alt modifier and button presses on Windows -- it just didn't work (at least not in 8.3.0).  I corrected this, and the fix will go out with 8.3.1.  I was unable to determine how to prevent Tk from interpreting Alt as M2 for Button presses, so if you have both an <Alt-Button-1> and a <M2-Button-1> binding, the most recently declared one will be matched and executed.  I think this is better than the original 8.3.0 behavior, though.

  - eric

  -- 04/18/2000 ericm


tkt_uuid: 830667ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: final: 8.3.5
resolution: Duplicate
title: umask 027 issue
comment:
  When umask is set to 027 during compilation (may be 022 during make install), the resulting /usr/bin/wish8.3 has incorrect privileges rwxr-x---

  Dirty fix: Write "set umask to 022 during configure, make and make install" into suitable place into unix/README


tkt_uuid: 1777362fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: Double-click bug in text widget with hyphen in name
comment:
  Using Tclkit 8.5a6, double-clicking a word in a text widget sometimes raises an error.

  pack [text .text-widget]
  .text-widget insert end "This is a test"

  <double click in the widget>

  bad text index "tk::anchor.text-widget + 1c"
  bad text index "tk::anchor.text-widget + 1c"
      while executing
  "$w compare $cur > $last"
      (procedure "tk::TextSelectTo" line 35)
      invoked from within
  "tk::TextSelectTo .text-widget 46 9"
      (command bound to event)

  This doesn't seem to happen in ActiveTcl 8.4.9. The mark is valid, as

  .text-widget index tk::anchor.text-widget

  returns correctly, but using any modifiers throws an error. From my minimal testing, this seems to only happen if the widget name contains a hyphen character; if you repeat with a text widget called .text_widget it works fine.


tkt_uuid: 220860ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: unite -bitmap and -image
comment:
  OriginalBugID: 2579 RFE
  Version: 8.0.5
  SubmitDate: '1999-08-18'
  LastModified: '1999-11-03'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other


  Name:Andreas Leitgeb

  CustomShell:
  workaround:

  DesiredBehavior:
  Doesn't anyone else find it annoying, that an 
      bitmap-image cannot be used for tk_dialog ?
      tk_dialog passes the bitmap-arg to a label's
      -bitmap option.  -bitmap can only be the 
      predefined bitmaps or pointers to bitmap-files,
      but not images, even if these are bitmaps, too.
      
      I'd request, that either bitmap-image-names be legal 
      arguments for Tk_GetBitmap() (making the -image obsolete 
      in most cases (except for compatibility-issues)) or  
      that there exists an script-API to create bitmaps from
      image-bitmaps(or files), such as a "bitmap"-command.


tkt_uuid: 220271ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Invalid
title: Pop-up windows don't pop up for sub-widgets
comment:
  OriginalBugID: 4059 Bug
  Version: 8.2
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-25'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  ClosedDate: '2000-01-25'


  Name: Les Hatton

  ReproducibleScript:
  Tried to implement a balloon help, (full example sent to Angie).  Works fine with TclPro1.2 shipped release for Linux.  Mostly works for Windows except that help window pops up in top left instead of relative to widget requesting help.  Works fine with TclPro1.3 (with shipped Tcl/Tk) for Linux but on Windows the help only pops up for the top-level widget (but still in top left) and doesn't pop up at all for sub-widgets.

  DesiredBehavior:
  Consistent behaviour between Linux and Windows as occurred with TclPro1.2.



  There are some known problems with geometry management for
  hidden toplevels that cause problems when attempting trivial
  tasks like balloon help.  Most problems were resolved by 8.2.1
  and all are fixed by 8.3b1.  For valid work-arounds for earlier
  version of tk, email hobbs @ scriptics. 
  -- 01/25/2000 hobbs


tkt_uuid: 673722ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 4
foundin: obsolete: 8.4.1
resolution: Fixed
title: Button width computation in standard dialogs
comment:
  The standard dialogs (tk_get*File, etc.) only pay
  attention to the button -text when computing the
  maximum button widths.   If buttons are also given an
  -image (say via the option database), the layout is
  miscomputed.

  For example:
  ----
  # Quick-and-dirty "theme" support: (Requires Tk 8.4+)
  image create photo check -data
  {R0lGODlhEAAQAIIAAPwCBMT+xATCBASCBARCBAQCBEQCBAAA
  ACH5BAEAAAAALAAAAAAQABAAAAM2CLrc/itAF8RkdVyVye4FpzUgJwijORCGUhDDOZbLG6Nd2xjwibIQ
  2y80sRGIl4IBuWk6Af4EACH+aENyZWF0ZWQgYnkgQk1QVG9HSUYgUHJvIHZlcnNpb24gMi41DQqpIERl
  dmVsQ29yIDE5OTcsMTk5OC4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCmh0dHA6Ly93d3cuZGV2ZWxjb3Iu
  Y29tADs=}

  option add *ok.image check
  option add *ok.compound left

  pack [button .ok -text OK];# This does the Right Thing
  tk_getOpenFile;# [Open] button is too small!
  ---


tkt_uuid: 778511ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Elide text scrolling doesn't work
comment:
  when trying to scroll elide text the scrollbar thumb 
  is going berserk. 

  example: 

  text .t -yscrollcommand ".yscroll set" -wrap none 
  scrollbar .yscroll -command ".t yview" -orient vert 

  pack .yscroll -side right -fill y 
  pack .t -fill both -expand true 

  for {set i 0} {$i < 100} {incr i} { 
  .t insert end "Testing 123...\n" ELIDE 
  } 

  for {set i 0} {$i < 100} {incr i} { 
  .t insert end "Testing 123...\n" 
  } 

  .t tag configure ELIDE -elide 1   


tkt_uuid: 795717ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: tk_getOpenFile foreground color
comment:
  The tk_getOpenFile ignores foreground colors in the
  option database. More precisely, canvas widgets do not
  have a -foreground color option which could be used by
  text items' -fill option.

  Example:
  % option add *Canvas.background black
  % option add *foreground white
  % tk_getOpenFile

  now shows black text on a black background. Not very
  helpful. Here's a small patch to tkfbox.tcl (8.4.4)
  which remedies the situation:

  > diff tkfbox.tcl tkfbox.tcl.0
  242,245d241
  <     set fg [option get $data(canvas) foreground
  Foreground]
  <     if { ![string length $fg] } { set fg black }
  <     set data(fill) $fg
  <
  345d340
  <     set fg [option get $data(canvas) foreground
  Foreground]
  350d344
  <               -fill $data(fill) \


tkt_uuid: 1763744fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Duplicate
title: meunubutton cascades don't post
comment:
  In the latest release cascade menus don't post when called from a menubutton

  example:
  toplevel .t
  pack [menubutton .t.mb -menu .t.mb.m1]
  menu .t.mb.m1
  .t.mb.m1 add checkbutton -label 1
  .t.mb.m1 add cascade -label 2 -menu .t.mb.m1.m2
  menu .t.mb.m1.m2
  .t.mb.m1.m2 add checkbutton -label a
  .t.mb.m1.m2 add checkbutton -label b

  I have only tested this in OSX Aqua.


tkt_uuid: 1375069fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Fix for Bug 1374935
comment:
  Index: tkTextTag.c
  =============================================
  ======================
  RCS file: /cvsroot/tktoolkit/tk/generic/tkTextTag.c,v
  retrieving revision 1.22
  diff -p -r1.22 tkTextTag.c
  *** tkTextTag.c 17 Nov 2005 10:57:35 -0000      1.22
  --- tkTextTag.c 7 Dec 2005 06:58:20 -0000
  *************** TkTextTagCmd(
  *** 623,630 ****
               * The 'sel' tag is not in the hash table.
               */
    
  !           arrayPtr[i] = textPtr->selTagPtr;
  !           arraySize = textPtr->sharedTextPtr->numTags;
          } else {
              if (TkTextGetObjIndex(interp, textPtr, objv[3],
                      &index1) != TCL_OK) {
  --- 623,630 ----
               * The 'sel' tag is not in the hash table.
               */
    
  !           arrayPtr[i++] = textPtr->selTagPtr;
  !           arraySize = i; /*textPtr->sharedTextPtr->numTags;*/
          } else {
              if (TkTextGetObjIndex(interp, textPtr, objv[3],
                      &index1) != TCL_OK) {


tkt_uuid: 680884ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Accepted
title: menubutton scripts are confused about their owning menu
comment:
  The attached script shows a bug in the menubutton 
  scripts, when the act of creating a menu takes 
  some time, and the user inadvertently moves the 
  mouse onto a different menu button. Tk tries to 
  *post* the menu for the other menubutton, but that 
  doesn't exist!

  Given we are in the middle of executing bindings 
  for the first button, there is no reason for Tk to try 
  to do something on the other.

  # Now click on menu 'one', but while you 
  # are waiting for it to popup, move the 
  # mouse over menu 'two'.  
  # 
  # You will get the following bgerror:
  # 
  # invalid command name ".two.m"
  #     while executing
  # "$menu cget -type"
  #     (procedure "MbPost" line 13)
  #     invoked from within
  # "MbPost $new $rootx $rooty"
  #     (procedure "tk::MbMotion" line 14)
  #     invoked from within
  # "tk::MbMotion .one down 95 93
  # "
  #     (command bound to event)


tkt_uuid: 456879ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: obsolete: 8.3
resolution: None
title: Problem compiling on a Cray
comment:
  I had a problem with tk routine tkUnixFont.c at line
  41.
  #define     FONTMAP_PAGES \
         (1 << (sizeof(Tcl_UniChar)*8 - FONTMAP_SHIFT))
  There is an implicit assumption that
  sizeof(Tcl_UniChar) is 2 bytes.
  On a Cray it is 8 bytes, so that  FONTMAP_PAGES becomes
  a huge
  number, which is used to define the size of  an array
  in structure  FontFamily.
  My work around was to hardcode a 2 for
  sizeof(Tcl_UniChar).

  I believe this problem is in the 8.4 versions also.


tkt_uuid: 220637ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: inconsistent fonts on the Mac
comment:
  OriginalBugID: 3884 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-15'
  LastModified: '1999-12-16'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Name:
  Peter Nye

  ReproducibleScript:
  button .b -text "The quick brown fox jumped over the lazy dog" -font lucida
  pack .b

  ObservedBehavior:
  The letters a ,e and q  appear to be coming from the wrong font in the above case, and also
  in the console window.  It's true for every font I tried, but is especially pronounced in lucida.
  This is flor the out-of-the-box 8.2.2 release.

  For 8.2.1, ther e is the same problem, but with different letters (q o n x p z y).



  This is already fixed in the upcoming 8.3b1 release for the Mac,
  with a community contributed patch.  If the user requires the
  fix, please respond (8.3b1 out before xmas). 
  -- 12/16/1999 hobbs


tkt_uuid: 220326ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.3.2
resolution: Invalid
title: X server hangs when doing make test
comment:
  OriginalBugID: 6325 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-29'
  LastModified: '2000-10-18'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Digital Unix
  OSVersion: 4.0f + patch (duv40f0004)
  Machine: DMCC - Alpha
  ClosedDate: '2000-10-18'


  Name:
  Tupone Alfredo

  Comments:
  I think the X server shipped with the O.S. is bugged

  ReproducibleScript:
  Just run make test!
  The last line is 
  unixMenu

  ObservedBehavior:
  When the script create a menu with the font "Helvectica 72" (I thing is a typo), and try that => tkTearOffMenu .m1 40 40

  the X server stays in a dead loop (consuming CPU, 97-98 %) and the only way to resume it is to kill the X server from another terminal.



  From comp.lang.tcl:

  Andreas Leitgeb wrote:

  > >ObservedBehavior:
  > >When the script create a menu with the font "Helvectica 72"
  > > (I thing is a typo), and try that => tkTearOffMenu .m1 40 40
  >
  > 72 is indeed quite large, but not too large.
  >
  > I once used large fonts in Tcl/Tk (size 256 !), and it took my X-server
  > almost a minute to display them. (until that it was not responsive, and
  > likely ate a lot of CPU-percentage ...)
  >
  > how long did you wait, before you killed it, and how fast is your machine ?

  I wait a long time, before killing the X-Server.  My machine is an Alpha 500 Mhz.  I saw that the procedure consuming that large amount of CPU are the one related to the graphic board - Elsa 8 Mb.  I have another machine with a different kind of board, a PowerStorm 4D20T, and all seems ok.

                                                                      Alfredo
  ---------------

  This does sound like a buggy X Server.  Contact the OS vendor to report the bug.

     Eric Melski                            The Other Tcl Guy
     ericm at ajubasolutions.com            Ajuba Solutions

  -- 10/18/2000 ericm


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: 1096074fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 7 High
foundin: obsolete: 8.5a3
resolution: None
title: Wish crashes if a wrong value is used as a container id
comment:
  There is no protocol for embedded window 
  attachment, i.e., any number used as a value for -
  use option will be accepted in general.  That may 
  result in unexpected crach/panic if an invalid id is 
  supplied.

  Following is one of examples with Tk 8.4/Window 
  2K (patch level 8.4.5).

  1) run wish84
  2) eval "winfo id ." and find the id is 0x000e0dc8
  3) run another wish84
  4) eval "toplevel .t -use 0x000e0dc8" and get an 
  message box with a title: Console: wish84.exe -
  Application Error, with the following message: The 
  instruction at "0x0023b6ac" referenced memory 
  at "0x00000000".  The memory could not be "read".

  Click on OK to terminate the program
  Click on CANCEL to debug the program

  A user clicks OK and the first wish84 is killed.

  To solve the problem, a protocol for 
  embedding/embedded attachment is needed.  A 
  suggested one is for the container to send back its 
  id during attachment so that the embedded window 
  will use the returned id the verify the value of -use.

  If match, the embbedded application will proceed 
  the attachment.  Otherwise the embedded 
  application should return TCL_ERROR to cancel the 
  operation.


tkt_uuid: 471900ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: string misspelled as sting
comment:
  bgerror.tcl line 95

      if {[sting equal $tcl_platform(platform) 
  "macintosh"]

  should be

      if {[string equal $tcl_platform(platform) 
  "macintosh"]


tkt_uuid: 220087ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Duplicate
title: Characters "ä", "ö", "ü" shown in wrong font
comment:
  OriginalBugID: 5469 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-12'
  LastModified: '2000-05-12'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2172
  OS: Windows NT
  OSVersion: MS Windows 98, NT 4.0 SP3
  Machine: Pentium II 400, Pentium II 333
  ClosedDate: '2000-05-12'


  Name:
  Stefan Koch

  Extensions:
  BWidget, Tk

  ReproducibleScript:
  Within the console window as well as in entry widgets the characters "ä", "ö", "ü" change the font type when using the font "Fixedsys 9"

  ObservedBehavior:
  Behaviour observed on NT and Windows 98



  The fix for this is listed in bug 2172, for which a different form
  will be incorporated into Tk8.4a1. 
  -- 05/12/2000 hobbs


tkt_uuid: 220553ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Implementation of XWarpPointer for Windows
comment:
  OriginalBugID: 2340 RFE
  Version: 8.1.1
  SubmitDate: '1999-07-07'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:

  Jan Nijtmans



  CVS:

  Juli 2, 1999



  DesiredBehavior:

  This function allows extensions to warp the

      mouse pointer in the same way as X does it.

      I know it is not recommended to do that in

      general user interfaces, but for things like

      playback it is the common thing to do.



  Patch:

  *** generic/tkInt.decls.origTue Jul  6 21:23:07 1999

  --- generic/tkInt.declsTue Jul  6 21:37:38 1999

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

  *** 1505,1510 ****

        void XDrawLine (Display* d, Drawable dr, GC g, int x1, int y1, \

        int x2, int y2)

    }

    

    # X functions for Mac

    

  --- 1505,1514 ----

        void XDrawLine (Display* d, Drawable dr, GC g, int x1, int y1, \

        int x2, int y2)

    }

  + declare 105 win {

  +     void XWarpPointer (Display* d, Window dw, int sx, int sy, \

  +     unsigned int sw, unsigned int sh, int dx, int dy)

  + }

    

    # X functions for Mac

    

  *** win/tkWinPointer.c.origTue Jul  6 21:23:27 1999

  --- win/tkWinPointer.cTue Jul  6 21:24:13 1999

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

  *** 331,336 ****

  --- 331,372 ----

        *mask_return = TkWinGetModifierState();

        return True;

    }

  + 

  + /*

  +  *----------------------------------------------------------------------

  +  *

  +  * XWarpPointer --

  +  *

  +  *Move pointer to new location.  This is not a complete

  +  *implementation of this function.

  +  *

  +  * Results:

  +  *None.

  +  *

  +  * Side effects:

  +  *Mouse pointer changes position on screen.

  +  *

  +  *----------------------------------------------------------------------

  +  */

  + 

  + void

  + XWarpPointer(display, src_w, dest_w, src_x, src_y, src_width,

  + src_height, dest_x, dest_y)

  +     Display* display;

  +     Window src_w;

  +     Window dest_w;

  +     int src_x;

  +     int src_y;

  +     unsigned int src_width;

  +     unsigned int src_height;

  +     int dest_x;

  +     int dest_y;

  + {

  +     RECT r;

  + 

  +     GetWindowRect(Tk_GetHWND(dest_w), &r);

  +     SetCursorPos(r.left+dest_x, r.top+dest_y);    

  + }

    

    /*

     *----------------------------------------------------------------------



  PatchFiles:

  tkInt.decls tkWinPointer.c





  in 8.3b1 
  -- 12/13/1999 hobbs


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

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

  package require Tk

  wm withdraw .

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

  puts $res
  exit 0

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

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


tkt_uuid: 1308786fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 6
foundin: None
resolution: None
title: Photo visibility in widgets
comment:
  Hi,
  we wrote an extension in C to Tk for aMSN which let us
  to load animated gifs and we display each frame after a
  delay with Tk_PhotoPutBlock. But when we have many
  animated GIFs loaded it take many CPU power and we
  would like to reduce it. To do that we would need a
  function to know the visibility of the image. Not if it
  is bind to a widget but if it is displayed in any
  widget. Or maybe you have another idea to know that...
  Thanks


tkt_uuid: 643823ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: insertion cursor not seen at right
comment:
  If the insertion cursor is displayed at the right side of an entry widget it is not shown at all. This is on aqua Tk 8.4.1 (MacOS X 10.2.1).

  To see this effect, make an entry widget with right justification:
  entry .test -justify right
  pack .test
  Then manually resize the window size so the grow box does not obscure any of the entry widget.

  No insertion cursor is shown when the widget has focus unless the insertion cursor is somewhere other than after the right-most character.

  -- Russell


tkt_uuid: 220153ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: Photos don't provide a way to get the size
comment:
  OriginalBugID: 1647 RFE
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '1999-08-06'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: FreeBSD 3.0
  Machine: NA
  ClosedDate: '1999-08-06'


  Name:
  Steven Grady

  CustomShell:
  I applied the Img8.1b2 patches to Tk

  ReproducibleScript:
      #!/usr/local/bin/wish8.1
      image create photo foo -file test.gif
      puts [foo cget -width] 
      
      (Provide a GIF file, test.gif, when running)
      



  ObservedBehavior:
      The width is "0"
      



  DesiredBehavior:
      I'd like to see the width of the image.  If I can't get it via "cget
      -width",
      then there should be a separate option to extract information about the
      current
      photo.
      
      (This is also important when changing the size via. subsampling.)
      




  This is the purpose of the [image width|height <name>] methods. 
  -- 08/06/1999 hobbs


tkt_uuid: 1632447fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 43. Photo Image|PPM
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.4.12
private_contact: c39c633bc9fd2fa3639a14e104fd770241e1fea2
resolution: None
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: 2745650fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Works For Me
title: Quit menu cannot be overridden
comment:
  The standard Quit menu item that appears in the application menu of Aqua Tcl/Tk applications on MacOS X appears to be hard-wired to do something (stop the mainloop?). This presents a real problem when the application needs special behavior to quit.

  My specific problem is that I have a Python/Tkinter application that uses the Twisted networking library. Twisted takes over the tcl/tk event loop in a way that is transparent to tcl/tk, but a nasty side effect is that the Quit menu item has absolutely no effect!!! If I could bind to something to catch the menu item it would be fine, but I've not figured out a binding that works. The root window is not closed, so catching destroy from the window manager is not an option. 

  Please offer some way to modify the behavior of the Quit menu item for MacOS X Aqua Tcl/Tk applications. Or some way to hide that menu item so I can add my own.

  (Note: the problem does not occur on unix and Windows because they don't automatically add a Quit menu item. I have to set my own so I can make it do whatever I like).


tkt_uuid: 220348ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Reliably free image color table
comment:
  OriginalBugID: 586 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-15'
  Severity: SER
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  In Tk8.0p2, when you free an photo image, the DisposeInstance call

  will call FreeColorTable.  That function will schedule an idle call to

  free the color table for the image.


  However, if you are shutting down Tcl, then there won't be any more

  idle calls, so the color table will never be freed.


  Here is a patch to force a color table to be freed immediately when

  disposing of an instance.


  Ian Taylor

  ian@cygnus.com


  *** /5g/ian/tk8.0p2/generic/tkImgPhoto.c        Fri Aug  8 14:32:47 1997

  --- tkImgPhoto.c        Tue Apr 14 14:26:34 1998

  *************** static int              IsValidPalette _ANSI_ARGS_((

  *** 361,367 ****

                              char *palette));

    static int            CountBits _ANSI_ARGS_((pixel mask));

    static void           GetColorTable _ANSI_ARGS_((PhotoInstance *instancePtr));

  ! static void           FreeColorTable _ANSI_ARGS_((ColorTable *colorPtr));

    static void           AllocateColors _ANSI_ARGS_((ColorTable *colorPtr));

    static void           DisposeColorTable _ANSI_ARGS_((ClientData clientData));

    static void           DisposeInstance _ANSI_ARGS_((ClientData clientData));

  --- 361,368 ----

                              char *palette));

    static int            CountBits _ANSI_ARGS_((pixel mask));

    static void           GetColorTable _ANSI_ARGS_((PhotoInstance *instancePtr));

  ! static void           FreeColorTable _ANSI_ARGS_((ColorTable *colorPtr,

  !                           int force));

    static void           AllocateColors _ANSI_ARGS_((ColorTable *colorPtr));

    static void           DisposeColorTable _ANSI_ARGS_((ClientData clientData));

    static void           DisposeInstance _ANSI_ARGS_((ClientData clientData));

  *************** ImgPhotoConfigureInstance(instancePtr)

  *** 1486,1492 ****


          if (colorTablePtr != NULL) {

              colorTablePtr->liveRefCount -= 1;

  !           FreeColorTable(colorTablePtr);

          }

          GetColorTable(instancePtr);


  --- 1487,1493 ----


          if (colorTablePtr != NULL) {

              colorTablePtr->liveRefCount -= 1;

  !           FreeColorTable(colorTablePtr, 0);

          }

          GetColorTable(instancePtr);


  *************** ImgPhotoGet(tkwin, masterData)

  *** 1646,1652 ****


                  Tcl_CancelIdleCall(DisposeInstance, (ClientData) instancePtr);

                  if (instancePtr->colorTablePtr != NULL) {

  !                   FreeColorTable(instancePtr->colorTablePtr);

                  }

                  GetColorTable(instancePtr);

              }

  --- 1647,1653 ----


                  Tcl_CancelIdleCall(DisposeInstance, (ClientData) instancePtr);

                  if (instancePtr->colorTablePtr != NULL) {

  !                   FreeColorTable(instancePtr->colorTablePtr, 0);

                  }

                  GetColorTable(instancePtr);

              }

  *************** GetColorTable(instancePtr)

  *** 2484,2498 ****

     */


    static void

  ! FreeColorTable(colorPtr)

        ColorTable *colorPtr;     /* Pointer to the color table which is

                                   * no longer required by an instance. */

    {

        colorPtr->refCount--;

        if (colorPtr->refCount > 0) {

          return;

        }

  !     if ((colorPtr->flags & DISPOSE_PENDING) == 0) {

          Tcl_DoWhenIdle(DisposeColorTable, (ClientData) colorPtr);

          colorPtr->flags |= DISPOSE_PENDING;

        }

  --- 2485,2506 ----

     */


    static void

  ! FreeColorTable(colorPtr, force)

        ColorTable *colorPtr;     /* Pointer to the color table which is

                                   * no longer required by an instance. */

  +     int force;                        /* Force free to happen immediately. */

    {

        colorPtr->refCount--;

        if (colorPtr->refCount > 0) {

          return;

        }

  !     if (force) {

  !       if ((colorPtr->flags & DISPOSE_PENDING) != 0) {

  !           Tcl_CancelIdleCall(DisposeColorTable, (ClientData) colorPtr);

  !           colorPtr->flags &= ~DISPOSE_PENDING;

  !       }

  !       DisposeColorTable((ClientData) colorPtr);

  !     } else if ((colorPtr->flags & DISPOSE_PENDING) == 0) {

          Tcl_DoWhenIdle(DisposeColorTable, (ClientData) colorPtr);

          colorPtr->flags |= DISPOSE_PENDING;

        }

  *************** DisposeInstance(clientData)

  *** 2958,2964 ****

          ckfree((char *) instancePtr->error);

        }

        if (instancePtr->colorTablePtr != NULL) {

  !       FreeColorTable(instancePtr->colorTablePtr);

        }


        if (instancePtr->masterPtr->instancePtr == instancePtr) {

  --- 2966,2972 ----

          ckfree((char *) instancePtr->error);

        }

        if (instancePtr->colorTablePtr != NULL) {

  !       FreeColorTable(instancePtr->colorTablePtr, 1);

        }


        if (instancePtr->masterPtr->instancePtr == instancePtr) {




  This patch was integrated sometime before 8.2.0. 
  -- 08/15/1999 hobbs


tkt_uuid: 749463ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: None
resolution: None
title: win<->X discrepancy: keysyms
comment:
  Under windows, the keypad-keys are reported as
  non-keypad keys, eg. the keysym is UP instead of KP_UP.
  Binding the KP_UP keysyms fails.


tkt_uuid: 220027ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: Memory Problem while running the Tcl/Tk script
comment:
  OriginalBugID: 2875 RFE
  Version: 8.0p2
  SubmitDate: '1999-09-23'
  LastModified: '2000-01-25'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3220
  OS: Linux-SuSE
  Machine: Other
  ClosedDate: '2000-01-25'


  Name:
  Kulkarni Vivek

  DesiredBehavior:
  Can you tell me about - how to manage memory in Tcl/Tk as I am having a
      lot of procedures in the 
      Tcl/Tk. It creates problem while running it. I am building GUI and I am
      showing some moving things in that. As number of moving objects on the
      screen increases the GUI slows down considerably.
      What can be done in this case? Shall I send the script to you so that
      you can have a look at it.


tkt_uuid: 1297800fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Invalid
title: menus dont work right when called from systray
comment:
  The problem is described here:

  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/60d29d5a874c6805/6114f936e7370bb0

  and here:

  http://support.microsoft.com/kb/q135788/

  To sum it up:

  I'm using the winico extension to create an app that
  normally is
  "withdraw"n, and just sits in the windows systray. 
  Like other normal systray applications, if you right
  click on it, a little menu comes up. So far, so good. 
  The problem is when you click somewhere outside the
  menu.  That should normally make it go away, but it
  doesn't. 

  Here is a workaround, called from the winico callback:

  WM_RBUTTONDOWN {
      # Pop up the menu when we get right-clicked.

      # This is all very ugly, and we have Microsoft to
  thank:
      # http://support.microsoft.com/kb/q135788/
      wm overrideredirect .info 1
      wm geometry .info 0x0-1000-1000 
      focus -force .info
      raise .info
      update
      .info post $x $y
  }


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: 220447ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: sockets,files not closed on program termination
comment:
  OriginalBugID: 1437 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-04'
  LastModified: '1999-10-19'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-10-19'
  FixedInVersion: 8.2


  Name:
  David Maggiano

  ObservedBehavior:
  When running tk applications on NT 4.0, sockets do not appear to be closed
  for you when you close the window to exit the application.  This causes
  an error the next time the program is executed, indicating that the requested
  port is already in use.  I see no way other than a shut down to reset the 
  port.



  DesiredBehavior:
  I would expect sockets to be closed when the parent application is terminated.




  The socket driver code was rewritten in 8.2.0.  A quick test of:
     proc foo args {puts [info level 0]}
     socket -server foo 12345
  run through consecutive invocations of wish where wish was ended
  with the [X] worked, so it appears this was fixed with 8.2. 
  -- 10/19/1999 hobbs


tkt_uuid: 563866ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: Italic displayed wrong in text widget
comment:
  Italic and bold are displayed incorrectly in the text widget 
  when using MS Sans Serif font (this font seems to be the 
  default on my windows machine for Tk).  Other fonts I 
  checked don't seem to have this problem.

  When italic is applied to a tag in the widget, a large amount 
  of space follows the portion of the text that is italic.  Then 
  moving the cursor back and forth across the italic 
  characters causes the X position of the characters to jump 
  around.  Similar behavior is seen for bold.

  I have duplicated this on both 8.3.2 and 8.4a5.

  Here is a script that demonstrates the problem:
  package require Tk
  proc showTextBug {effect fontFamily} {
      .t configure -font [list $fontFamily 8]
      .t insert end "This is an " {} $effect $effect " word"
      set origLineWidth [lindex [.t dlineinfo 1.0] 2]
      .t tag configure $effect -font [list $fontFamily 8 $effect]
      set newLineWidth [lindex [.t dlineinfo 1.0] 2]
      set msg ""
      append msg "Adding $effect caused the linewidth to 
  increase from $origLineWidth to $newLineWidth\n"
      append msg "It should be visually apparent that the 
  $effect word doesn't look right (lots of extra space at the 
  end)\n"
      tk_messageBox -message $msg -icon info

      .t mark set insert 1.0
      set origXpos [lindex [.t bbox 1.12] 0]
      .t mark set insert 1.12
      set newXpos [lindex [.t bbox 1.12] 0]
      set msg ""
      append msg "Placing the insertion cursor on the $effect 
  word caused the X position of the character at 1.12\n"
      append msg "to change from $origXpos to $newXpos\n"
      tk_messageBox -message $msg -icon info
      return
      }

  text .t
  pack .t
  showTextBug italic {MS Sans Serif}
  .t delete 1.0 end
  showTextBug bold {MS Sans Serif}


tkt_uuid: 220745ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Wish crashes with segmentation fault
comment:
  OriginalBugID: 5783 Bug
  Version: 8.3.1
  SubmitDate: '2000-06-01'
  LastModified: '2000-06-02'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: Linux 2.2.14
  Machine: Dell Pentium III box
  FixedDate: '2000-06-02'
  FixedInVersion: 8.4a1


  Name:

  David F. Skoll



  Comments:

  Nice work on Tcl/Tk!  Keep it up and keep it free!



  ReproducibleScript:

  The following script crashes Wish 8.3.1:



  canvas .c

  pack .c

  .c create polygon 0 0 100 100 200 50 -fill {} -stipple gray50 -outline black



  ObservedBehavior:

  Segmentation fault



  DesiredBehavior:

  No segmentation fault



  Patch:

  *** tkCanvPoly.c        Thu Jun  1 12:00:10 2000

  --- tkCanvPoly-fixed.c  Thu Jun  1 12:00:24 2000

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

  *** 916,922 ****

         * read-only.

         */

    

  !     if (stipple != None) {

          Tk_TSOffset *tsoffset = &polyPtr->tsoffset;

          int w=0; int h=0;

          int flags = tsoffset->flags;

  --- 916,922 ----

         * read-only.

         */

    

  !     if (stipple != None && polyPtr->fillGC != None) {

          Tk_TSOffset *tsoffset = &polyPtr->tsoffset;

          int w=0; int h=0;

          int flags = tsoffset->flags;

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

  *** 991,997 ****

          }

        }

        Tk_ResetOutlineGC(canvas, itemPtr, &(polyPtr->outline));

  !     if (stipple != None) {

          XSetTSOrigin(display, polyPtr->fillGC, 0, 0);

        }

    }

  --- 991,997 ----

          }

        }

        Tk_ResetOutlineGC(canvas, itemPtr, &(polyPtr->outline));

  !     if (stipple != None && polyPtr->fillGC != None) {

          XSetTSOrigin(display, polyPtr->fillGC, 0, 0);

        }

    }



  PatchFiles:

  generic/tkCanvPoly.c





  Added with extra test to 8.4a1. 
  -- 06/02/2000 hobbs


tkt_uuid: 220059ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Duplicate
title: -outline stipple option doesn't work with create rectangle
comment:
  OriginalBugID: 4081 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-03-27'
  Severity: LOW
  Status: Closed
  Submitter: shawn
  ChangedBy: hobbs
  RelatedBugIDs: 1274
  OS: Windows NT
  ClosedDate: '2000-03-27'


  -outline stipple option doesn't work with create rectangle  -  outline is not different with -outlinestipple option applied - 

  reproducible script: 

  .a create rectangle  0 0 500 500 -fill brown 

  .a create rectangle 20 20 200 200  -fill green -stipple gray50 -outline green -outlinestipple gray50

  .a create rectangle 220 20  400  200 -fill green -stipple gray50 -outline green 

  Expected results: 

  I expect the outline of the first rectangle to be stippled according to the bitmap gray50 -  both rectangles are the same. 


tkt_uuid: 1711987fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: type-pun warning
comment:
  /home/dgp/src/tk8.5a6/unix/../generic/tkOption.c: In function ‘GetDefaultOptions’:
  /home/dgp/src/tk8.5a6/unix/../generic/tkOption.c:1586: warning: dereferencing type-punned pointer will break strict-aliasing rules


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: 793909ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: Problem with nonexistent namespaces
comment:
  Platform:

  Win98SE,Wish8.3for Windows.

  Description:

  It is possible to assign the "-textvariable <name>" option 
  to an entry widget using a namespace that does not
  yet exist. 

  After the namespace and variable are instantiated, changes to
  the variable are not reflected within the text widget. 

  Subsequent ".entry config -textvariable <name> " 
  commands do not clear up the problem. 

  Code snippet:
  entry .foo -textvariable fred::foo(wha)

  namespace eval fred { 
     variable foo
  }



  grid .foo

  set fred::foo(wha) "Hey!"


tkt_uuid: 1977618fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: tk_messageBox OS X no translation
comment:
  In a German environment, tk_messageBox uses English labels on Buttons for eg "-type yesno" instead of German.

  I found this on OS X but not on Linux with Tcl/Tk 8.5.2.

  Other dialogs like tk_getOpenFile show the German labels fine.


tkt_uuid: 220467ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Tk 8.1b2 patch level not correct
comment:
  OriginalBugID: 1614 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-24'
  LastModified: '1999-04-05'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Other
  Machine: NA
  FixedDate: '2019-06-01'
  FixedInVersion: 8.1b3


  Name:
  Jeffrey Hobbs

  ReproducibleScript:
      The tk_patchLevel was wrong when I did an about, which I traced back
      to the fact that it wasn't updated in tk.h
      
      



  Patch:
  ewsx2 [~/src/tk8.1b2/generic] 95 % diff tk.h~ tk.h
  48c48
  < #define TK_PATCH_LEVEL "8.1b1"
  ---
  > #define TK_PATCH_LEVEL "8.1b2"




  PatchFiles:
      tk8.1b2/generic/tk.h
      


tkt_uuid: 469074ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Duplicate
title: 'image create photo .' segfaults
comment:
  I thought this bug had been fixed somewhere, but on 
  Windows 2000 with the latest cvs pull, 'image create 
  photo .' crashes.


tkt_uuid: 220119ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: error handling is not turned on when invoking a proc from a menu (on windows95)
comment:
  OriginalBugID: 953 Bug
  Version: 8.0p2
  SubmitDate: '1998-12-14'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Windows 95
  OSVersion: alpha
  Machine: X86
  ClosedDate: '2000-04-03'


  Name:
  michal holenderski

  Extensions:
  none

  CustomShell:
  none

  ReproducibleScript:
  # here is short script which will show
  # my problem. i am using windows95 (on
  # unix this bug doesn't exist). when 
  # you envoke a procedure from a menu,
  # the error handling is not turned on.
  # i get no error messages. but if i 
  # envoke the same procedure using a # button, the exception handler is 
  # turned on. 
  # this script creates a simple form
  # with a menu and a button. to both
  # a not existing procedure (Quit) is
  # attached. when you press the button
  # an error message apears, when you
  # chose the menu, nothing happens.

  # create the menue
    set m  .menu 
    menu $m 

    set file $m.file
    menu $file -tearoff 0
    $m add cascade -label File -menu $file
    $file add command -label "Quit" -command "Quit"

    . configure -menu  .menu

    pack [button .quit -text "Quit" -command "Quit"]



  ObservedBehavior:
  # here is short script which will show
  # my problem. i am using windows95 (on
  # unix this bug doesn't exist). when 
  # you envoke a procedure from a menu,
  # the error handling is not turned on.
  # i get no error messages. but if i 
  # envoke the same procedure using a # button, the exception handler is 
  # turned on. 
  # this script creates a simple form
  # with a menu and a button. to both
  # a not existing procedure (Quit) is
  # attached. when you press the button
  # an error message apears, when you
  # chose the menu, nothing happens.




  DesiredBehavior:
  the menu schould behave like the button.




  This works on 8.3.0 with NT.

  - eric
   
  -- 04/03/2000 ericm


tkt_uuid: 220068ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: mingw support for Tk
comment:
  OriginalBugID: 4235 RFE
  Version: 8.3
  SubmitDate: '2000-02-23'
  LastModified: '2000-06-13'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 5844
  OS: All Windows
  FixedDate: '2000-06-13'


  Name:
  Jan Nijtmans

  DesiredBehavior:
  Here are the patches from  Mumit Khan <khan@NanoTech.Wisc.EDU> submitted through the official bug form.

  Patch:
  *** win/Makefile.in.origThu Feb 10 12:11:05 2000
  --- win/Makefile.inWed Feb 23 20:21:11 2000
  ***************
  *** 85,93 ****
    # names based on the platform.
    PATHTYPE= @PATHTYPE@

    # The name of the Tcl library.
  ! TCL_LIB_FILE  = "$(shell cygpath $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_LIB_FILE@')"
  ! TCL_STUB_LIB_FILE = "$(shell cygpath $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_STUB_LIB_FILE@')"

    SRC_DIR= @srcdir@
    ROOT_DIR= $(SRC_DIR)/..
  --- 85,96 ----
    # names based on the platform.
    PATHTYPE= @PATHTYPE@

  + # This program converts between Windows native and Cygwin POSIX pathnames.
  + CYGPATH= @CYGPATH@
  + 
    # The name of the Tcl library.
  ! TCL_LIB_FILE  = "$(shell $(CYGPATH) $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_LIB_FILE@')"
  ! TCL_STUB_LIB_FILE = "$(shell $(CYGPATH) $(PATHTYPE) '@TCL_BIN_DIR@/@TCL_STUB_LIB_FILE@')"

    SRC_DIR= @srcdir@
    ROOT_DIR= $(SRC_DIR)/..
  ***************
  *** 98,111 ****
    XLIB_DIR= $(ROOT_DIR)/xlib
    RC_DIR= $(WIN_DIR)/rc

  ! ROOT_DIR_NATIVE   = $(shell cygpath $(PATHTYPE) '$(ROOT_DIR)')
  ! WIN_DIR_NATIVE   = $(shell cygpath $(PATHTYPE) '$(WIN_DIR)')
  ! GENERIC_DIR_NATIVE = $(shell cygpath $(PATHTYPE) '$(GENERIC_DIR)')
  ! BITMAP_DIR_NATIVE= $(shell cygpath $(PATHTYPE) '$(ROOT_DIR)/bitmaps')
  ! XLIB_DIR_NATIVE= $(shell cygpath $(PATHTYPE) '$(ROOT_DIR)/xlib')
  ! TCL_GENERIC_NATIVE= $(shell cygpath $(PATHTYPE) '$(TCL_GENERIC_DIR)')
  ! TCL_SRC_DIR_NATIVE      = $(shell cygpath $(PATHTYPE) '$(TCL_SRC_DIR)')
  ! TCL_BIN_DIR_NATIVE      = $(shell cygpath $(PATHTYPE) '$(TCL_BIN_DIR)')

    DLLSUFFIX= @DLLSUFFIX@
    LIBSUFFIX= @LIBSUFFIX@
  --- 101,114 ----
    XLIB_DIR= $(ROOT_DIR)/xlib
    RC_DIR= $(WIN_DIR)/rc

  ! ROOT_DIR_NATIVE   = $(shell $(CYGPATH) $(PATHTYPE) '$(ROOT_DIR)')
  ! WIN_DIR_NATIVE   = $(shell $(CYGPATH) $(PATHTYPE) '$(WIN_DIR)')
  ! GENERIC_DIR_NATIVE = $(shell $(CYGPATH) $(PATHTYPE) '$(GENERIC_DIR)')
  ! BITMAP_DIR_NATIVE= $(shell $(CYGPATH) $(PATHTYPE) '$(ROOT_DIR)/bitmaps')
  ! XLIB_DIR_NATIVE= $(shell $(CYGPATH) $(PATHTYPE) '$(ROOT_DIR)/xlib')
  ! TCL_GENERIC_NATIVE= $(shell $(CYGPATH) $(PATHTYPE) '$(TCL_GENERIC_DIR)')
  ! TCL_SRC_DIR_NATIVE      = $(shell $(CYGPATH) $(PATHTYPE) '$(TCL_SRC_DIR)')
  ! TCL_BIN_DIR_NATIVE      = $(shell $(CYGPATH) $(PATHTYPE) '$(TCL_BIN_DIR)')

    DLLSUFFIX= @DLLSUFFIX@
    LIBSUFFIX= @LIBSUFFIX@
  ***************
  *** 120,126 ****

    WISH= wish$(VER)${EXESUFFIX}
    TKTEST= tktest${EXEEXT}
  ! CAT32= cat32
    MAN2TCL= man2tcl$(EXEEXT)

    @SET_MAKE@
  --- 123,129 ----

    WISH= wish$(VER)${EXESUFFIX}
    TKTEST= tktest${EXEEXT}
  ! CAT32= cat32${EXEEXT}
    MAN2TCL= man2tcl$(EXEEXT)

    @SET_MAKE@
  ***************
  *** 128,140 ****
    # Macro that expands to the first dependency argument with the appropriate
    # path type already resolved.

  ! DEPARG = "$(shell cygpath $(PATHTYPE) $<)"

    # Setting the VPATH variable to a list of paths will cause the 
    # makefile to look into these paths when resolving .c to .obj
  ! # dependencies.

  ! VPATH = $(GENERIC_DIR);$(WIN_DIR);$(UNIX_DIR);$(XLIB_DIR);$(RC_DIR)

    # warning flags
    CFLAGS_WARNING= @CFLAGS_WARNING@
  --- 131,144 ----
    # Macro that expands to the first dependency argument with the appropriate
    # path type already resolved.

  ! DEPARG = "$(shell $(CYGPATH) $(PATHTYPE) $<)"

    # Setting the VPATH variable to a list of paths will cause the 
    # makefile to look into these paths when resolving .c to .obj
  ! # dependencies. Note the ':' to avoid autoconf's habit of deleting
  ! # all VPATH lines without an explicit ':' in it. 

  ! VPATH = $(GENERIC_DIR)@VPSEP@$(WIN_DIR)@VPSEP@$(UNIX_DIR)@VPSEP@$(XLIB_DIR)@VPSEP@$(RC_DIR) # :

    # warning flags
    CFLAGS_WARNING= @CFLAGS_WARNING@
  ***************
  *** 168,179 ****
    EXEEXT= @EXEEXT@
    OBJEXT= @OBJEXT@
    SHLIB_LD= @SHLIB_LD@
  ! SHLIB_LD_LIBS= @SHLIB_LD_LIBS@ $(TCL_STUB_LIB_FILE) gdi32.lib comdlg32.lib
    SHLIB_CFLAGS= @SHLIB_CFLAGS@
    SHLIB_SUFFIX= @SHLIB_SUFFIX@
    VER= @TK_MAJOR_VERSION@@TK_MINOR_VERSION@
    DOTVER= @TK_MAJOR_VERSION@.@TK_MINOR_VERSION@
  ! LIBS= @LIBS@ gdi32.lib comdlg32.lib
    RMDIR= rm -rf
    MKDIR= mkdir -p
    SHELL= @SHELL@
  --- 172,183 ----
    EXEEXT= @EXEEXT@
    OBJEXT= @OBJEXT@
    SHLIB_LD= @SHLIB_LD@
  ! SHLIB_LD_LIBS= @SHLIB_LD_LIBS@ $(TCL_STUB_LIB_FILE) @LIBS_GUI@
    SHLIB_CFLAGS= @SHLIB_CFLAGS@
    SHLIB_SUFFIX= @SHLIB_SUFFIX@
    VER= @TK_MAJOR_VERSION@@TK_MINOR_VERSION@
    DOTVER= @TK_MAJOR_VERSION@.@TK_MINOR_VERSION@
  ! LIBS= @LIBS@ @LIBS_GUI@
    RMDIR= rm -rf
    MKDIR= mkdir -p
    SHELL= @SHELL@
  ***************
  *** 474,492 ****

    $(WISH): $(TK_LIB_FILE) $(WISH_OBJS) wish.res
  ! $(CC) $(CFLAGS) $(WISH_OBJS) $(TCL_LIB_FILE) $(TK_LIB_FILE) $(LIBS)  ! wish.res $(CC_EXENAME) -link $(LDFLAGS_WINDOW)

    tktest : $(TKTEST)

    $(TKTEST): $(TK_LIB_FILE) $(TKTEST_OBJS) wish.res $(CAT32)
  ! $(CC) $(CFLAGS) $(TKTEST_OBJS_NATIVE) $(TCL_LIB_FILE)  ! $(TK_LIB_FILE) $(LIBS)  ! wish.res $(CC_EXENAME) -link $(LDFLAGS_WINDOW)

  ! $(CAT32): $(TCL_SRC_DIR)/cat.c
    $(CC) -c $(CC_SWITCHES) $(DEPARG) $(CC_OBJNAME)
  ! $(CC) $(CFLAGS) cat32.$(OBJEXT) $(CC_EXENAME) -link $(LDFLAGS_CONSOLE)

    # The following targets are configured by autoconf to generate either
    # a shared library or static library
  --- 478,498 ----

    $(WISH): $(TK_LIB_FILE) $(WISH_OBJS) wish.res
  ! $(CC) $(CFLAGS) $(WISH_OBJS) wish.res $(CC_EXENAME)  ! $(TK_LIB_FILE) $(TCL_LIB_FILE) $(LIBS) $(LDFLAGS_WINDOW)

    tktest : $(TKTEST)

    $(TKTEST): $(TK_LIB_FILE) $(TKTEST_OBJS) wish.res $(CAT32)
  ! $(CC) $(CFLAGS) $(TKTEST_OBJS_NATIVE) $(TK_LIB_FILE)  ! $(TCL_LIB_FILE) $(LIBS)  ! wish.res $(CC_EXENAME) $(LDFLAGS_WINDOW)

  ! cat32.${OBJEXT}: $(TCL_SRC_DIR)/cat.c
    $(CC) -c $(CC_SWITCHES) $(DEPARG) $(CC_OBJNAME)
  ! 
  ! $(CAT32): cat32.${OBJEXT}
  ! $(CC) $(CFLAGS) cat32.${OBJEXT} $(CC_EXENAME) $(LDFLAGS_CONSOLE)

    # The following targets are configured by autoconf to generate either
    # a shared library or static library
  ***************
  *** 497,503 ****

    ${TK_DLL_FILE}: ${TK_OBJS} tk.res
    @$(RM) ${TK_DLL_FILE}
  ! @MAKE_DLL@ ${TK_OBJS} tk.res

    ${TK_LIB_FILE}: ${TK_OBJS}
    @$(RM) ${TK_LIB_FILE}
  --- 503,509 ----

    ${TK_DLL_FILE}: ${TK_OBJS} tk.res
    @$(RM) ${TK_DLL_FILE}
  ! @MAKE_DLL@ ${TK_OBJS} tk.res ${SHLIB_LD_LIBS}

    ${TK_LIB_FILE}: ${TK_OBJS}
    @$(RM) ${TK_LIB_FILE}
  ***************
  *** 532,538 ****
  --- 538,548 ----
    $(CC) -c $(STUB_CC_SWITCHES) -DBUILD_tk ${DEPARG} $(CC_OBJNAME)

    .rc.res:
  + ifeq "$(findstring windres, $(RC))" ""
    $(RC) -fo $@ -r -i "$(GENERIC_DIR_NATIVE)" -i "$(TCL_GENERIC_NATIVE)" $(DEPARG)
  + else
  + $(RC) -O coff -o $@ --include "$(GENERIC_DIR_NATIVE)" --include "$(TCL_GENERIC_NATIVE)" --include "$(RC_DIR)" $(DEPARG)
  + endif

    depend:

  *** win/Makefile.mingw.origWed Feb 23 20:21:11 2000
  --- win/Makefile.mingwWed Feb 23 20:21:11 2000
  ***************
  *** 0 ****
  --- 1,600 ----
  + # GCC/MinGW makefile
  + #
  + # See the file "license.terms" for information on usage and redistribution
  + # of this file, and for a DISCLAIMER OF ALL WARRANTIES.
  + # 
  + # Copyright (c) 1995-1997 Sun Microsystems, Inc.
  + # RCS: @(#) $Id: Makefile.mingw,v 1.1 2000/02/17 20:23:24 khan Exp $
  + 
  + # Does not depend on the presence of any environment variables in
  + # order to compile tcl; all needed information is derived from 
  + # location of the compiler directories.
  + 
  + #
  + # Project directories
  + #
  + # ROOT    = top of source tree
  + #
  + # TMPDIR  = location where .o files should be stored during build
  + #
  + # TOOLS32 = location of VC++ 32-bit development tools. Note that the
  + #    VC++ 2.0 header files are broken, so you need to use the
  + #    ones that come with the developer network CD's, or later
  + #    versions of VC++.
  + #
  + # TCLDIR = location of top of Tcl source heirarchy
  + #
  + 
  + VPATH = .:$(XLIBDIR):$(WINDIR):$(GENERICDIR):$(ROOT)/unix:$(RCDIR)
  + 
  + ROOT= ..
  + TCLDIR= ../../tcl8.3
  + INSTALLDIR      = c:/progra~1/tcl
  + 
  + # Set this to the appropriate value of /MACHINE: for your platform
  + MACHINE= IX86
  + 
  + # Yes, Mingw will support IA64!
  + #!IF "$(MACHINE)" == "IA64"
  + #TOOLS32= c:/mingw64
  + #TOOLS32_rc= c:/mingw64
  + #!ELSE
  + TOOLS32= c:/mingw32
  + TOOLS32_rc= c:/mingw32
  + #!ENDIF
  + 
  + # Uncomment the following line to compile with thread support
  + #THREADDEFINES = -DTCL_THREADS=1
  + 
  + # Set NODEBUG to 0 to compile with symbols
  + NODEBUG = 1
  + 
  + # uncomment the following two lines to compile with TCL_MEM_DEBUG
  + #DEBUGDEFINES=-DTCL_MEM_DEBUG
  + 
  + ######################################################################
  + # Do not modify below this line
  + ######################################################################
  + 
  + TCLNAMEPREFIX = tcl
  + TKNAMEPREFIX = tk
  + WISHNAMEPREFIX = wish
  + VERSION = 83
  + DOTVERSION = 8.3
  + 
  + TCLSTUBPREFIX = $(TCLNAMEPREFIX)stub
  + TKSTUBPREFIX  = $(TKNAMEPREFIX)stub
  + 
  + 
  + BINROOT= .
  + #!IF "$(NODEBUG)" == "1"
  + #TMPDIRNAME= Release
  + #DBGX=
  + #!ELSE
  + #TMPDIRNAME= Debug
  + #DBGX= d
  + #!ENDIF
  + TMPDIR= $(BINROOT)/$(TMPDIRNAME)
  + OUTDIRNAME= $(TMPDIRNAME)
  + OUTDIR= $(TMPDIR)
  + 
  + TCLLIB = lib$(TCLNAMEPREFIX)$(VERSION)$(DBGX).a
  + TCLPLUGINLIB = lib$(TCLNAMEPREFIX)$(VERSION)p.a
  + TCLSTUBLIB= lib$(TCLSTUBPREFIX)$(VERSION)$(DBGX).a
  + TKDLLNAME= $(TKNAMEPREFIX)$(VERSION)$(DBGX).dll
  + TKDLL = $(OUTDIR)/$(TKDLLNAME)
  + TKLIB = $(OUTDIR)/lib$(TKNAMEPREFIX)$(VERSION)$(DBGX).a
  + TKSTUBLIBNAME= lib$(TKSTUBPREFIX)$(VERSION)$(DBGX).a
  + TKSTUBLIB= $(OUTDIR)/$(TKSTUBLIBNAME)
  + TKPLUGINDLLNAME= $(TKNAMEPREFIX)$(VERSION)p$(DBG).dll
  + TKPLUGINDLL = $(OUTDIR)/$(TKPLUGINDLLNAME)
  + TKPLUGINLIB = $(OUTDIR)/lib$(TKNAMEPREFIX)$(VERSION)p$(DBGX).a
  + 
  + WISH = $(OUTDIR)/$(WISHNAMEPREFIX)$(VERSION)$(DBGX).exe
  + WISHC = $(OUTDIR)/$(WISHNAMEPREFIX)c$(VERSION)$(DBGX).exe
  + WISHP = $(OUTDIR)/$(WISHNAMEPREFIX)p$(VERSION)$(DBGX).exe
  + TKTEST = $(OUTDIR)/$(TKNAMEPREFIX)test.exe
  + CAT32           = $(TMPDIR)/cat32.exe
  + 
  + #RMDIR= ./rmd.bat
  + #MKDIR= ./mkd.bat
  + #RM= del
  + #XCOPY= xcopy
  + RMDIR= rm -rf
  + MKDIR= mkdir -p
  + RM= rm -f
  + COPY= cp
  + XCOPY= cp -r
  + 
  + BIN_INSTALL_DIR = $(INSTALLDIR)/bin
  + INCLUDE_INSTALL_DIR = $(INSTALLDIR)/include
  + LIB_INSTALL_DIR = $(INSTALLDIR)/lib
  + SCRIPT_INSTALL_DIR = $(LIB_INSTALL_DIR)/tk$(DOTVERSION)
  + 
  + WISHOBJS =  + $(TMPDIR)/winMain.o
  + 
  + TKTESTOBJS =  + $(TMPDIR)/tkTest.o  + $(TMPDIR)/tkSquare.o  + $(TMPDIR)/testMain.o  + $(TCLLIBDIR)/tclThreadTest.o
  + 
  + XLIBOBJS =  + $(TMPDIR)/xcolors.o  + $(TMPDIR)/xdraw.o  + $(TMPDIR)/xgc.o  + $(TMPDIR)/ximage.o  + $(TMPDIR)/xutil.o
  + 
  + TKOBJS =  + $(TMPDIR)/tkConsole.o  + $(TMPDIR)/tkUnixMenubu.o  + $(TMPDIR)/tkUnixScale.o  + $(XLIBOBJS)  + $(TMPDIR)/tkWin3d.o  + $(TMPDIR)/tkWin32Dll.o  + $(TMPDIR)/tkWinButton.o  + $(TMPDIR)/tkWinClipboard.o  + $(TMPDIR)/tkWinColor.o  + $(TMPDIR)/tkWinConfig.o  + $(TMPDIR)/tkWinCursor.o  + $(TMPDIR)/tkWinDialog.o  + $(TMPDIR)/tkWinDraw.o  + $(TMPDIR)/tkWinEmbed.o  + $(TMPDIR)/tkWinFont.o  + $(TMPDIR)/tkWinImage.o  + $(TMPDIR)/tkWinInit.o  + $(TMPDIR)/tkWinKey.o  + $(TMPDIR)/tkWinMenu.o  + $(TMPDIR)/tkWinPixmap.o  + $(TMPDIR)/tkWinPointer.o  + $(TMPDIR)/tkWinRegion.o  + $(TMPDIR)/tkWinScrlbr.o  + $(TMPDIR)/tkWinSend.o  + $(TMPDIR)/tkWinTest.o  + $(TMPDIR)/tkWinWindow.o  + $(TMPDIR)/tkWinWm.o  + $(TMPDIR)/tkWinX.o  + $(TMPDIR)/stubs.o  + $(TMPDIR)/tk3d.o  + $(TMPDIR)/tkArgv.o  + $(TMPDIR)/tkAtom.o  + $(TMPDIR)/tkBind.o  + $(TMPDIR)/tkBitmap.o  + $(TMPDIR)/tkButton.o  + $(TMPDIR)/tkCanvArc.o  + $(TMPDIR)/tkCanvBmap.o  + $(TMPDIR)/tkCanvImg.o  + $(TMPDIR)/tkCanvLine.o  + $(TMPDIR)/tkCanvPoly.o  + $(TMPDIR)/tkCanvPs.o  + $(TMPDIR)/tkCanvText.o  + $(TMPDIR)/tkCanvUtil.o  + $(TMPDIR)/tkCanvWind.o  + $(TMPDIR)/tkCanvas.o  + $(TMPDIR)/tkClipboard.o  + $(TMPDIR)/tkCmds.o  + $(TMPDIR)/tkColor.o  + $(TMPDIR)/tkConfig.o  + $(TMPDIR)/tkCursor.o  + $(TMPDIR)/tkEntry.o  + $(TMPDIR)/tkError.o  + $(TMPDIR)/tkEvent.o  + $(TMPDIR)/tkFileFilter.o  + $(TMPDIR)/tkFocus.o  + $(TMPDIR)/tkFont.o  + $(TMPDIR)/tkFrame.o  + $(TMPDIR)/tkGC.o  + $(TMPDIR)/tkGeometry.o  + $(TMPDIR)/tkGet.o  + $(TMPDIR)/tkGrab.o  + $(TMPDIR)/tkGrid.o  + $(TMPDIR)/tkImage.o  + $(TMPDIR)/tkImgBmap.o  + $(TMPDIR)/tkImgGIF.o  + $(TMPDIR)/tkImgPPM.o  + $(TMPDIR)/tkImgPhoto.o  + $(TMPDIR)/tkImgUtil.o  + $(TMPDIR)/tkListbox.o  + $(TMPDIR)/tkMacWinMenu.o  + $(TMPDIR)/tkMain.o  + $(TMPDIR)/tkMenu.o  + $(TMPDIR)/tkMenubutton.o  + $(TMPDIR)/tkMenuDraw.o  + $(TMPDIR)/tkMessage.o  + $(TMPDIR)/tkObj.o  + $(TMPDIR)/tkOldConfig.o  + $(TMPDIR)/tkOption.o  + $(TMPDIR)/tkPack.o  + $(TMPDIR)/tkPlace.o  + $(TMPDIR)/tkPointer.o  + $(TMPDIR)/tkRectOval.o  + $(TMPDIR)/tkScale.o  + $(TMPDIR)/tkScrollbar.o  + $(TMPDIR)/tkSelect.o  + $(TMPDIR)/tkText.o  + $(TMPDIR)/tkTextBTree.o  + $(TMPDIR)/tkTextDisp.o  + $(TMPDIR)/tkTextImage.o  + $(TMPDIR)/tkTextIndex.o  + $(TMPDIR)/tkTextMark.o  + $(TMPDIR)/tkTextTag.o  + $(TMPDIR)/tkTextWind.o  + $(TMPDIR)/tkTrig.o  + $(TMPDIR)/tkUtil.o  + $(TMPDIR)/tkVisual.o  + $(TMPDIR)/tkStubInit.o  + $(TMPDIR)/tkStubLib.o  + $(TMPDIR)/tkWindow.o
  + 
  + TKSTUBOBJS = $(TMPDIR)/tkStubLib.o  + $(TMPDIR)/tkStubImg.o
  + 
  + 
  + #cc32= "$(TOOLS32)/bin/cl.exe"
  + #link32= "$(TOOLS32)/bin/link.exe"
  + #lib32= "$(TOOLS32)/bin/lib.exe"
  + #rc32= "$(TOOLS32_rc)/bin/rc.exe"
  + #include32= -I"$(TOOLS32)/include"
  + 
  + # Say yes if you have gcc-2.95.2-1 and binutils-19990818-1 or later, which
  + # contains support for `gcc -shared' and `ld --shared'.
  + LD_SUPPORTS_SHARED = no
  + 
  + cc32= $(CROSS)gcc
  + link32= $(cc32)
  + rc32= $(CROSS)windres
  + include32= 
  + libpath32= 
  + lib32= $(CROSS)ar
  + # Needed if LD_SUPPORTS_SHARED is "no". GNU ld supports --shared on 
  + # x86-windows starting from binutils-19990818-1 release. 
  + dllwrap= $(CROSS)dllwrap
  + 
  + # Needed for cross-compilation only.
  + ifneq "$(strip $(CROSS))" ""
  + rc32_flags= --preprocessor "$(cc32) -c -E -xc-header -DRC_INVOKED"
  + dllwrap_flags= --as=$(CROSS)as --dlltool-name=$(CROSS)dlltool  +   --driver-name=$(cc32)
  + endif
  + 
  + WINDIR          = $(ROOT)/win
  + GENERICDIR= $(ROOT)/generic
  + XLIBDIR= $(ROOT)/xlib
  + BITMAPDIR= $(ROOT)/bitmaps
  + TCLLIBDIR       = $(TCLDIR)/win/$(OUTDIRNAME)
  + RCDIR= $(WINDIR)/rc
  + 
  + TK_INCLUDES= -I$(WINDIR) -I$(GENERICDIR) -I$(BITMAPDIR) -I$(XLIBDIR)  + -I$(TCLDIR)/generic
  + TK_DEFINES= -D__WIN32__ $(DEBUGDEFINES) $(THREADDEFINES)
  + 
  + ######################################################################
  + # Compile flags
  + ######################################################################
  + 
  + #!IF "$(NODEBUG)" == "1"
  + #!IF "$(MACHINE)" == "ALPHA"
  + ## MSVC on Alpha doesn't understand -Ot
  + #cdebug= -O2i -Gs -GD
  + #!ELSE
  + ## NOTE: Due to a bug in MSVC, we cannot use -O2 here or Tk starts to misbehave.
  + #cdebug= -Oti -Gs -GD
  + #!ENDIF
  + #!ELSE
  + #!IF "$(MACHINE)" == "IA64"
  + #cdebug= -Od -Zi
  + #!ELSE
  + #cdebug= -Z7 -Od -WX
  + #!ENDIF
  + #!ENDIF
  + 
  + ifeq "$(NODEBUG)" "1"
  + # This cranks the optimization level to maximize speed
  + cdebug = -O2
  + else
  + ifeq "$(MACHINE)" "IA64"
  + cdebug = -g
  + else
  + cdebug = -g
  + endif
  + endif
  + 
  + # declarations common to all compiler options
  + #cflags= -c -W3 -nologo -Fp$(TMPDIR)/ -YX
  + #cvarsdll = -MD$(DBGX)
  + cflags = -c -Wall
  + cvarsdll = 
  + 
  + CON_CFLAGS= $(cdebug) $(cflags) $(include32) -DCONSOLE
  + TK_CFLAGS= $(cdebug) $(cflags) $(cvarsdll) $(include32)  + $(TK_INCLUDES) $(TK_DEFINES) -DUSE_TCL_STUBS
  + WISH_CFLAGS= $(cdebug) $(cflags) $(cvarsdll) $(include32)  + $(TK_INCLUDES) $(TK_DEFINES)
  + 
  + ######################################################################
  + # Link flags
  + ######################################################################
  + 
  + #!IF "$(NODEBUG)" == "1"
  + #ldebug= /RELEASE
  + #!ELSE
  + #ldebug= -debug:full -debugtype:cv
  + #!ENDIF
  + 
  + # declarations common to all linker options
  + #lcommon= /NODEFAULTLIB /RELEASE /NOLOGO
  + #lflags= $(lcommon) /MACHINE:$(MACHINE)
  + lcommon= 
  + lflags= $(lcommon)
  + 
  + # declarations for use on Intel i386, i486, and Pentium systems
  + #!IF "$(MACHINE)" == "IX86"
  + #DLLENTRY = @12
  + #!ENDIF
  + 
  + #conlflags= $(lflags) -subsystem:console -entry:mainCRTStartup
  + #guilflags= $(lflags) -subsystem:windows -entry:WinMainCRTStartup
  + #dlllflags= $(lflags) -entry:_DllMainCRTStartup$(DLLENTRY) -dll
  + conlflags= $(lflags) 
  + guilflags= $(lflags) -mwindows
  + 
  + ifeq "$(strip $(LD_SUPPORTS_SHARED))" "yes"
  + dlllflags = $(lflags) -shared
  + else
  + dlllflags = $(lflags) 
  + endif
  + 
  + #!IF "$(MACHINE)" == "PPC"
  + #libc = libc$(DBGX).lib
  + #libcdll = crtdll$(DBGX).lib
  + #!ELSE
  + #libc = libc$(DBGX).lib oldnames.lib
  + #libcdll = msvcrt$(DBGX).lib oldnames.lib
  + #!ENDIF
  + 
  + #baselibs   = kernel32.lib $(optlibs) advapi32.lib
  + #winlibs    = $(baselibs) user32.lib gdi32.lib comdlg32.lib winspool.lib
  + 
  + baselibs   = 
  + winlibs    = -mwindows -lwinspool 
  + 
  + guilibs   = $(libc) $(winlibs)
  + conlibs    = $(libc) $(baselibs)
  + guilibsdll = $(libcdll) $(winlibs)
  + 
  + ######################################################################
  + # Project specific targets
  + ######################################################################
  + 
  + all:    setup $(WISH) $(CAT32)
  + install: install-binaries install-libraries
  + plugin:setup $(TKPLUGINDLL) $(WISHP)
  + tktest: setup $(TKTEST) $(CAT32)
  + test:setup $(TKTEST) $(TKLIB) $(CAT32)
  + set TCL_LIBRARY=$(TCLDIR)/library
  + set PATH=$(TCLDIR)\\win\\$(TMPDIRNAME);$(PATH)
  + $(TKTEST) $(ROOT)/tests/all.tcl | $(CAT32)
  + 
  + runtest: setup $(TKTEST) $(TKLIB) $(CAT32)
  + set TCL_LIBRARY=$(TCLDIR)/library
  + set PATH=$(TCLDIR)\\win\\$(TMPDIRNAME);$(PATH)
  + $(TKTEST) 
  + 
  + console-wish : all $(WISHC)
  + 
  + stubs:
  + $(TCLDIR)/win/$(TMPDIRNAME)/tclsh$(VERSION)$(DBGX)  + $(TCLDIR)/tools/genStubs.tcl $(GENERICDIR)  + $(GENERICDIR)/tk.decls $(GENERICDIR)/tkInt.decls
  + 
  + setup:
  + @$(MKDIR) $(TMPDIR)
  + @$(MKDIR) $(OUTDIR)
  + 
  + install-binaries:
  + @$(MKDIR) "$(BIN_INSTALL_DIR)"
  + $(COPY) $(TKDLL) "$(BIN_INSTALL_DIR)"
  + $(COPY) $(WISH) "$(BIN_INSTALL_DIR)"
  + @$(MKDIR) "$(LIB_INSTALL_DIR)"
  + $(COPY) $(TKLIB) "$(LIB_INSTALL_DIR)"
  + 
  + install-libraries:
  + @$(MKDIR) "$(INCLUDE_INSTALL_DIR)"
  + @$(MKDIR) "$(INCLUDE_INSTALL_DIR)/X11"
  + $(COPY) "$(ROOT)/generic/tk.h"             "$(INCLUDE_INSTALL_DIR)"
  + $(COPY) "$(ROOT)/generic/tkDecls.h"        "$(INCLUDE_INSTALL_DIR)"
  + $(COPY) "$(ROOT)/generic/tkIntXlibDecls.h" "$(INCLUDE_INSTALL_DIR)"
  + ifeq "$(findstring xcopy, $(XCOPY))" ""
  + -$(MKDIR) "$(INCLUDE_INSTALL_DIR)/X11"
  + $(COPY) "$(ROOT)"/xlib/X11/*.h            "$(INCLUDE_INSTALL_DIR)/X11"
  + else
  + $(XCOPY) "$(ROOT)"/xlib/X11/*.h            "$(INCLUDE_INSTALL_DIR)/X11"
  + endif
  + @$(MKDIR) "$(SCRIPT_INSTALL_DIR)"
  + @$(MKDIR) "$(SCRIPT_INSTALL_DIR)/images"
  + @$(MKDIR) "$(SCRIPT_INSTALL_DIR)/demos"
  + @$(MKDIR) "$(SCRIPT_INSTALL_DIR)/demos/images"
  + ifneq "$(findstring xcopy, $(XCOPY))" ""
  + $(XCOPY) "$(ROOT)/library"              "$(SCRIPT_INSTALL_DIR)"
  + else
  + $(COPY) "$(ROOT)"/library/*.tcl         "$(SCRIPT_INSTALL_DIR)"
  + $(COPY) "$(ROOT)"/library/tclIndex      "$(SCRIPT_INSTALL_DIR)"
  + $(COPY) "$(GENERICDIR)"/prolog.ps       "$(SCRIPT_INSTALL_DIR)"
  + $(COPY) "$(ROOT)"/unix/tkAppInit.c      "$(SCRIPT_INSTALL_DIR)"
  + $(XCOPY) "$(ROOT)/library/images"       "$(SCRIPT_INSTALL_DIR)"
  + $(XCOPY) "$(ROOT)/library/demos"        "$(SCRIPT_INSTALL_DIR)"
  + endif
  + 
  + $(TKLIB): $(TKDLL) $(TKSTUBLIB)
  + 
  + #$(TKSTUBLIB): $(TKSTUBOBJS)
  + #        $(lib32) /out:$@ $(TKSTUBOBJS)
  + 
  + $(TKSTUBLIB): $(TKSTUBOBJS)
  + $(lib32) crv $@ $(TKSTUBOBJS)
  + 
  + #$(TKDLL): $(TKOBJS) $(TMPDIR)/tk.res
  + #set LIB=$(TOOLS32)/lib
  + #       $(link32) $(ldebug) $(dlllflags)  + #-out:$@ $(TMPDIR)/tk.res $(TCLLIBDIR)/$(TCLSTUBLIB)  + #$(guilibsdll) @<<
  + #$(TKOBJS)
  + #<<
  + 
  + ifeq "$(strip $(LD_SUPPORTS_SHARED))" "yes"
  + $(TKDLL): $(TKOBJS) $(TMPDIR)/tk.res.o
  + $(link32) $(ldebug) $(dlllflags)  + -o $@ $(TMPDIR)/tk.res.o  + -Wl,--out-implib,$(TKLIB)  + -Wl,--output-def,tk83.def  + $(TKOBJS)  + $(TCLLIBDIR)/$(TCLSTUBLIB)  + $(guilibsdll)
  + else
  + $(TKDLL): $(TKOBJS) $(TMPDIR)/tk.res.o
  + $(dllwrap) $(dllwrap_flags) $(ldebug) $(dlllflags)  + -o $@ $(TMPDIR)/tk.res.o  + --output-lib $(TKLIB)  + --output-def tk83.def  + $(TKOBJS)  + $(TCLLIBDIR)/$(TCLSTUBLIB)  + $(guilibsdll)
  + endif
  + 
  + $(TKPLUGINLIB): $(TKPLUGINDLL)
  + 
  + #$(TKPLUGINDLL): $(TKOBJS) $(TMPDIR)/tk.res
  + #set LIB=$(TOOLS32)/lib
  + #        $(link32) $(ldebug) $(dlllflags)  + #-out:$@ $(TMPDIR)/tk.res $(TCLLIBDIR)/$(TCLPLUGINLIB)  + #$(guilibsdll) @<<
  + #$(TKOBJS)
  + #<<
  + 
  + $(WISH): $(WISHOBJS) $(TKLIB) $(TMPDIR)/wish.res.o
  + $(link32) $(ldebug) $(guilflags) $(TMPDIR)/wish.res.o -o $@  + $(WISHOBJS) $(TCLLIBDIR)/$(TCLLIB) $(TKLIB) $(guilibsdll) 
  + 
  + $(WISHC): $(WISHOBJS) $(TKLIB) $(TMPDIR)/wish.res.o
  + $(link32) $(ldebug) $(conlflags) $(TMPDIR)/wish.res.o -o $@  + $(WISHOBJS) $(TCLLIBDIR)/$(TCLLIB) $(TKLIB) $(guilibsdll) 
  + 
  + $(WISHP): $(WISHOBJS) $(TKPLUGINLIB) $(TMPDIR)/wish.res.o
  + $(link32) $(ldebug) $(guilflags) $(TMPDIR)/wish.res.o -o $@  + $(guilibsdll) $(TCLLIBDIR)/$(TCLPLUGINLIB)  + $(TKPLUGINLIB) $(WISHOBJS) 
  + 
  + $(TKTEST): $(TKTESTOBJS) $(TKLIB) $(TMPDIR)/wish.res.o
  + $(link32) $(ldebug) $(guilflags) $(TMPDIR)/wish.res.o -o $@  + $(guilibsdll) $(TCLLIBDIR)/$(TCLLIB) $(TKLIB) $(TKTESTOBJS)
  + 
  + $(CAT32): $(TCLDIR)/win/cat.c
  + $(cc32) $(CON_CFLAGS) -o $(TMPDIR)/cat.o $?
  + $(link32) $(conlflags) -o $@ -Wl,--stack,0x16384  + $(TMPDIR)/cat.o $(conlibs)
  + 
  + #
  + # Regenerate the stubs files.
  + #
  + 
  + genstubs:
  + tclsh$(VERSION) $(TCLDIR)/tools/genStubs.tcl $(GENERICDIR)  + $(GENERICDIR)/tk.decls $(GENERICDIR)/tkInt.decls
  + 
  + #
  + # Special case object file targets
  + #
  + 
  + $(TMPDIR)/testMain.o: $(ROOT)/win/winMain.c
  + $(cc32) $(WISH_CFLAGS) -DTK_TEST -o $@ $?
  + 
  + $(TMPDIR)/tkTest.o: $(ROOT)/generic/tkTest.c
  + $(cc32) $(WISH_CFLAGS) -o $@ $?
  + 
  + $(TMPDIR)/tkSquare.o: $(ROOT)/generic/tkSquare.c
  + $(cc32) $(WISH_CFLAGS) -o $@ $?
  + 
  + $(TMPDIR)/winMain.o: $(ROOT)/win/winMain.c
  + $(cc32) $(WISH_CFLAGS) -o $@ $?
  + 
  + $(TMPDIR)/tkStubLib.o : $(GENERICDIR)/tkStubLib.c
  + $(cc32) $(TK_CFLAGS) -DSTATIC_BUILD -o $@ $?
  + 
  + #
  + # Implicit rules
  + #
  + 
  + #{$(XLIBDIR)}.c{$(TMPDIR)}.o:
  + #$(cc32) -DDLL_BUILD -DBUILD_tk $(TK_CFLAGS) -Fo$(TMPDIR)/ $<
  + #
  + #{$(GENERICDIR)}.c{$(TMPDIR)}.o:
  + #$(cc32) -DDLL_BUILD -DBUILD_tk $(TK_CFLAGS) -Fo$(TMPDIR)/ $<
  + #
  + #{$(WINDIR)}.c{$(TMPDIR)}.o:
  + #$(cc32) -DDLL_BUILD -DBUILD_tk $(TK_CFLAGS) -Fo$(TMPDIR)/ $<
  + #
  + #{$(ROOT)/unix}.c{$(TMPDIR)}.o:
  + #$(cc32) -DDLL_BUILD -DBUILD_tk $(TK_CFLAGS) -Fo$(TMPDIR)/ $<
  + #
  + #{$(RCDIR)}.rc{$(TMPDIR)}.res:
  + #$(rc32) -fo $@ -r -i "$(GENERICDIR)" -i "$(TOOLS32)/include"  + #-i "$(TCLDIR)/generic" $<
  + 
  + %.o : %.c
  + $(cc32) -DDLL_BUILD -DBUILD_tk $(TK_CFLAGS) -o $@ $<
  + 
  + %.res.o : %.rc
  + $(rc32) $(rc32_flags) -o $@ --include "$(GENERICDIR)"  + --include $(RCDIR)  + --include "$(TCLDIR)/generic" $<
  + 
  + clean:
  + -@$(RM) $(OUTDIR)/*.exp 
  + -@$(RM) $(OUTDIR)/*.lib 
  + -@$(RM) $(OUTDIR)/*.dll 
  + -@$(RM) $(OUTDIR)/*.exe
  + -@$(RM) $(OUTDIR)/*.pdb
  + -@$(RM) $(TMPDIR)/*.pch
  + -@$(RM) $(TMPDIR)/*.o
  + -@$(RM) $(TMPDIR)/*.res.o
  + -@$(RM) $(TMPDIR)/*.exe
  + 
  + # dependencies
  + 
  + $(TMPDIR)/tk.res.o:  +     $(RCDIR)/buttons.bmp  +     $(RCDIR)/cursor*.cur  +     $(RCDIR)/tk.ico
  + 
  + $(GENERICDIR)/default.h: $(WINDIR)/tkWinDefault.h
  + $(GENERICDIR)/tkButton.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkCanvas.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkEntry.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkFrame.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkListbox.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkMenu.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkMenubutton.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkMessage.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkScale.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkScrollbar.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkText.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkTextIndex.c: $(GENERICDIR)/default.h
  + $(GENERICDIR)/tkTextTag.c: $(GENERICDIR)/default.h
  + 
  + $(GENERICDIR)/tkText.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextBTree.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextDisp.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextDisp.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextImage.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextIndex.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextMark.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextTag.c: $(GENERICDIR)/tkText.h
  + $(GENERICDIR)/tkTextWind.c: $(GENERICDIR)/tkText.h
  + 
  + $(GENERICDIR)/tkMacWinMenu.c: $(GENERICDIR)/tkMenu.h
  + $(GENERICDIR)/tkMenu.c: $(GENERICDIR)/tkMenu.h
  + $(GENERICDIR)/tkMenuDraw.c: $(GENERICDIR)/tkMenu.h
  + $(WINDIR)/tkWinMenu.c: $(GENERICDIR)/tkMenu.h
  + 
  *** win/aclocal.m4.origThu Feb 10 12:11:05 2000
  --- win/aclocal.m4Wed Feb 23 20:21:11 2000
  ***************
  *** 171,177 ****
        AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available [--disable-gcc]],
    [ok=$enableval], [ok=no])
        if test "$ok" = "yes"; then
  ! CC=gcc
    AC_PROG_CC
        else
    CC=cl
  --- 171,180 ----
        AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available [--disable-gcc]],
    [ok=$enableval], [ok=no])
        if test "$ok" = "yes"; then
  ! # Let user override.
  ! if test -z "$CC"; then
  !     CC=gcc
  ! fi
    AC_PROG_CC
        else
    CC=cl
  ***************
  *** 297,303 ****
        fi
    ])

  - 
    #--------------------------------------------------------------------
    # SC_CONFIG_CFLAGS
    #
  --- 300,305 ----
  ***************
  *** 320,339 ****
    #    CFLAGS_WARNING
    #    LDFLAGS_DEBUG
    #    LDFLAGS_OPTIMIZE
  ! #    PATHTYPE
    #    CC_OBJNAME
    #    CC_EXENAME
    #
  - #Defines the following vars for non-gcc compilers
    #    SHLIB_LD
    #    SHLIB_LD_LIBS
    #    LIBS
    #    AR
    #    MAKE_LIB
    #    MAKE_EXE
    #    MAKE_DLL
    #
    #    LIBSUFFIX
    #    LIBRARIES
    #    EXESUFFIX
    #    DLLSUFFIX
  --- 322,346 ----
    #    CFLAGS_WARNING
    #    LDFLAGS_DEBUG
    #    LDFLAGS_OPTIMIZE
  ! #LDFLAGS_CONSOLE
  ! #LDFLAGS_WINDOW
    #    CC_OBJNAME
    #    CC_EXENAME
  + #    PATHTYPE
  + #VPSEP
  + #CYGPATH
    #
    #    SHLIB_LD
    #    SHLIB_LD_LIBS
    #    LIBS
  + #LIBS_GUI
    #    AR
    #    MAKE_LIB
    #    MAKE_EXE
    #    MAKE_DLL
    #
    #    LIBSUFFIX
  + #    LIBPREFIX
    #    LIBRARIES
    #    EXESUFFIX
    #    DLLSUFFIX
  ***************
  *** 346,369 ****
        # set various compiler flags depending on whether we are using gcc or cl

        if test "${GCC}" = "yes" ; then
    CFLAGS_DEBUG=-g
  ! CFLAGS_OPTIMIZE=-O
    CFLAGS_WARNING="-Wall -Wconversion"
    LDFLAGS_DEBUG=-g
  ! LDFLAGS_OPTIMIZE=-O
  ! PATHTYPE=-u

    # Specify the CC output file names based on the target name
    CC_OBJNAME="-o \[$]@"
    CC_EXENAME="-o \[$]@"
        else
    SHLIB_LD="link -dll -nologo"
    SHLIB_LD_LIBS="user32.lib advapi32.lib"
    LIBS="user32.lib advapi32.lib"
    AR="lib -nologo"
    RC="rc"
    MAKE_LIB="\${AR} -out:\[$]@"
    MAKE_EXE="\${CC} -Fe\[$]@"

    if test "${SHARED_BUILD}" = "0" ; then
        # static
  --- 353,466 ----
        # set various compiler flags depending on whether we are using gcc or cl

        if test "${GCC}" = "yes" ; then
  + SHLIB_LD=""
  + SHLIB_LD_LIBS=""
  + LIBS=""
  + LIBS_GUI="-lgdi32 -lcomdlg32"
  + AR="${AR-ar}"
  + STLIB_LD="${AR-ar}"
  + RC="${WINDRES-windres}"
  + MAKE_LIB="\${AR} crv \[$]@"
  + MAKE_EXE="\${CC} -o \[$]@"
  + LIBPREFIX="lib"
  + 
  + if "$CC" -v 2>&1 | egrep '\/gcc-lib\/i[[3-6]]86[[^\/]]*-cygwin' >/dev/null; then
  +     mno_cygwin="yes"
  +     extra_cflags="-mno-cygwin"
  +     extra_ldflags="-mno-cygwin"
  + else
  +     mno_cygwin="no"
  +     extra_cflags=""
  +     extra_ldflags=""
  + fi
  + 
  + if test "$cross_compiling" = "yes" -o "$mno_cygwin" = "yes"; then
  +     PATHTYPE=''
  +     CYGPATH='echo '
  +     VPSEP=':'
  + else
  +     PATHTYPE='-w'
  +     CYGPATH='cygpath'
  +     VPSEP=';'
  + fi
  + 
  + if test "${SHARED_BUILD}" = "0" ; then
  +     # static
  +             AC_MSG_RESULT([using static flags])
  +     runtime=
  +     MAKE_DLL="echo "
  +     LIBSUFFIX="s\${DBGX}.a"
  +     LIBRARIES="\${STATIC_LIBRARIES}"
  +     EXESUFFIX="s\${DBGX}.exe"
  +     DLLSUFFIX=""
  + else
  +     # dynamic
  +             AC_MSG_RESULT([using shared flags])
  + 
  +     # check to see if ld supports --shared. Libtool does a much
  +     # more extensive test, but not really needed in this case.
  +     if test -z "$LD"; then
  + ld_prog="`(${CC} -print-prog-name=ld) 2>/dev/null`"
  + if test -z "$ld_prog"; then
  +   ld_prog=ld
  + else
  +   # get rid of the potential '\r' from ld_prog.
  +   ld_prog="`(echo $ld_prog | tr -d '\015' | sed 's,\\\\,\\/,g')`"
  + fi
  + LD="$ld_prog"
  +     fi
  + 
  +     AC_MSG_CHECKING([whether $ld_prog supports -shared option])
  + 
  +     # now the ad-hoc check to see if GNU ld supports --shared.
  +     if "$LD" --shared 2>&1 | egrep ': -shared not supported' >/dev/null; then
  + ld_supports_shared="no"
  + SHLIB_LD="${DLLWRAP-dllwrap}"
  +     else
  + ld_supports_shared="yes"
  + SHLIB_LD="${CC} -shared"
  +     fi
  +     AC_MSG_RESULT([$ld_supports_shared])
  + 
  +     runtime=
  +     # Add SHLIB_LD_LIBS to the Make rule, not here.
  +     MAKE_DLL="\${SHLIB_LD} \$(LDFLAGS) -o \[$]@ ${extra_ldflags}"
  +     if test "${ld_supports_shared}" = "yes"; then
  +         MAKE_DLL="${MAKE_DLL} -Wl,--out-implib,\$(patsubst %.dll,lib%.a,\[$]@)"
  +     else
  +         MAKE_DLL="${MAKE_DLL} --output-lib \$(patsubst %.dll,lib%.a,\[$]@)"
  +     fi
  +     LIBSUFFIX="\${DBGX}.a"
  +     DLLSUFFIX="\${DBGX}.dll"
  +     EXESUFFIX="\${DBGX}.exe"
  +     LIBRARIES="\${SHARED_LIBRARIES}"
  + fi
  + 
  + EXTRA_CFLAGS="${extra_cflags}"
    CFLAGS_DEBUG=-g
  ! CFLAGS_OPTIMIZE=-O2
    CFLAGS_WARNING="-Wall -Wconversion"
    LDFLAGS_DEBUG=-g
  ! LDFLAGS_OPTIMIZE=

    # Specify the CC out

  PatchFiles:
  Makefile.in Makefile.ming (new file) aclocal.m4 configure.in



  I'm marking this RFE as duplicate with respect to 5844.

  - eric
   
  -- 06/13/2000 ericm


tkt_uuid: 2507417fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Fix for image clipping on Windows menus
comment:
  Here is a relatively simple fix for the problems
  displaying images on Windows menus, when menu animation
  effects are turned on. See bugs #1329198 and #456299.

  In TkpDrawMenuEntry the contents for each menu entry are
  drawn to a compatible bitmap first.  The bitmap is then
  copied to the output menu.  This avoids the problems with
  clipping when drawing directly to an animated menu.  The
  draw to compatible bitmap plus copy doesn't appear to be
  a big deal, performance-wise.

  I have removed the previous work-around of 2006-09-21,
  which disabled animation for top-level menus with images.

  I attach updated versions of win/tkWinMenu.c for Tk 8.5.6
  and the current CVS HEAD revision 1.62

  The default setting is animated menus turned on in modern
  windows versions, making Tk apps look poor, so this is an
  important issue to address.


tkt_uuid: 2159857fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Wont Fix
title: OSX no checkmark in menu
comment:
  using {set ::tk::mac::useCustomMDEF 1}, checkbutton and radiobutton menu entries do not display their checkmarks.

  using {set ::tk::mac::useCustomMDEF 0}, they will.

  I noticed this on a PPC Mac running OSX 10.5.5 and tcl/tk 8.5.4

  On an Intel Mac running OSX 10.5.5 and tcl/tk 8.5.0 the checkmarks are displayed properly.


  kind regards, uwe


tkt_uuid: 220168ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_GetVRootGeometry API
comment:
  OriginalBugID: 1867 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




  04/28/1999 14:32 - kenj - Already documented in GetVRoot.3.


tkt_uuid: 488951ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 7 High
foundin: obsolete: 8.3.3
resolution: Fixed
title: $canvas postscript hangs wish Win98
comment:
  On Windows 98 SE (only platform tested), the following script causes wish to hang (and not show 
  up in the Windows process list), and hog system resources so that you need to do a hard reboot of 
  Windows (Ctrl-Alt-Del, Ctrl-Alt-Del). System: ActiveTcl8.3.3.3. No extensions loaded.

  canvas .c
  text .c.t
  .c.t insert end "Test\n"
  pack .c -fill both -expand 1
  .c create window 50 50 -window .c.t
  .c postscript

  results in a popup saying "GetImage not implemented" followed by invalid page fault and hang.


tkt_uuid: 1090719fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Invalid
title: input from numeric pad always dropped when numlock off
comment:
  In IDLE, the Python IDE (integrated development environment, 
  written in Tk), the behaviour of the direction keys on the numpad 
  is inconsistent when numlock is turned off.  
  Home/End/PgUp/PgDn and the arrow keys work fine in some 
  applications (gedit), but do not work in Python's IDLE. 
  By not work, I mean: input is silently dropped. 
   
  How reproducible: 
  Always 
   
  Steps to Reproduce: 
  1. Turn off numlock. 
  3. Open gedit, type in garbage, use direction keys on 
  numpad to move around. 
  4. Open idle, type in garbage, attempt to use direction 
  keys on numpad to move around. It fails.     
   
  Actual Results:  Intense frustration for people who 
  have been using the numeric keypad as direction keys 
  for decades! 
   
  Expected Results:  When numlock is off, the direction 
  keys on the numpad should function in the same manner 
  as the dedicated direction keys. 
   
  I reported this to Python, but they say it is a Tk problem, and 
  that it is my responsibility to post the bug here.  Bugs item 
  #1074333. 
   
  https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 
   
  This problem has also been reported to RedHat, see  
   
  http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. 


tkt_uuid: 1887149fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Works For Me
title: menus added after system menu do not appear in menubar
comment:
  Running 8.5 (ActiveTcl) in Win XP

  If you try to add new menus to a menubar after you've added the magic ".system" menu, they will not appear.  The widget's menu command is created etc., and no errors are generated.  

  For example, the following will create a menubar for the main window, which will include the File menu, but the Edit menu will not appear in the menubar.

  menu .m
  . configure -menu .m
  .m add cascade -label File -menu [menu .m.f]
  .m add cascade menu [menu .m.system]
  .m add cascade -label Edit -menu [menu .m.e]


tkt_uuid: 1804565fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: Fixed
title: Provide all TIP#145 fonts on all platforms
comment:
  The script lib/tk8.5/ttk/fonts.tcl is executed at startup.  On systems that do not implement TIP#145, lib/tk8.5/ttk/fonts.tcl provides substitute definitions for _some_ of the TIP#145 fonts.  These definitions are available to Tk as well as to Ttk.

  Tk 8.5b1 under X11 does not implement TIP#145.  This leads, for example, to inappropriate font choices in the Tk widget demo when Tk is built with --enable-xft.

  The main purpose of the patch is to make lib/tk8.5/ttk/fonts.tcl supply substitutes for _all_ the TIP#145 fonts.

  The patch also:
  - makes the named fonts slightly larger for X11.
  - for TkCaptionFont under win32, changes the font family to Trebuchet if available (to agree with the implementation of TIP#145 in 8.5b1).

  Tested on X11 with and without xft, and on win32.  I do not have access to a Mac for testing.


tkt_uuid: 220145ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: under Irix 6.2 I get segmentation violation in demos. 8.0.3 worked fine
comment:
  OriginalBugID: 1535 Bug
  Version: 8.0.5
  SubmitDate: '1999-03-18'
  LastModified: '1999-11-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: IRIX
  OSVersion: 6.2
  Machine: Other
  ClosedDate: '1999-11-16'


  Name:
  paul lansky

  CVS:
  March 16

  ReproducibleScript:
      /usr/local/lib/tk8.0/demos/widget
      
      gets segmentation violation, as do all the other demos there.
      
      I had no problems with 8.0.3 under Irix 6.2


  Was any change made in the compiler?  There are known problems
  with various versions of gcc on IRIX.  Also, some improved config
  stuff is in 8.2. 
  -- 09/20/1999 hobbs
  Verified that Tcl/Tk 8.0.5 builds and runs the demos fine on
  an IRIX 6.3 machine with the MIPS compiler. 
  -- 11/16/1999 hobbs


tkt_uuid: 745189ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: Works For Me
title: tkfbox causes error on fork
comment:
  I think lines 849 and 853 of tkfbox.tcl need a catch
  round them (otherwise "configure -state" can be, and
  is,  called on a label).  Anyway, when the catch is
  added it fixes the problem and our existing code works
  fine again. Was their a change here? Platform is Linux
  kernel 2.4.20 (SuSE 8.2 Pro). Seems to work fine when
  there are no children.


tkt_uuid: 220915ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 7 High
foundin: obsolete: 8.5a4
resolution: Fixed
title: Canvas Item documentation
comment:
  OriginalBugID: 5397 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Linux-Red Hat
  Machine: P II - 350,  384M ram, ATI expert 8M running at 1280x1024


  Name:
  Spiros J Boucouris

  Extensions:
  none

  ReproducibleScript:
  For custom canvas items to use the the object interface, alwaysRedraw must be or'ed
  with TK_CONFIG_OBJS.  I did not find that documented anywhere.  Or'ing TK_CONFIG_OBJS
  with flags is documented in the header.  In short, the object interface requires multiple "configurations"
  in the user's code.

  ObservedBehavior:
  Provide a reasonably complete (point form) guide for using the object interface with canvas items.  Presently, even the header files do not have all the information.  One has to dig into tkCanvas.c.

  DesiredBehavior:
  I would like to see a cleaner object interface for custom canvas items (similar to the dual
  cmd / objcmd used in Tcl.  Presently the code does all sorts of casts based on information
  the user must provide at multiple places.  In short I would like an interface no less robust
  than the previous (ono-object) one.


tkt_uuid: 220214ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: we occassionally get a tk internal error which freezes the script and users have to restart
comment:
  OriginalBugID: 2373 Bug
  Version: 8.0.3
  SubmitDate: '1999-07-16'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedInVersion: 8.2
  ClosedDate: '1999-08-20'


  Name:
  danny chen

  Extensions:
  none

  CustomShell:
  using prowish80

  ObservedBehavior:
  users occassionally get the following error message:
      
      Error: Can't read "tkprv(relief)": no such element in array
      
      after getting this message, our the script freezes and the users have to
      restart.  this is not one of our variables so it must be a tk internal
      variable.  i looked in the tk libraries and can't find any mention of
      it.
      can you tell us when/why this would happen?



  tkprv would have to come from some other code.  There is a tkPriv
  array that is used.  Some problems have been noted over time with
  various aspects of this, but all known ones have been fixed. 
  -- 08/20/1999 hobbs


tkt_uuid: 1095967fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: report libdir in tkConfig.sh
comment:
  Add the line to tkConfig.sh.in

  TK_LIBDIR='@libdir@'

  so that applications linking the
  Tk library can know where it's
  found.


tkt_uuid: 3599928fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: Fixed
title: Tk 8.5.13 fails to build on Solaris 5
comment:
  Recently Tk switched from using XKeycodeToKeysym to XkbKeycodeToKeysym, defined in X11/XKBlib.h. However, that header file is not available on Solaris 5 and as a result Tk fails to build on this platform.

  The availability of X11/XKBlib.h should be checked by configure, and an appropriate fallback should be used if the header file is not available.


tkt_uuid: 1029349fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: makefile.vc env checks fail under vc7
comment:
  the environment checks in the tk makefile.vc differ
  from the tcl makefile. tcl works under vc7 but tk does
  not.

  tk:

  !if "$(MSDEVDIR)" == ""

  tcl:

  !if !defined(MSDEVDIR) && !defined(MSVCDIR)


tkt_uuid: 220882ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.0.4
resolution: Works For Me
title: Inconsistent behavior between NT and X11
comment:
  OriginalBugID: 3686 Bug
  Version: 8.0.4
  SubmitDate: '1999-11-24'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT
  OSVersion: solaris/linux/NT/98
  Machine: E5500 and PC's


  Name:
  steve szabo

  Extensions:
  BLT and Tcl-DP

  ReproducibleScript:
  button ${PARENT}frameToolBar.labelIcons.buttonHelp  -image tool_help_icon -bd 1 -padx 15 -pady 7 -relief flat  -command { cssQA:Help ${PARENT} }

  when ${PARENT} moves or is covered by a pop-up the image "tool_help_icon" is
  hidden from view. you must move the mouse over the button to re-draw the image.

  note that under X11 this does not happen

  ObservedBehavior:
  when ${PARENT} moves or is covered by a pop-up the image "tool_help_icon" is
  hidden from view. you must move the mouse over the button to re-draw the image.

  note that under X11 this does not happen

  DesiredBehavior:
  same behavior under NT as under X11


tkt_uuid: 1591497fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: unixWm test suite case 4,48,50 failure tk cvs head
comment:
  tk cvs head, built on solaris 9 with sun c compiler,
  and test suite display via exceed 10.0.0.12 on win xp.
  Window manager is Sun GNOME metacity.

  unixWm.test

  ==== unixWm-4.1 moving window while withdrawn FAILED
  ==== Contents of test case:

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+57+80
  ---- Result should have been (exact matching):
  100x150+20+80
  ==== unixWm-4.1 FAILED

  ==== unixWm-4.3 moving window while withdrawn FAILED
  ==== Contents of test case:

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+57+39
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED

  ==== unixWm-48.13 ParseGeometry procedure, resize
  causes window to move FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200
      wm geom .t +0+0
      update
      wm geom .t -0-0
      update
      set x [winfo x .t]
      set y [winfo y .t]
      wm geometry .t 150x300
      update
      list [expr [winfo x .t] - $x] [expr [winfo y .t] -
  $y]  [winfo width .t] [winfo
   height .t]

  ---- Result was:
  0 0 150 300
  ---- Result should have been (exact matching):
  50 -100 150 300
  ==== unixWm-48.13 FAILED

  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a
  toplevel, x-coords FAILED
  ==== Contents of test case:

      deleteWindows
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +40+0
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg red
      wm geom .t2 +140+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x - 30] [expr $y +
  250]]  [winfo containing [expr
   $x - 1] [expr $y + 250]]  [winfo containing $x [expr
  $y + 250]]  [winfo containing
   [expr $x + 99] [expr $y + 250]]  [winfo containing
  [expr $x + 100] [expr $y + 250]
  ]  [winfo containing [expr $x + 199] [expr $y + 250]] 
  [winfo containing [expr $x +
   200] [expr $y + 250]]  [winfo containing [expr $x +
  220] [expr $y + 250]]

  ---- Result was:
  {} {} {} .t .t .t .t .t
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED

  ==== unixWm-50.8 Tk_CoordsToWindow procedure, more
  basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 400 -height 300 -bg green
      wm geom .t +0+0
      frame .t.f -width 200 -height 100 -bd 2 -relief raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 200 -height 100 -bd 2 -relief
  raised
      place .t.f.f -x 100 -y 0
      update
      set x [winfo rooty .t]
      set y [expr [winfo rooty .t] + 150]
      list [winfo containing [expr $x + 50] $y]  [winfo
  containing [expr $x + 150] $y
  ]  [winfo containing [expr $x + 250] $y]  [winfo
  containing [expr $x + 350] $y]  [w
  info containing [expr $x + 450] $y]
  ---- Result was:
  .t.f .t.f.f .t {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED

  ==== unixWm-50.10 Tk_CoordsToWindow procedure, unmapped
  windows FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      frame .t.f -width 150 -height 150 -bd 2 -relief raised
      place .t.f -x 25 -y 25
      tkwait visibility .t.f
      set result [list [winfo containing 100 100]]
      place forget .t.f
      update
      lappend result [winfo containing 100 100]

  ---- Result was:
  .t .t
  ---- Result should have been (exact matching):
  .t.f .t
  ==== unixWm-50.10 FAILED


tkt_uuid: 3572437fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Support of setAccessoryView on OS X for -filetypes
comment:
  The OS X versions of tk_get*File (Tk-Cocoa) do not display -filetypes comboboxes/menubuttons when the -filetypes option is specified. The list of possible files is merely filtered. On Linux and Windows a combobox/menubutton is shown and the user can choose a filetype.

  On OSX, the setAccessoryView task of the NSSavePanel and NSOpenPanel do support this kind of feature:

  http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSavePanel_Class/Reference/Reference.html#//apple_ref/occ/cl/NSSavePanel

  http://www.cocoabuilder.com/archive/cocoa/295153-custom-nssavepanel.html

  It looks as if this is relatively simple to implement and it would bring the OS X file dialogs to the same level as for the other platforms. If no -filetypes are specified, the accessory view could be hidden.

  In the future, this accessory view culd even be used to display more options like checkboxes, text and other stuff.


tkt_uuid: 1319720fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: Tk_DeleteOptionTable leaks & Tk_CreateOptionTable short allo
comment:
  Tk_CreateOptionTable allocates the option table one 
  entry too short, since it mis-calculates number of 
  options

  Tk_DeleteOptionTable does not delete the last option's 
  default value causing a memory leak.

  patch included


tkt_uuid: 1822601fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: Fixed
title: Text Widgets Peering and window resize
comment:
  The "Text Widget Peering" demo does not resize the widgets when the toplevel is made bigger. Just add the line

  grid columnconfigure $w 0 -weight 1

  as the last line of the demo and resizing is better.

  The order in which the widgets are gridded makes that the buttons disappear first when the window is made smaller. This should be fixed too, IMO.


tkt_uuid: 220893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: final: 8.2.3
resolution: Works For Me
title: some errors in the testsuite run
comment:
  OriginalBugID: 4171 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-25'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE


  Name:
  Joachim Zaers

  ObservedBehavior:
  LD_LIBRARY_PATH=`pwd`:/usr/local/src/tcl8.2.3/unix:;  export LD_LIBRARY_PATH;  LIBPATH=`pwd`:/usr/local/src/tcl8.2.3/unix:; export LIBPATH;  SHLIB_PATH=`pwd`:/usr/local/src/tcl8.2.3/unix:;  export SHLIB_PATH;  TCL_LIBRARY=/usr/local/src/tcl8.2.3/library; export TCL_LIBRARY;  TK_LIBRARY=/usr/local/src/tk8.2.3/library; export TK_LIBRARY;  ./tktest ./../tests/all.tcl -geometry +0+0
  Tk 8.2.0 tests running in interp:  /usr/local/src/tk8.2.3/unix/tktest
  Tests running in working dir:  /usr/local/src/tk8.2.3/unix
  Tests began at Tue Feb 08 12:28:46 MET 2000
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  clipboard.test
  clrpick.test
  cmds.test
  color.test
  config.test
  cursor.test
  entry.test

  ==== entry-3.81 EntryWidgetCmd procedure, "xview" widget command FAILED
  ==== Contents of test case:

      # UTF
      # If Tcl_NumUtfChars wasn't used, wrong answer would be:
      # {0.106383 0.319149} {0.117021 0.351064} {0.117021 0.351064}

      set x {}
      .e xview moveto .1
      lappend x [.e xview]
      .e xview moveto .11
      lappend x [.e xview]
      .e xview moveto .12
      lappend x [.e xview]

  ---- Result was:
  {0.0957447 0.255319} {0.106383 0.265957} {0.117021 0.329787}
  ---- Result should have been:
  {0.0957447 0.308511} {0.106383 0.319149} {0.117021 0.329787}
  ==== entry-3.81 FAILED

  event.test
  filebox.test
  focus.test
  focusTcl.test
  font.test
  frame.test
  geometry.test
  get.test
  grid.test
  id.test
  image.test
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  skipping: Mac only tests...
  macMenu.test
  skipping: Mac only tests...
  macWinMenu.test
  macscrollbar.test
  skipping: Mac only tests...
  main.test
  menu.test
  menuDraw.test
  menubut.test
  msgbox.test
  obj.test
  oldpack.test
  option.test
  pack.test
  place.test
  raise.test
  safe.test
  scale.test
  scrollbar.test
  select.test
  send.test
  Your X server is insecure, so "send" can't be used; skipping "send" tests.
  text.test
  textBTree.test
  textDisp.test
  textImage.test
  textIndex.test
  textMark.test
  textTag.test
  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test

  ==== unixEmbed-3.4 ContainerEventProc procedure, geometry requests FAILED
  ==== Contents of test case:

      foreach w [winfo child .] {
  catch {destroy $w}
      }
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      dobg "set w1 [winfo id .f1]"
      dobg {
  eval destroy [winfo child .]
  toplevel .t1 -use $w1
      }
      update
      dobg {
  .t1 configure -width 300 -height 80
      }
      update
      list [winfo width .f1] [winfo height .f1] [dobg {wm geometry .t1}]

  ---- Result was:
  200 50 {bad window path name ".t1"}
  ---- Result should have been:
  300 80 300x80+0+0
  ==== unixEmbed-3.4 FAILED

  ==== unixEmbed-7.2 TkpRedirectKeyEvent procedure, don't forward keystroke width FAILED
  ==== Contents of test case:

      foreach w [winfo child .] {
  catch {destroy $w}
      }
      frame .f1 -container 1 -width 200 -height 50
      pack .f1
      dobg "set w1 [winfo id .f1]"
      dobg {
  eval destroy [winfo child .]
  toplevel .t1 -use $w1
      }
      update
      focus -force .f1
      update
      bind . <KeyPress> {lappend x {key %A}}
      set x {}
      set y [dobg {
  update
  bind .t1 <KeyPress> {lappend y {key %A}}
  set y {}
  event generate .t1 <KeyPress> -keysym b
  set y
      }]
      update
      bind . <KeyPress> {}
      list $x $y

  ---- Result was:
  {} {bad window path name ".t1"}
  ---- Result should have been:
  {} {{key b}}
  ==== unixEmbed-7.2 FAILED

  ==== unixEmbed-8.1 TkpClaimFocus procedure FAILED
  ==== Contents of test case:

      foreach w [winfo child .] {
  catch {destroy $w}
      }
      frame .f1 -container 1 -width 200 -height 50
      frame .f2 -width 200 -height 50
      pack .f1 .f2
      dobg "set w1 [winfo id .f1]"
      dobg {
  eval destroy [winfo child .]
  toplevel .t1 -use $w1 -highlightthickness 2 -bd 2 -relief sunken
      }
      focus -force .f2
      update
      list [dobg {
  focus .t1
  set x [list [focus]]
  update
  after 500
  update
  lappend x [focus]
      }] [focus]

  ---- Result was:
  {bad window path name ".t1"} .f2
  ---- Result should have been:
  {{} .t1} .f1
  ==== unixEmbed-8.1 FAILED

  unixFont.test
  unixMenu.test
  unixSelect.test
  unixSend.test
  Your X server is insecure, so "send" can't be used; skipping "send" tests.
  unixWm.test

  ==== unixWm-51.10 TkWmRestackToplevel procedure, don't move window that's already in the right place FAILED
  ==== Contents of test case:

      makeToplevels
      raise .raise1
      set time [lindex [time {raise .raise1}] 0]
      expr {$time < 2000000}

  ---- Result was:
  0
  ---- Result should have been:
  1
  ==== unixWm-51.10 FAILED

  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  skipping: tests require the testwinevent command
  winFont.test
  winMenu.test
  winSend.test
  skipping: Windows only tests...
  winWm.test
  window.test
  winfo.test
  xmfbox.test

  Tests ended at Tue Feb 08 12:36:39 MET 2000
  all.tcl:Total6351Passed5949Skipped397Failed5
  Sourced 84 Test Files.
  Files with failing tests: entry.test unixEmbed.test unixWm.test
  Number of tests skipped for each constraint:
  2altDisplay
  3colorsLeftover
  2emptyTest
  44macOnly
  11macOrPc
  1nonPOrtable
  98nonPortable
  230pcOnly
  4pseudocolor
  1secureServer
  1userInteraction


tkt_uuid: 220286ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: "after" prevents user from switching to other applications in MacOS
comment:
  OriginalBugID: 4358 Bug
  Version: 8.3
  SubmitDate: '2000-03-10'
  LastModified: '2000-04-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: PowerMac G3
  ClosedDate: '2000-04-07'


  Name: Q. Alex Zhao

  ReproducibleScript:
  set i 0
  while { $i < 100 } {
  incr i
  puts $i
  after 1000
  }

  ObservedBehavior:
  The numbers were not printed out one-by-one: they were printed out all at once at the end of the loop. During the 100 seconds of when the loop was running, the system appeared to be stuck -- I couldn't switch to the Finder or any other application running at the same time.

  If I put the code in a proc (say "testAfter") and do a
  after 5000 testAfter
  and switch to the Finder before the callback is called, "wish" doesn't interfere with other application that much (the numbers will still be printed out at the end of the loop, though).

  DesiredBehavior:
  When a Tcl/Tk program is the foreground process, waiting for "after" callbacks should not prevent the user from switching to another process.



  This is due to the lack or true multi-tasking on the part of
  the Mac.  The user has essentially created an app with a tight
  loop.  You can rewrite this to reschedule the proc instead of
  waiting in the proc. 
  -- 04/07/2000 hobbs


tkt_uuid: 1550513fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: None
title: Fix bug when entering a relative path name (Unix)
comment:
  When a relative path name is entered in the "Selection" 
  entry, it is not interpreted relative to the currently 
  selected directory, as I would expect, but relative to 
  [pwd].

  Subsequently, the dialog gets confused and does not 
  allow browsing out of [pwd], because it now considers 
  [pwd] to be the file system "root".

  This patch changes the behavior to be as I expect it, 
  by joining the text from the "Selection" entry with the 
  currently selected directory. This is consistent with 
  the behavior of tk_chooseDirectory on Windows.

  Thanks to the semantics of [file join], the user is 
  still able to enter/paste an absolute path.

  This patch also gets rid of the suspicious
  set text [eval file join [file split [string trim 
  $text]]]
  Although I do not understand the history of this code 
  fragment, it seems wrong, as it is incapable of 
  browsing paths that contain space characters: it fails 
  both when any of the path components contain a space, 
  and also if the user attempts to enter the name of a 
  directory that begins or ends in a space character.


tkt_uuid: 220638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: Doing a -nocase search on a text widget that contains a copyright symbol causes a seg fault
comment:
  OriginalBugID: 3886 Bug
  Version: 8.1
  SubmitDate: '1999-12-15'
  LastModified: '1999-12-16'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '1999-12-16'
  FixedInVersion: 8.2


  Name: Mike Mahar

  Comments:
  This report is FYI only.  I'veworked around the problem but if you make a patch please email me.

  ReproducibleScript:
  # t is a text widget
  # fileid is an open file. The file contains a copyright symbol 0xA9
  $t insert end  [read $fileid]
  #now search for a string that is not  in the file to guarantee that we will see (c)
  $t search -nocase  -count numchars-- "nostring"  insert
  #At this point wish8.1 crashes with a seg fault.

  ObservedBehavior:
  Program received signal SIGSEGV, Segmentation fault.
  0x11f350 in Tcl_UniCharToUtf ()
  (gdb) where
  #0  0x11f350 in Tcl_UniCharToUtf ()
  #1  0x11fa84 in Tcl_UtfToLower ()
  #2  0x7eeb8 in TextSearchCmd (textPtr=0xa9c2a9c2, interp=0xa9c2a9c2, argc=-1446860350, argv=0xa9c2a9c2) at Isrc/../generic/tkText.c:1712
  #3  0x7ce30 in TextWidgetCmd (clientData=0xa9c2a9c2, interp=0xa9c2a9c2, argc=-1446860350, argv=0xa9c2a9c2) at Isrc/../generic/tkText.c:628
  #4  0xdf14c in TclInvokeStringCommand ()
  #5  0xf81c0 in TclExecuteByteCode ()
  #6  0xdfbe4 in Tcl_EvalObjEx ()
  Cannot access memory at address 0xa9c2a9fa.
  (gdb)



  This is not reproducible with the 8.2 version of Tk on Solaris7,
  so I'm assuming it was fixed before then. 
  -- 12/16/1999 hobbs


tkt_uuid: 1911853fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Duplicate
title: tk initialization error message tweak
comment:
  Sometimes, when I attempt to start a tk application, instead of windows I get:

  Application initialization failed: this isn't a Tk applicationcouldn't connect to display "mysrv:0.0"
  Error in startup script: this isn't a Tk applicationcouldn't connect to display "mysrv:0.0"
      while executing
  "load /usr/tcl84/lib/tk8.4g/../libtk8.4g.so Tk"
      ("package ifneeded" script)
      invoked from within
  "package require Tk "
      (file "/vol/multifig/n098/u10k/lib/MFigPGUI/main.tcl" line 2)
      invoked from within
  "source "$u10k/lib/MFigPGUI/main.tcl""
      (file "/cas/bin/sun4/mfigp" line 39)


  There appears to be a missing period and newline (or space or something) after the word "application".


tkt_uuid: 2166563fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: None
title: test case main-3.1 hangs displaying to Exceed x server
comment:
  tcl/tk 8.5.4 release code, compiled on sparc solaris 8 and displaying back to windows xp sp 3 and hummingbird exceed 10.0.0.12.

  When the test suite reaches main.test, it comes to a halt. After waiting a couple of minutes, I end up having to kill the process to get the code to continue the test suite.

  This test was expecting:
  main.test

  ==== main-3.1 Tk_ParseArgv: -help option FAILED
  ==== Contents of test case:

      # Run only on unix as Win32 pops up native dialog
      list [catch {exec [interpreter] -help} msg] $msg

  ---- Result was:
  1 {% % child killed: software termination signal}
  ---- Result should have been (glob matching):
  1 {% Application initialization failed: Command-specific options:*}
  ==== main-3.1 FAILED

  The child killed was, as I mentioned above, because I killed it after waiting for a long time.


tkt_uuid: 2182156fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: [tk busy] test failures
comment:
  We need Category support for the new files.

  These tests are failing:

  ==== busy-4.6 tk busy configure invalid option FAILED
  ==== Contents of test case:

      tk busy configure .f -invalidOption

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 1
  ==== busy-4.6 FAILED



  ==== busy-4.10 tk busy configure valid option with invalid value FAILED
  ==== Contents of test case:

      tk busy configure .f -cursor nonExistingCursor

  ---- Test completed normally; Return code was: 0
  ---- Return code should have been one of: 1
  ==== busy-4.10 FAILED


tkt_uuid: 616923ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Invalid
title: Selection not always claimed by text
comment:
  The following will not claim the selection:
    pack [text .t]
    update
    .t insert 1.0 "any text" sel

  Note that the problem is independent of the index, but
  things work if the text widget was the last window on
  the display to claim the selection.  However if the
  selection was anywhere else (including another Tk
  widget in the same toplevel as the text widget) the
  selection will not be claimed by the text (though it
  will be highlighted as if it is.


tkt_uuid: 1946209fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Invalid
title: cygwin build fails for both X11 and win32 windowing systems
comment:
  Building Tk on Windows with the cygwin environment fails for both the win32 native build and the X11 build.

  The win32 native build bug was detailed in bug 1844430, and is still there in both Tk 8.5.2 and 8.4.19.

  The X11, aka unix, build fails because of a bug in generic/default.h.  It should be using the same logic as the Tk_TkObjCmd function's TK_WINDOWINGSYSTEM code, instead of including Windows functions in a X11 build!
  Attached are patches for Tk 8.4.* and 8.5.[012].


tkt_uuid: 2118116fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.6a2
resolution: Fixed
title: man tk man pages unable to format on sparc solaris
comment:
  Today I was looking at the tk 8.6a2 man pages and found that sun's man command doesn't format many of them. This is due to a first line of:
  '\" -*- nroff -*-

  With this "comment" as the first line, Sun's nroff attempts to treat the line as an indicator of preprocessors to run, and the user gets:

   $ man -s n bell
  Reformatting page.  Please Wait...unknown preprocessor specifier -

  If the first line is a simple
  '\"
  or a blank line, then Sun's man command doesn't attempt to parse the line as preprocessor directives.

  I see the problem in the man section n pages for bell, bind, bindtags, bitmap, button, canvas, checkbutton, clipboard,... over 90 man pages, most of which are Tk man pages. I see a few non-Tk pages, and will open an artifact over in the tcl side as well.

  Thanks.


tkt_uuid: 220047ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Duplicate
title: button text of tk_messageBox
comment:
  OriginalBugID: 3656 RFE
  Version: 8.2
  SubmitDate: '1999-11-23'
  LastModified: '2000-02-01'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2671
  OS: Linux-SuSE
  OSVersion: none
  Machine: PC
  ClosedDate: '2000-02-01'


  Name:
  Holger Jakobs

  Extensions:
  none

  DesiredBehavior:
  In Windows the operating system takes care of presenting the button text of tk_messageBox
  in the native language of the user. X doesn't do it. Unfortunately, the texts are hard coded
  in some .tcl file in lib/tk8.2. Actually several files are affected, since similar texts exist in
  other dialog boxes as well. 

  My idea is that this should at least be coded only once in one file, whether it's an X resource
  or a sourceable file, so that everybody can easily move this file from one Tk version to the
  next.


tkt_uuid: 220561ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.2b1
resolution: Fixed
title: one minor bug, two minor problems
comment:
  OriginalBugID: 2385 Bug
  Version: 8.2b1
  SubmitDate: '1999-07-19'
  LastModified: '1999-07-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: redman
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-07-22'
  FixedInVersion: 8.2b2


  Name:
  vince darley

  CustomShell:
  I'm running with my 'glob' patch.

  ReproducibleScript:
  Problem 1)
      ----------
      
      In the pkgindex for iwidgets the following line:
      
      package ifneeded Iwidgets 3.0.0 "source [file join $dir iwidgets.tcl]"
      
      should be replaced with
      
      package ifneeded Iwidgets 3.0.0 [list source [file join $dir
      iwidgets.tcl]]
      
      or iwidgets will not load if you've installed Tcl in a path with spaces
      (the default under Windows!).
      
      Problem 2)
      ----------
      
      So that Tcl/Tk extensions can be built with the Metrowerks compiler on
      windows, two small changes should be made:
      
      In tkWinPort.h the following line should be wrapped as follows:
      
      #ifndef __MWERKS__
      #include <sys/stat.h>
      #endif
      
      since this file doesn't exist in the Metrowerks Standard Library (or
      perhaps it's just 'stat.h' not in sys).  Anyway to build an extension
      the above suffices.
      
      Similarly tclWinPort.h requires the following minor change:
      
      #ifndef __MWERKS__
      #include <sys/stat.h>
      #include <sys/timeb.h>
      #endif
      
      With these two changes one can easily build extensions for Tcl and Tk
      using the standard distribution.



  Problem (1) was fixed in 8.2b1, but not the source release. Need to do (2) still.

  -- 07/21/1999 redman

  Fixed problem (2).

  -- 07/22/1999 redman


tkt_uuid: 1561991fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: text widget : loosing of tags with undo/redo
comment:
  Hello,

  I issue this bug report after discussions with Donal
  Fellows and Vince Darley, about the behavior of the
  Undo/Redo mecanism in handling tags under deletion.

  In a text widget, when a tagged text region is deleted
  and then the delete is undone, the tags are lost. I
  discuss this point with Vince Darley, and the mails are
  copied below.

  In the meantime, I wrote a Tcl C code to handle tags
  with delete events. The code compiles fine and seems to
  work with the little tests I've done. PLEASE understand
  i'm not an expert at all, so the code may look ugly for
  Tcl'er Gurus, and I don't know about the procedures
  used to make tests, and so on !

  In the tkText.c file (taken from the tk8.4.13
  distribution), procedure DeleteCmd, search for
  "Handling Tags"

  Hope this helps !

  ----------------------------------------------------------------------
  Dr. Luc Moulinier
  IGBMC
  Laboratoire de Biologie et Genomique Structurale      
   1,rue Laurent FRIES               
  BP 10142                tel: (33) (0)3 88 65 32 79
  67 404 ILLKIRCH CEDEX            fax: (33) (0)3 88 65 32 76
  France
  ----------------------------------------------------------------------


  Dear Vince,

  After talking with Donal Fellow, it seems you are the
  right person taht may help me, if you don't mind.

  I'm currently writing a big app for bioinformatics
  purposes. It uses a lot the text widget. And i'm quite
  desesparate with the undo/redo behaviour with tags. The
  problem is the losing of the tagging status of a text
  region when the text is deleted and then the delete is
  undone. I'm sure you're aware of that, but in cas, i
  enclose a very simple script to illustrate it. This
  happens with tcl/tk 8.4.13 and 8.5.0.
  Looking at the mailing list and TIPs, i found nothing
  said about changing that behaviour, (TIPs 26,104,255),
  although someone (maybe you ?) said it should not be a
  so difficult task to achieve. The point would be to
  dump the text widget before deletion.

  Have you any clue about when this behaviour will be
  solved ? or
  Do you know any script/extension that would meka a
  undo/redo working with tagged text ?

  Thank you very much in advance !!

  ----------------------------------------------------------------------
  Dr. Luc Moulinier
  IGBMC
  Laboratoire de Biologie et Genomique Structurale      
   1,rue Laurent FRIES               
  BP 10142                tel: (33) (0)3 88 65 32 79
  67 404 ILLKIRCH CEDEX            fax: (33) (0)3 88 65 32 76
  France
  ----------------------------------------------------------------------

  #!/usr/local/bin/wish

  proc Remove {} {
      .t delete 2.19 2.30
      .t edit separator
  }

  proc Add {} {
      .t edit undo
  }

  text .t -bg black -fg white \
  -height 10 -width 55 \
  -state normal \
  -undo 1 -autoseparators 0
  pack .t

  .t insert end "Here is a test.\n"
  .t insert end "And this is a line with a blue tagged
  region inside\n"
  .t insert end "that explicit the undo behaviour with tags"
  .t tag configure tblue -background cyan
  .t tag add tblue 2.19 2.30
  .t edit separator

  button .brm -text "1. Remove " -bg green -command [list
  Remove]
  button .bad -text "2.  Add back" -bg green -command
  [list Add]
  pack .brm .bad -side left


  Vince Darley replies
  --------------------
  Yes, indeed, the problem here is that the text widget
  never has
  supported storing text tags with the text it stores to
  record 'insert'
  and 'delete' events, and therefore has also never supported
  re-applying those text tags when text is inserted as a
  result of an
  undo or redo operation.

  This is not something that would probably be that hard
  to fix (search
  for 'TextPushUndoAction' in tkText.c for the 2 calls
  that would need
  changing/enhancing). However, some thought would be
  needed to ensure
  undo/redo behaved well if, for example, a tag in the
  undo range was
  deleted from the widget, and then the undo applied
  (probably the
  correct behaviour should be to silently ignore the tag).

  Probably the biggest work is just in building up (in
  TextPushUndoAction's implementation) the script that
  must be executed
  for the undo/redo.  It's always a pain to do that from
  C code, so
  perhaps it could be pushed out into a Tcl supporting
  script in
  text.tcl.

  Vince.


tkt_uuid: 220494ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: selection not UTF-aware
comment:
  OriginalBugID: 1791 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-13'
  LastModified: '1999-07-01'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: foster
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  FixedDate: '1999-06-03'
  FixedInVersion: 8.2b1


  Name:
  Jeffrey Hobbs

  CustomShell:
  I have made mods, but the above is

  Comments:
  I'd like to see some fix to prevent the crash, and then whatever
      route was chosen should probably be documented in the selection
      mechanism docs (both C and Tk level APIs).

      Note that this isn't a problem in Tk8.0 due to the lack of Unicode.

  ReproducibleScript:
  The problem is that the Tk selection mechanism can bring chars into Tk
      that are not safe in all areas of the UTF code (specifically,
      conversion
      between UTF and Unicode, like in string to*).  Here is a snapshot from
      tkcon (commented) that illustrates the bug (causing a crash).  It must
      be done with a Tk-based console (because selection get is used) to
      bring out the bug.

      Main console display active
      ## Here I get the value for a from the xterm,
      ## pasting into the text widget with <2>
      ## We see it comes across as u(umlauted)ber, even with
      ## the cut and past to Netscape
      (unix) 1 % set a über
      über
      ## This special function is like string length without
      ## the Tcl_NumUtfChars, meaning it returns the exact number
      ## of bytes used internally to store the string.
      ## We see that the umlauted u takes only one byte
      (unix) 2 % string bytes $a
      4
      ## Here I type in the \374, which Tcl conveniently converts to
      ## the umlauted u (utf-wise), and I see that in Tk.  The tilde'd A
      ## followed by the 1/4 symbol occurs only through cut-and-paste.
      ## That is the difference really between UTF-wise unicode and straight
      ## interpretation of the umlauted u.  It fits in one byte (as was
      ## done with 8.0), but in a proper UTF env, it is two.
      (unix) 3 % set b \374ber
      über
      ## Here we see that Tcl recognizes the proper ueber is 5 bytes.
      (unix) 4 % string bytes $b
      5
      (unix) 5 % string len $a
      4
      (unix) 6 % string len $b
      4
      ## Both come to the same length (NumUtfChars)
      ## toupper works on b, as the size is appropriate
      ## I get the U-umlaut, as expected in Tk, it just
      ## gets lost here in selection again.
      (unix) 7 % string toupper $b
      Ã?BER
      (unix) 8 % string toupper $a
      ## Doing a string toupper on a, with only 4 bytes, seg faults
      ## on Solaris.

  ObservedBehavior:
  Program received signal SIGSEGV, Segmentation fault.
      0xef5a83dc in Tcl_UniCharToUtf (ch=156, 
          str=0x168000 <Address 0x168000 out of bounds>) at
      ./../generic/tclUtf.c:109
      109             str[1] = (char) ((ch | 0x80) & 0xBF);
      (gdb) bt
      #0  0xef5a83dc in Tcl_UniCharToUtf (ch=156, 
          str=0x168000 <Address 0x168000 out of bounds>) at
      ./../generic/tclUtf.c:109
      #1  0xef5a92a4 in Tcl_UtfToUpper (
          str=0xbb428
      "Ã\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â 234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234
      Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\2
      34Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â
      \234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\23
      4Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â 234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234Â\234"...) at
      ./../generic/tclUtf.c:862
      #2  0xef54193c in Tcl_StringObjCmd (dummy=0x0, interp=0xaa810, objc=3, 
          objv=0xab17c) at ./../generic/tclCmdMZ.c:1197
      #3  0xef55cf44 in TclExecuteByteCode (interp=0xaa810, codePtr=0xb1388)
          at ./../generic/tclExecute.c:843

  DesiredBehavior:
  I would expect it not to crash.  Preferrably in my case, I would like to
      see that stuff coming in from selection get is properly converted into a
      format that Tcl code won't choke on.  See the example:

      Main console display active
      (unix) 1 % set a über
      über
      (unix) 2 % string bytes $a
      4
      (unix) 3 % encoding convertfrom ascii $a
      über
      (unix) 4 % string bytes [encoding convertfrom ascii $a]
      5

      OK, so for me to safely (the question is whether it is proper) bring in
      arbitrary data to Tk that might be further manipulated in Tcl (this
      would be the case for any text editor), I have to do an encoding
      conversion
      on my own.  Note that this is a two-way problem (UTF chars go out as is,
      meaning I paste them into something non-UTF aware and get multiple
      chars).



  The problem with "string toupper" (and consequently "string tolower") was fixed.  the problem was that badly formed Utf strings can contain character that increase in size when converted to their lower of upper case counterparts.  The Tcl_UtfToUpper and Tcl_UtfToLower functions now check that the number of bytes is not increased before copying the new char (in place).  If the number of bytes has increased, the the offending character is not converted to upper or lower case.

  A small test case for the "string toupper" bug is the following:

       text .t ; pack .t
       # paste über or into the text widget
       set x [.t get 0.0 end]
       string toupper $x

  The selection bug can be handled by changing tk code in 4 places:

  1) convert local encoding to utf in TkSelEventProc, where retrPtr->proc is called.

  2) convert local encoding to utf in SelRcvIncrProc.  This is the conversion case where the selection is large so it's done in multiple chunks.  Avoid converting a partial char to utf--do this by storing the partial char in the selection struct, to be converted the next time.  Use the flags in the Tcl_ExternalToUtf call to learn whether there is a partial char.

  3 &4) convert the utf to local encoding in ConvertSelection.  Do this in both the 1-chunk and multiple-chunk selections, where propPtr is set (in the "if" and "else if" clauses, but not in the "else" clause--handles binary data).  Beware of copying partial bytes in multiple-chunk case.
  04/28/1999 19:10 - hershey -

  06/03/1999 11:46 - stanton - Selection code has been upgraded to support COMPOUND_TEXT and STRING formats using iso2022 and iso8859-1 respectively.


tkt_uuid: 1063675fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 9 Immediate
foundin: obsolete: 8.4.7
resolution: Accepted
title: translation errors in tk8.4/msgs/it.msg
comment:
  There are two mistakes in the Italian msgcat file for
  tk 8.4 (I am using 8.4.6 from ActivState):
  - 'Delete' is translated as 'Incolla' instead of 'Cancella'
  - 'Yes' is translated (twice) as 'Si' (without accent)
  instead of 'Sì' (with grave accent)

  Attached is a unified diff file (it contains also a few
  minor adjustments).


tkt_uuid: 220845ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 42. Photo Image|GIF
priority: 5 Medium
foundin: obsolete: 8.1
resolution: Out of Date
title: images degraded with 8.1 from 8.0
comment:
  OriginalBugID: 2142 Bug
  Version: 8.1
  SubmitDate: '1999-06-03'
  LastModified: '1999-10-22'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86


  Name:
  Peter Costello

  Comments:
  i would like to upload the 2 images that appear different in 8.1.
      
      Brent thought I should upload the images,  but how/where???

  ReproducibleScript:
  set btn_base_file "d:/tcl/prjs/swm2/btns/grey_sq/base_btn.gif"
          set btn_www_file "d:/tcl/prjs/swm2/btns/grey_sq/web_search.gif"
          set btn_cumbre_file "d:/tcl/prjs/swm2/btns/grey_sq/cumbre.gif"
          set btn_ar3030_file "d:/tcl/prjs/swm2/btns/grey_sq/ar3030btn.gif"
          set btn_alm_file "d:/tcl/prjs/swm2/btns/grey_sq/clk_btn.gif"
          set btn_swbc_file "d:/tcl/prjs/swm2/btns/grey_sq/swbcbtn.gif"
          set btn_whatson_file "d:/tcl/prjs/swm2/btns/grey_sq/whatson.gif"
      
          # Blank Button
          set blank_btn_img [image create photo]
          $blank_btn_img configure -file $btn_base_file
      
          # Web Browser Button
          set btn_www [image create photo]
          $btn_www configure -file $btn_www_file
      
          # Alarm Button
          set btn_alm [image create photo]
          $btn_alm configure -file $btn_alm_file
      
          # Cumbre DX
          set btn_cumbre [image create photo]
          $btn_cumbre configure -file $btn_cumbre_file
      
          # AR3030
          set btn_ar3030 [image create photo]
          $btn_ar3030 configure -file $btn_ar3030_file
      
          # SWBC Files
          set btn_swbc [image create photo]
          $btn_swbc configure -file $btn_swbc_file
      
          # What's On ?
          set btn_whatson [image create photo]
          $btn_whatson configure -file $btn_whatson_file

  ObservedBehavior:
  some .gif images have lost resolution and/or colors in using Tcl/Tk 8.1
      after
      being fine in 8.0

  DesiredBehavior:
  Images to look identical independent of Tcl/Tk release version.


tkt_uuid: 1835848fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: Fixed
title: font sizing problems
comment:
  There is a problem with font sizing in 8.5b3. When I draw a label, the size of the font is clearly 9. But when querying the size, 12 is reported:

  % pack [label .k -text Koen]
  % .l cget -font
  TkDefaultFont
  % font actual TkDefaultFont
  -family {Luxi Sans} -size 12 -weight normal -slant roman -underline 0 -overstrike 0

  Some further tests reveal that specifying a negative size (in points) does not work anymore:

  % font actual {{luxi sans} -12}
  -family {Luxi Sans} -size 12 -weight normal -slant roman -underline 0 -overstrike 0
  %  font actual {{luxi sans} -8}
  -family {Luxi Sans} -size 12 -weight normal -slant roman -underline 0 -overstrike 0

  Note: this problem also causes a number of failures in the testsuite, already reported in #1800192.

  System is RedHat EL 4: Linux 2.6.9-5.ELsmp


tkt_uuid: 472936ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 3 Low
foundin: None
resolution: Fixed
title: can not find channel named "stdout"
comment:
  I'm trying MacOSXTk8.4a4.  If I try to source tkCVS
  or its installer, I get "can not find channel named stdout".  Then tkCVS opens a secondary window but
  the main one never appears.  I'm not writing explicitly
  to stdout, so I don't know what the problem is.


tkt_uuid: 3609839fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: MouseWheel on Mac : wrong x y
comment:
  I noticed this strange behaviour on Mac (on Win it's OK):
  I'm working with ActiveTcl 8.5.13

  Let's take this simple case
    canvas .c -bg yellow
    pack .c -expand true -fill both -pady 50 -padx 50
    focus .c  ;# this is necessary on Windows ..
    #
    bind .c <Button-1>      { puts "B1 on %W  %x %y" }
    bind .c <MouseWheel> { puts "MW on %W  %x %y" }

  * On Windows
     Acting on B1 and on MouseWheel, you get the same coords (GOOD)
  * On MacOs
   Printed coords are different ! In particular if you click near the top-left corner you'll get something very close to (0,0) (good), but if you act on mousewheel you'll get something close to (50,50) !!


tkt_uuid: 1078648fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: -debug 1 testing reveals test suite flaws
comment:
  Tried Tk 8.4.9 test suite with the
  -debug 1 flag on.  Disaster.
  Test suite's in  mega-need of cleanup.
  Tk 8.5 is no better.

  Assigning to dkf only on the chance
  he might have work he'd rather avoid. :^)

  Low hanging fruit is all the duplicated
  test names.


tkt_uuid: 849173ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: configure sets HAVE_STRUCT_DIRENT64 when readdir64 unavail
comment:
  After running configure in tcl8.4.5 and tk8.4.5 I get a
  link error
  at the end of make because readdir64 is not defined.

  I edited the Makefile and tkConfig.sh (tclConfig.sh on
  the tcl side)
  to remove the HAVE_STRUCT_DIRENT64 and was able to
  complete the make/install (and run tkdiff as a
  testcase)

  I'm using linux 2.4.23-rc with libc5.4.44
  gcc version egcs-2.91.66.1


tkt_uuid: 1816826fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.4.16
resolution: Works For Me
title: focus bug during window activation (Aqua)
comment:
  To produce the bug:
  toplevel .t
  pack [text .t.t1]
  toplevel .t2

  1 click into .t2
  2 Minimize .t  with the yellow button.
  3. when you deiconify the minimized window, the text box has no cursor, and also has no focus ring around it. It responds to button events but doesn't set a cursor.
  4. If you click into .t2, then back, the text box is activated again, has a cursor and a focus ring.

  if the console window is the next window down in the stack, so that it gets focus on minimizing, the bug doesn't happen.


tkt_uuid: 220469ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: win dde execute timeout large / request extra characters
comment:
  OriginalBugID: 1639 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-26'
  LastModified: '1999-04-05'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: Windows 95
  OSVersion: B
  Machine: X86
  FixedDate: '1999-04-05'


  Name:

  Harald Oehlmann



  Extensions:

  none



  CustomShell:

  No



  ReproducibleScript:

      dde execute CS CS "\[SetPrinter(\"gimmick\")\]

      dde request CS CS "@VARLIST"

      







  ObservedBehavior:

      1) If the DDE server (here Codesoft 4.2 from Teklinx) crashes in the

      execution of a command, tk waits 2h in inactivity.

      2) dde request returns extra characters after the terminating zero.

      3) It was reported to me that windows send doesn't work because of the

      extra characters.

      







  DesiredBehavior:

      1) Timout at a reasonable time (ex. 30 sec)

      2) No extra characters

      







  Patch:

  *** tkWinSend.c_origSat Mar 13 19:09:41 1999

  --- tkWinSend.c_newFri Mar 26 11:07:24 1999

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

  *** 844,850 ****

        }

    

        utilString = (char *) DdeAccessData(hData, &len);

  !     ddeObjectPtr = Tcl_NewStringObj(utilString, len);

        Tcl_IncrRefCount(ddeObjectPtr);

        DdeUnaccessData(hData);

        if (convPtr->returnPackagePtr != NULL) {

  --- 844,850 ----

        }

    

        utilString = (char *) DdeAccessData(hData, &len);

  !     ddeObjectPtr = Tcl_NewStringObj(utilString, strlen(utilString));

        Tcl_IncrRefCount(ddeObjectPtr);

        DdeUnaccessData(hData);

        if (convPtr->returnPackagePtr != NULL) {

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

  *** 1184,1190 ****

                                ddeResult);

    } else {

        ddeReturn = DdeClientTransaction((LPBYTE) ddeData, 0xFFFFFFFF,

  !     hConv, 0, CF_TEXT, XTYP_EXECUTE, 7200000, NULL);

        if (ddeReturn == 0) {

    SetDdeError(interp);

    result = TCL_ERROR;

  --- 1184,1190 ----

                                ddeResult);

    } else {

        ddeReturn = DdeClientTransaction((LPBYTE) ddeData, 0xFFFFFFFF,

  !     hConv, 0, CF_TEXT, XTYP_EXECUTE, 30000, NULL);

        if (ddeReturn == 0) {

    SetDdeError(interp);

    result = TCL_ERROR;

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

  *** 1223,1229 ****

    result = TCL_ERROR;

        } else {

    dataString = DdeAccessData(ddeData, &dataLength);

  ! returnObjPtr = Tcl_NewStringObj(dataString, dataLength);

    DdeUnaccessData(ddeData);

    DdeFreeDataHandle(ddeData);

    Tcl_SetObjResult(interp, returnObjPtr);

  --- 1223,1229 ----

    result = TCL_ERROR;

        } else {

    dataString = DdeAccessData(ddeData, &dataLength);

  ! returnObjPtr = Tcl_NewStringObj(dataString, strlen(dataString));

    DdeUnaccessData(ddeData);

    DdeFreeDataHandle(ddeData);

    Tcl_SetObjResult(interp, returnObjPtr);









  PatchFiles:

      win/tkWinSend.c

      









  04/05/1999 20:19 - redman - All problems have been fixed, applied patch to decrease the timeouts. 

     2) This is a known problem with Windows 95 / Windows 3.1.
      The DdeGetData command does not return a valid length.
      Instead strlen can be used because Win Atoms are always 0-terminated.
      3) I have send my version to Kevin Kenny how reported the 3rd problem.
      He will report if it works.


tkt_uuid: 220682ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Scale widget consumes CPU
comment:
  OriginalBugID: 4191 Bug
  Version: 8.3
  SubmitDate: '2000-02-16'
  LastModified: '2000-04-14'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  Machine: Compaq Deskpro, 200 MHz Pentium Pro
  FixedDate: '2000-04-14'
  FixedInVersion: 8.3.1


  Name:
  Ryan Telkamp

  ReproducibleScript:
  I'm running a CompaQ 200+ MHz Pentium Pro with 64 Mb memory and running Win NT 4.0 Patch 3.  I've tried the following code on TCL/TK rev 8.0.5 and now with 8.3 with the same results from Wish.

  % set x [scale .ra -from 0  -to 360  -length 200  -orient horizontal  -tickinterval 0.1  -showvalue false  -resolution 0.1  -variable scale_val   -command "puts stdout "]
  .ra
  % pack .ra

  ObservedBehavior:
  Whenever the cursor moves into the slider area CPU utilization jumps to 90-100 % utilization for 3-5 seconds, then slowly reduces back to 0 (when the cursor is still).  Responsiveness of the slider bar is very slow (2-3 seconds to acknoledge selection).

  Other TCL/TK apps that I've written, none of which used a scale directive, exhibit this.  Even when I have multiple levels of bindings.

  DesiredBehavior:
  Performance and CPU utilization similar to a scrollbar.



  The problem seems to be related to -tickinterval solely, and it
  can also screw up on Unix somewhat.  Also have to check into the
  problem that the scale command gets called too often on Motion. 
  -- 04/09/2000 hobbs
  This was due to an overagressive use of the configure method
  in the Motion event (calling tkScaleActivate).  This has been
  fixed for 8.3.1.  This only affected the scale widget. 
  -- 04/14/2000 hobbs


tkt_uuid: 579651ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: leftover assert in tkFont.c
comment:
  While chasing the origin of static strings in the compiled 
  binaries, I saw that there is one in tkFont.c, generated by 
  a call to assert(). 
   
  SInce it's the only one, I suggest removing it.  


tkt_uuid: 220426ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Arugments on the wish command line do not have their character set translated.
comment:
  OriginalBugID: 1154 Bug
  Version: 8.1a2
  SubmitDate: '1999-02-02'
  LastModified: '1999-05-20'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hershey
  OS: Windows NT
  OSVersion: NT4.0J
  Machine: X86
  FixedDate: '1999-03-26'


  Name:
  Syd Polk

  CVS:
  1.1.4.2 generic/tkMain.c

  ReproducibleScript:
  On a Japanese machine, write a script. Use wish to call the script and give it Japanese command line arguments. The arguments are mangled. This bug is not present in tclMain.c, just in tkMain.c

  Patch:
  *** tkMain.c    Fri Dec 11 14:33:26 1998
  --- tkMain.c.new        Fri Dec 11 14:34:00 1998
  ***************
  *** 133,139 ****

        args = Tcl_Merge(argc-1, argv+1);
        Tcl_ExternalToUtfDString(NULL, args, -1, &argString);
  !     Tcl_SetVar(interp, "argv", args, TCL_GLOBAL_ONLY);
        Tcl_DStringFree(&argString);
        ckfree(args);
        sprintf(buf, "%d", argc-1);
  --- 133,139 ----

        args = Tcl_Merge(argc-1, argv+1);
        Tcl_ExternalToUtfDString(NULL, args, -1, &argString);
  !     Tcl_SetVar(interp, "argv", Tcl_DStringValue(&argString), TCL_GLOBAL_ONLY);
        Tcl_DStringFree(&argString);
        ckfree(args);
        sprintf(buf, "%d", argc-1);

  PatchFiles:
  generic/tkMain.c



  That patch was already applied as of 03/26/1999 13:40 - surles -


tkt_uuid: 624974ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: image create photo -format
comment:
  This crashes or causes incorrect behavior:

  image create photo -format
  image1 cget -format

  I "fixed" it like so:

  --- tkImgPhoto.c        9 Oct 2002 09:32:24 -0000     
   1.35
  +++ tkImgPhoto.c        17 Oct 2002 23:56:26 -0000
  @@ -1848,9 +1848,12 @@
                  }
              } else if ((args[j][1] == 'f') &&
                      !strncmp(args[j],"-format",
  (size_t) length)) {
  -               if (i < objc) {
  +               if (i+1 < objc) {
                      format = objv[++i];
                      j--;
  +               } else {
  +                   j--;
  +                   format = NULL;
                  }
              }
          }

  But I don't know if that's the correct place or way to
  fix it.


tkt_uuid: 1609328fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: None
title: focus test failures
comment:
  Fedora Core 6 / KDE 3.5.5:

  failing tests:

  ==== spinbox-19.8 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .e
      # update necessary to process FocusIn event
      update
      set ::vVals

  ---- Result was:
  .e -1 -1 abcd abcd {} focus focusout
  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusin
  ==== spinbox-19.8 FAILED


  ==== spinbox-19.10 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .e
      # update necessary to process FocusIn event
      update
      set ::vVals

  ---- Result was:
  .e -1 -1 abcd abcd {} all focusout
  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} all focusin
  ==== spinbox-19.10 FAILED


  ==== spinbox-19.14 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .e
      # update necessary to process FocusIn event
      update
      set ::vVals

  ---- Result was:
  .e -1 -1 abcd abcd {} focusout focusout
  ---- Result should have been (exact matching):

  ==== spinbox-19.14 FAILED


tkt_uuid: 220414ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Double Click selection in Text widget does not select the word if text is not english
comment:
  OriginalBugID: 1048 RFE
  Version: 8.1b1
  SubmitDate: '1999-01-15'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Name:
  Petasis George

  DesiredBehavior:
  When you double click in a text widget, the word under cursor is selected.
  But this works fine only if the text beneath cursor is in english. If the text under the curson is in another language (greek for example) then the whole range of characters is selected, from the previous english character to the next one.
  It would be nice if in other languages, words were selected depending on spaces or other punctual symbols (apostrophes, slashes, etc.)
  Also this request is related with the wordstart and wordend tags of the text document.



  This appears to work in 8.2b2, was probably fixed before 8.1 went
  final.  Required Unicode awareness for the helper procedures.
  This works with German texts. 
  -- 08/06/1999 hobbs


tkt_uuid: 220686ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 59. [tk_focus*]
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: Improper use of uplevel
comment:
  OriginalBugID: 4208 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux-SuSE
  FixedDate: '2000-02-25'
  FixedInVersion: 8.3.1


  Name:

  Csaba Nemethi



  ReproducibleScript:

  In the patch contained in the bug report 3943 ("Improper use of after,

  eval, and uplevel") I unfortunately forgot to include a line from the

  Tk library file focus.tcl (although this file was present in the list

  of the affected files).  Consider the following script. in which the

  widget name ".e 2" intentionally contains a space (according to the

  Tcl man page, this is allowed):



      entry .e1

      entry ".e 2" -takefocus p

      proc p w {return ""}

      pack .e1 ".e 2"



  ObservedBehavior:

  When traversing to the second entry with Tab, the following error

  message is displayed:



      called "p" with too many arguments

          while executing

      "p .e 2"

          ("uplevel" body line 1)

          invoked from within

      "uplevel #0 $value $w"

          (procedure "tkFocusOK" line 9)

          invoked from within

      "tkFocusOK $cur"

          (procedure "tk_focusNext" line 36)

          invoked from within

      "tk_focusNext .e1"

          invoked from within

      "tkTabToWindow [tk_focusNext .e1]"

          (command bound to event)



  The error occurs because uplevel concatenates its arguments, therefore

  tkFocusOK are passed the arguments ".e" and "2" instead of the single

  argument ".e 2".



  DesiredBehavior:

  The invocation of uplevel should make use of the list command, in order

  to work for widget names containing spaces or other special characters.



  Patch:

  *** focus.tcl.OLD       Thu Sep  2 19:02:52 1999

  --- focus.tcl.NEW       Sun Dec 26 18:40:17 1999

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

  *** 136,142 ****

          } elseif {$value == 1} {

              return [winfo viewable $w]

          } else {

  !           set value [uplevel #0 $value $w]

              if {[string compare $value ""]} {

                  return $value

              }

  --- 136,142 ----

          } elseif {$value == 1} {

              return [winfo viewable $w]

          } else {

  !           set value [uplevel #0 $value [list $w]]

              if {[string compare $value ""]} {

                  return $value

              }



  PatchFiles:

  focus.tcl





  Fixed as noted for 8.3.1. 
  -- 02/25/2000 hobbs


tkt_uuid: 1938580fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: 8.5 tkArgv.c PrintUsage -help crash
comment:
  Executing wish8.5 -help crashes from consuming all available memory.  The problem is in file generic/tkArgv.c in the function PrintUsage.  Going from 8.4 to 8.5, the variables width, i, numspaces and length have been changed to size_t which is unsigned.  The loop test while (numspaces > 0) is never false, so the interpreter is stuck allocating all memory for the interp result.

  To fix the problem, on line 340 of version 1.11 tkArgv.c, change size_t to int.  Then, to avoid compiler warnings, change "size_t length;" on line 354 to "int length;'


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: 618096ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: None
title: menu bugs with huge display (xinerama)
comment:
  (FYI, tk bug reporting is very well hidden from the
  tcl/tk home page)

  Environment: Solaris 8, openwin X11 server, CDE
  window manager (dtwm) I'm running X in "Xinerama"
  mode with one logical screen across two physical
  displays.  To X clients, it appears as if there
  is one single 2560x1024 display.

  Both of the problems below occur when a Tk window
  is moved to the right half of the screen (into
  the second monitor), but it doesn't happen
  exactly at the same spot each time.  Sometimes I
  can get a window fully into the right monitor,
  plus another 20 or 30 pixels without problems,
  but then if I move it farther to the right, the
  problems start.

  First, menus (at least within a menubar) become
  very slow and unresponsive.  They don't respond
  at all to press-and-drag menu selection.  Once
  started, this problem persists regardless of
  where the window is posistioned.

  Second when submenus of a menu are posted, they
  appear at the correct y, but far to the left, in
  the first monitor.  This problem eventually goes
  away if the window is moved to the left again,
  but also not at a consistent x-position.

  I checked winfo: x, y, rootx, rooty, screenwidth,
  screenheight, pointerx, and pointery all return
  values that you'd expect for the main window
  regardless of where the window is.  However when
  I post a menu with ".mb1.menu1 post 1800 120",
  and the immediately do "winfo rootx .mb1.menu1",
  it returns 520, which is 1800-1280, and 1280 is
  half the screen width, one monitor width.  The
  menu still appears in the right half of the
  screen though.  If I then call ".mb1.menu1
  postcascade 2", the sub menu winds up (not
  surprisingly) at an x of 639, both visibly and as
  reported by winfo rootx.  (winfo x reports the
  same as winfo rootx in these two cases also.)

  dtwm uses a "rooms" virtual window paradigm, so
  vrootx and vrooty should always be zero, and they
  are reported as such.  vrootwidth and vrootheight
  are also reported correctly by winfo.


tkt_uuid: 220394ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: alternate font syntaxes do not work on some X servers
comment:
  OriginalBugID: 846 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-24'
  LastModified: '1998-11-24'
  Severity: SER
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-24'
  FixedInVersion: 8.0.5


  The following script fails to display correctly on some X servers (e.g. Exceed v6) because the servers claim to find a font for any string, even if it doesn't really match anything:

  label .l -text foobar -font {Courier 36}
  pack .l



  The TkpGetNativeFont routine on Unix needs to weed out suspicious font names so Tk gets a chance to parse them.


tkt_uuid: 220376ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: entry box look and feel
comment:
  OriginalBugID: 655 Bug
  Version: 8.0p1
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  The LOOK of a disable (-state disable) vs. enabled (-state normal)
  widget varies from widget to widget and from platform to platform and,
  in some cases, is broken.  I haven't monkeyed with menus.  I can tell
  you that entry widgets don't follow native look and feel on UNIX (Motif)
  and NT.  I've attached an entry sub-class which fixes this in Tcl.  I
  wouldn't ordinarily post such a long script but I've tried to upload
  this to the Neosoft archives and failed so here it is for whoever can
  make good use of it.

  ---
  # entry.tcl --
  #
  # Fix-up native look-and-feel of entry widgets for NT and UNIX.
  #
  # Chris Nelson (nelson@pinebush.com)  28 Apr 1998
  #
  #------------------------------------------------------------------------
  # Widgets sub-classed from [entry] to deal with a problem with native
  # look-and-feel regarding the coloring of disabled entries.
  #
  # In Motif, the background of entries is always the same (generally
  # the same as the window background) and disabled entries have their
  # foreground greyed out.
  #
  # In Windows NT, the foreground of entries is always the same
  # (generally the same as the window text color) and the background
  # changes when an entry is enabled or disabled.  Generally, the
  # background is white for enabled entries, and the same color as the
  # window background for disabled entries.  (This tends to give stronger
  # visual feedback about the state of the UI.)
  #
  # In Tk 8.0, entries do not change colors at all when they are
  # disabled.
  #
  # This script "sub-classes" [entry] by replacing the default widget proc
  # with a wrapper which takes special actions on state change.  Thanks
  # to Bryan Oakley for the basic technique which he also implemented in
  # his supertext widget; a sub-class of [text] which include undo
  # commands.
  #
  # The general sub-classing technique is:
  #
  #    proc newEntry { w args } {
  #        set e [entry $w $args]
  #        rename $e ${e}_base
  #        bind $e <Destroy> {+ rename ${e}_base {}}
  #        proc $e { args }  #            "set w $e;set baseProc ${e}_base;[info body wrapperProc]"
  #    }
  #
  # You could then replace all calls to [entry] with [newEntry].  An
  # alternative might be to have start up code like:
  #
  #    rename entry tkEntry
  #    proc entry { w args } {
  #       set e [tkEntry $w $args]
  #       ...
  #    }
  #
  # Then the sub-classed entry is used by default everywhere.  This
  # second technique is implemented in this script.
  #
  #
  # NOTE: we CANNOT just have wrapperProc figure out the base proc
  # and/or widget name with introspection like:
  #
  #     set baseProc "[lindex [info level] 0]_base"
  # 
  # because the new proc we create as $e might have been renamed AGAIN.
  # For example, if the entry widget for <path>.e proc is renamed
  # .<path>.e so the above would set baseProc to .<path>.e_orig (not
  # <path>.e_orig), which would be either undefined or not the proc we
  # want.
  #
  # Since we can't rely in [info] or other introspection routines to
  # tell us what we want to know at run time, we need to bind this
  # information when we know it -- as the proc is created -- we do this
  # by pre-pending two lines to the body of the wrapper as shown.
  #
  #------------------------------------------------------------------------

  # Remember how to get to the core function.
  rename entry tkEntry

  # A proc to create the new, sub-classed widget
  proc entry {w args} {
      # Create the basic entry
      uplevel 1 [list tkEntry $w] $args

      # Put our own proc on the widget
      #
      # It would be safer to do something like:
      #    for { set baseName ${w}_base }  #             { [catch {rename $w $baseName}] }  #             { set baseName "${baseName}_" } {
      #       # Empty - work done in test
      #    }
      # but ...
      rename $w ${w}_base
      # Sometimes <Destroy> event handlers get called twice so we 
      # [catch] the rename so it doesn't fail the second time.
      bind $w <Destroy> [list + catch [list rename ${w}_base {}]]
      proc $w { args }  "set w $w;set baseProc ${w}_base;[info body EntryProc]"

      return $w
  }
  # entry

  # A replacement for the entry widget proc which deals with colors for
  # state change for better native look-and-feel.
  #
  # Never, EVER call this directly.  entry creates a derived widget
  # proc by using [info body] to get EntryProc's body and prepending
  # the setting of w and baseProc.  See detailed comments on
  # sub-classing above.
  proc EntryProc { args } {
      set stateIndex [lsearch -exact $args "-state"]
      if { $stateIndex != -1 } {
          incr stateIndex
          set state [lindex $args $stateIndex]
          switch -- $state {
              normal -
              disabled {
                  EntryState $w $baseProc $state
              }
              default {
                  # Don't error here because command might be "$e cget -state"
                  # Original proc will catch other errors
              }
          }
          # switch
      }
      # If state control
      eval $baseProc $args
  }
  # EntryProc

  # Respond to state change for an entry
  proc EntryState { w baseProc state } {
      global EntryStateInited
      if { ! [info exists EntryStateInited] } {
          InitEntryState $w
          set EntryStateInited 1
      }

      switch -- $state {
          normal {
              $baseProc configure  -foreground [option get $w *Entry.Foreground Foreground]  -background [option get $w *Entry.Background Background]
          }
          disabled {
              $baseProc configure  -foreground  [option get $w *Entry.DisabledForeground DisabledForeground]  -background  [option get $w *Entry.DisabledBackground DisabledBackground]
          }
          default {
              error "incorrect state $state for entry"
          }
      }
      # switch
  }
  # EntryState

  #
  # Adjust entry colors so that disabled entries are deemphasized.
  # Season to taste. ;-)
  proc InitEntryState { w } {
      global tcl_platform

      # If we've been here before, get on with it.
      if { [option get $w *Entry.DisabledForeground DisabledForeground] != "" } {
          return
      }

      # Create a button and an entry (that we'll never pack)
      # so we can query their attributes
      set b [button .b11111111]
      set e [entry  .e22222222]

      # Set options to be used by proc that disables entries
      if {$tcl_platform(platform) == "unix"} {
          # Put the default entry foreground in the option db for later use.
          option add  *Entry.Foreground [$e cget -foreground] widgetDefault

          # The entry foreground should work like the button foreground
          option add  *Entry.DisabledForeground   [$b cget -disabledforeground]   widgetDefault

          # An entry background doesn't change on UNIX.
          option add  *Entry.Background [$e cget -background] widgetDefault
          option add  *Entry.DisabledBackground  [$e cget -background] widgetDefault
      } else {
          # An entry foreground doesn't chage on NT.
          option add  *Entry.Foreground [$e cget -foreground] widgetDefault
          option add  *Entry.DisabledForeground  [$e cget -foreground] widgetDefault

          # Put the default entry background in the option db for later use.
          option add  *Entry.Background  [$e cget -background] widgetDefault

          # The entry background is like the button background when disabled.
          option add  *Entry.DisabledBackground  [$b cget -background] widgetDefault
      }

      # Get rid of the widgets we queried
      destroy $b
      destroy $e
  }
  # InitEntryState

  #------------------------------------------------------------------------
  # Ugly little proc to show what the "patch" does
  proc entryColorTest { } {
      foreach cmd { tkEntry entry } label { Core Patched } {
          set f [frame .$cmd -relief ridge -borderwidth 2]
          pack $f -side top -padx 1m -pady 1m

          label $f.l -text $label
          pack $f.l -side top

          foreach n { 0 1 } {
              frame $f.$n
              pack $f.$n -side top -padx 1m

              global EntryState$cmd$n
              checkbutton $f.$n.cb -variable EntryState$cmd$n
              $cmd $f.$n.e
              $f.$n.e insert end "Some text"
              pack $f.$n.cb $f.$n.e -side left

              trace variable EntryState$cmd$n w [list ChangeEntryState $f.$n.e]
              set EntryState$cmd$n $n
          }
          # foreach
      }
      #foreach

      button .b -text "Exit" -command "exit"
      pack .b -padx 2m -pady 2m
  }
  # entryColorTest

  # Helper for entryColorTest - enabled and disables the entry
  # associated with a check button.
  proc ChangeEntryState { entry name1 name2 op } {
      upvar #0 $name1 state
      if { $state } {
          $entry configure -state normal
      } else {
          $entry configure -state disabled
      }
  }



  The entry widgets follow basic native LAF, and can be better
  configured by the user through the use of available options. 
  -- 09/13/1999 hobbs


tkt_uuid: 1224854fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: Fixed
title: compile warning in TkCanvas.c
comment:
  My (particularly picky) HP compiler issues this warning
  on tkCanvas.c

  cc:
  "/sppdg/scratch/bob/temp/tk8.4.11/unix/../generic/tkCanvas.c",
  line 214: warning 558: Empty declaration.

  Apparently the semicolon doesn't belong on this line:

    TCL_DECLARE_MUTEX(typeListMutex);


tkt_uuid: 798211ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 22. Style Engine
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: Double-free in style engine
comment:
  TkStylePkgFree() can end up being called while there
  are still extant references to Tk_Style structures
  cached in Tcl_Obj's.  This causes a reference to
  free()d memory, possibly followed by double-free later
  on when the Tcl_Obj is deleted.

  'valgrind' reports the following:

  ==10007== Invalid read of size 4
  ==10007==    at 0x81024B6: Tk_FreeStyle
  (/usr/local/src/tk/generic/tkStyle.c:1444)
  ==10007==    by 0x810267A: FreeStyleObjProc
  (/usr/local/src/tk/generic/tkStyle.c:1628)
  ==10007==    by 0x8169C85: TclFreeObj
  (../generic/tclObj.c:749)
  ==10007==    by 0x80E4E65: Tk_DeleteOptionTable
  (/usr/local/src/tk/generic/tkConfig.c:360)
  ==10007==    Address 0x4133A01C is 0 bytes inside a
  block of size 20 free'd
  ==10007==    at 0x4003D129: free (vg_clientfuncs.c:180)
  ==10007==    by 0x81A33F4: TclpFree
  (../generic/tclAlloc.c:702)
  ==10007==    by 0x8116EC6: Tcl_Free
  (../generic/tclCkalloc.c:1160)
  ==10007==    by 0x810156A: TkStylePkgFree
  (/usr/local/src/tk/generic/tkStyle.c:272)


tkt_uuid: 2810692fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Duplicate
title: tk_getOpenFile exceptions when double clicking on directory
comment:
  On Linux and probably all other unixen if a user does NOT HAVE PERMISSION to enter a directory ( e.g. 666 or drw-rw-rw ) the tk_getOpenFile dialog will cause an error  here is some example code to cause error. Trace back follows code. It looks like a simple fix as there is no message for the -message option in this case (See Trace back ) which causes the "warning" to be seen as an option.  Error was "Error: bad option "warning": must be -default,-de...
  =================START CODE ==================
  #!/bin/sh
   # the next line restarts using wish \
   exec /opt/usr8.6b.1/bin/tclsh8.6  "$0" ${1+"$@"}
    
  if { [ catch {package require Img } err ] != 0 } {
      puts stderr "Unable to find package Img ... adjust your auto_path!";
  }

  proc mkWindow { root } {
      global gStatus gCanvas
      if { $root eq "." } {
  set mf [ frame .frame -width 700 ]
      } else {
  set mf [ frame $root.frame -width 700 ]
      }
      set tf [frame .frame.topframe ]
      set bf [frame .frame.bottomframe ]
      set status [ label $tf.label -textvariable gStatus -width 300 ]
      set gCanvas [ canvas $tf.canvas  ]
      set bclose [button $bf.close -text Close -command { exit } ]
      set bopen  [button $bf.open  -text Open  -command { openProc } ] 
      pack $gCanvas -fill both -expand 1 -side top -anchor c
      pack $status -fill x -expand 1 -side top -anchor w
      pack $tf  -fill both -expand 1 -side top
      pack $bf  -fill x  -side top
      pack $bclose -ipadx 5 -padx 5 -pady 5 -side right -anchor c
      pack $bopen  -ipadx 5 -padx 5 -pady 5 -side right -anchor c
      pack $mf -side top -fill both -expand 1 -anchor c
      
  }

  proc openProc { } {
      global gCanvas env gLabel
      set filename [ tk_getOpenFile -defaultextension .jpg \
         -initialdir [file join $env(HOME) Pictures ] \
         -parent . \
         -title "View Picture?" ]
      if { [string length $filename ] == 0  } {
  return
      }
      catch { rename chuck {} } 
      image create photo chuck -format JPEG -file $filename
      set picid [$gCanvas create image 0 0 -anchor nw -image chuck ]
      $gCanvas bind $picid <Enter> [list set gStatus "id:$picid |filename:$filename" ]
  }

  global gCanvas gStatus
  set gStatus "hello"
  mkWindow .
  wm geometry . 500x500

  ====================== END CODE =============
  =====================START TRACEBACK =======
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
      while executing
  "error "bad option \"$cmdsw\": must be [tclListValidFlags cmd]""
      (procedure "tclParseConfigSpec" line 36)
      invoked from within
  "tclParseConfigSpec $w $specs "" $args"
      (procedure "tk::MessageBox" line 24)
      invoked from within
  "tk::MessageBox {*}$args"
      (procedure "tk_messageBox" line 2)
      invoked from within
  "tk_messageBox -type ok -parent $w -message -icon warning  [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]"
      (procedure "ListInvoke" line 14)
      invoked from within
  "ListInvoke $w [list $filename]"
      (procedure "::tk::dialog::file::OkCmd" line 13)
      invoked from within
  "::tk::dialog::file::OkCmd .__tk_filedialog"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 $data(-command)"
      (procedure "IconList_Invoke" line 5)
      invoked from within
  "IconList_Invoke $w"
      (procedure "tk::IconList_Double1" line 5)
      invoked from within
  "tk::IconList_Double1 .__tk_filedialog.contents.icons 30 98"
      (command bound to event)
  =================== END TRACEBACK ====================


tkt_uuid: 220175ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_Sleep API
comment:
  OriginalBugID: 1885 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




  04/28/1999 14:00 - kenj - Former Tk function now incorporated in Tcl. Tcl API documented in the Tcl man pages. Tk usage deprecated.


tkt_uuid: 627556ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 4
foundin: final: 8.3.5
resolution: Invalid
title: tcl.m4 is not up to date
comment:
  The released files tcl8.3.5/unix/tcl.m4 and
  tk8.3.5/unix/tcl.m4 are not the same.  I 
  think they are supposed to be the same.

  The real fix for this bug is not to update
  Tk's copy of tcl.m4, but to complete the
  factoring out of tcl.m4 and friends into
  a separate CVS module that both Tcl and
  Tk can include so that they automatically
  have the same version without all the
  endless copying from one CVS repository
  to another.


tkt_uuid: 2326602fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Incorrect documentation of canvas -width window item option.
comment:
  According to the current version (1.39) of the canvas documentation for the -width option of window items: 'If this option is not specified, or if it is specified as an empty string, then the window is given whatever width it requests internally.'

  However, specifying an empty string gives an error message: 'bad screen distance ""'

  It seems the described result is achieved by specifying a width of 0 instead of an empty string.

  % grid [canvas .c]
  % .c create window 10 10 -window [button .b] -width {}
  bad screen distance ""
  % set errorInfo
  bad screen distance ""
      (processing "-width" option)
      invoked from within
  ".c create window 10 10 -window [button .b] -width {}"

  A similar problem exists for the -height option.


tkt_uuid: 749889ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: Missing "Times" and "Helvetica" fonts when xft support on
comment:
  Just checked out the latest tk from CVS. After configuring and 
  installing with XFT Anti-Aliased font support turned on:

  ./configure --enable-xft
  make
  make install

  "font families" shows no "Helvetica" or "Times" fonts being available - 
  these are supposed to be guaranteed by Tk.

  % info patch
  8.5a0

  % parray tcl_platform
  tcl_platform(byteOrder) = littleEndian
  tcl_platform(machine)   = i686
  tcl_platform(os)        = Linux
  tcl_platform(osVersion) = 2.4.19-4GB
  tcl_platform(platform)  = unix
  tcl_platform(user)      = neil
  tcl_platform(wordSize)  = 4

  % join [lsort [font families]] \n
  Adobe Courier
  Adobe Helvetica
  Adobe New Century Schoolbook
  Adobe Times
  Adobe Utopia
  Arabic Newspaper
  B&H Lucida
  B&H LucidaBright
  B&H LucidaTypewriter
  Bitstream Charter
  Bitstream Terminal
  Century Schoolbook L
  Courier
  Courier 10 Pitch
  Cursor
  DEC Terminal
  Dingbats
  ETL Fixed
  East Syriac Adiabene
  East Syriac Ctesiphon
  Estrangelo Antioch
  Estrangelo Edessa
  Estrangelo Midyat
  Estrangelo Nisibin
  Estrangelo Nisibin Outline
  Estrangelo Quenneshrin
  Estrangelo Talada
  Estrangelo TurAbdin
  Goha-Tibeb Zemen
  Led Fixed
  Luxi Mono
  Luxi Sans
  Luxi Serif
  MUTT ClearlyU Alternate Glyphs Wide
  MUTT ClearlyU Wide
  Misc Fixed
  Misc Fixed Wide
  Nimbus Mono L
  Nimbus Roman No9 L
  Nimbus Sans L
  Schumacher Clean
  Serto Batnan
  Serto Jerusalem
  Serto Jerusalem Outline
  Serto Kharput
  Serto Malankara
  Serto Mardin
  Serto Urhoy
  Sony Fixed
  Standard Symbols L
  URW Bookman L
  URW Chancery L
  URW Gothic L
  URW Palladio L
  Utopia
  console8x16.pcf
  console8x8.pcf


tkt_uuid: 3574861fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Fixed
title: X11 fails to build
comment:
  8.5.12 release builds fine, but starting with 
  5b7f946912c4f9360d48c42572784079680f92d2 2012-10-02 00:45:42 UTC

  build attempts against X11 fail:

  tkUnixSend.c
  /Users/dgp/fossil/tk8.5/unix/../unix/tkUnixSend.c: In function ‘SendInit’:
  /Users/dgp/fossil/tk8.5/unix/../unix/tkUnixSend.c:1357: error: ‘TkDisplay’ has no member named ‘commTkWin’


tkt_uuid: 220571ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 2
foundin: None
resolution: Fixed
title: XFillRectangle missing from Tk's stub table
comment:
  OriginalBugID: 2446 Bug
  Version: 8.2b1
  SubmitDate: '1999-07-26'
  LastModified: '1999-07-30'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Redhat 4.2
  Machine: Other
  FixedDate: '1999-07-30'
  FixedInVersion: 8.2b2


  Name:

  Jan Nijtmans



  Comments:

  I don't want entry 105 to be used, because this should be reserved for

      the function XWarpPointer(). See also BugID 2340, please.



  ReproducibleScript:

  Try to compile Tktable 2.5 as stub-enabled extension on Windows. The

      result is

      that the symbol "XFillRectangle" is undefined. I already submitted a

      workaround for this problem to Jeffrey Hobbs. But the real problem is in

      Tk, so that's where it should be fixed.



  Patch:

  *** tkInt.decls.origWed Jun 16 22:11:28 1999

  --- tkInt.declsSun Jul 25 16:22:57 1999

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

  *** 1505,1510 ****

  --- 1505,1514 ----

        void XDrawLine (Display* d, Drawable dr, GC g, int x1, int y1, \

        int x2, int y2)

    }

  + declare 106 win {

  +     void XFillRectangle (Display* display, Drawable d, GC gc, \

  +     int x, int y, unsigned int width, unsigned int height)

  + }

    

    # X functions for Mac

    

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

  *** 1880,1883 ****

  --- 1884,1891 ----

    declare 82 mac {

        void XDrawLine (Display* d, Drawable dr, GC g, int x1, int y1, \

        int x2, int y2)

  + }

  + declare 83 mac {

  +     void XFillRectangle (Display* display, Drawable d, GC gc, \

  +     int x, int y, unsigned int width, unsigned int height)

    }



  PatchFiles:

  tkInt.decls


tkt_uuid: 220949ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.2
resolution: Duplicate
title: Stippled text on a canvas drawn in the wrong place using the wrong color
comment:
  OriginalBugID: 6240 Bug
  Version: 8.2
  SubmitDate: '2000-09-11'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Windows NT


  Name:
  Christopher Nelson

  ReproducibleScript:
  canvas .c -width 100 -height 100 -background white
  pack .c

  set id [.c create text 10 10 -fill green  -text "Text" -anchor nw -stipple gray50]
  set bb [.c bbox $id]

  # On UNIX, this box is around the text, on Win32, it's not.
  eval .c create rectangle $bb

  ObservedBehavior:
  On Win32 platforms (at least WinNT, maybe Win98), the text is not drawn where it should be.  The bounding box rectangle is in the same place on UNIX and 'Windows but the text is not.  Also, setting the color for the text has no effect on 'Windows.

  DesiredBehavior:
  Consistent behavior across platforms


tkt_uuid: 1436726fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 20. [tk_optionMenu]
priority: 4
foundin: obsolete: 8.4.12
resolution: None
title: -font option handled wrong on OS X
comment:
  I set the configuration option -font "size 7" for a created 
  tk_optionMenu but the font size is not changed. However, the box 
  reserved for the widget is altered, leaving the text only half-visible.

  I have attached a screenshot of this situation in action. Not also how 
  the widget borders are not coloured with the -highlightbackground as 
  should be, but are white. The -borderwidth option is set to 0. This is 
  probably related to an earlier bug I reported.


tkt_uuid: 564642ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #84: mouse motion filtering patch
comment:
  Attached is an implementation of TIP #84 to add a hook 
  that avoids the current mouse motion filtering.


tkt_uuid: 220404ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: 3 small bug fixes (Tk8.0.3, UNIX)
comment:
  OriginalBugID: 908 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Other
  OSVersion: Linux Redhat 4.2 (Intel)
  Machine: NA
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:
  Jan Nijtmans

  ObservedBehavior:
  1) typo on line 25: "tkl_ok" should be "tk_ok". Because this is the first
  time the "tk_ok" variable is used it doesn't have any adverse affect.
  But that doesn't change the fact that it clearly is a typo.

  2)  LIB_RUNTIME_DIR is set incorrectly for Tk if Tcl and Tk are installed
       in different directories. The "/lib" part is missing.

  3) long-standing bug: TK_LD_SEARCH_FLAGS is set incorrectly if  SHLIB_LD_LIBS='${LIBS}', and shared linking is performed through
  the C compiler. Systems affected are Linux, MP-RAS and NEXTSTEP,
  but also with gcc on many more systems. Currently SHLIB_LD_LIBS
  is empty for most sytem, but this is the real reason why shared linking
  fails  when SHLIB_LD_LIBS is set to '${LIBS}' (as it should be).

  Patch:
  *** unix/configure.in.origThu Nov 12 08:49:14 1998
  --- unix/configure.inThu Nov 12 08:51:30 1998
  ***************
  *** 21,27 ****

    AC_PROG_RANLIB
    AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available],
  !     [tk_ok=$enableval], [tkl_ok=no])
    if test "$tk_ok" = "yes"; then
        AC_PROG_CC
    else
  --- 21,27 ----

    AC_PROG_RANLIB
    AC_ARG_ENABLE(gcc, [  --enable-gcc            allow use of gcc if available],
  !     [tk_ok=$enableval], [tk_ok=no])
    if test "$tk_ok" = "yes"; then
        AC_PROG_CC
    else
  ***************
  *** 92,98 ****
    # search path to reflect this.

    if test "$TCL_EXEC_PREFIX" != "$exec_prefix"; then
  !     LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${TCL_EXEC_PREFIX}"
    fi

    #--------------------------------------------------------------------
  --- 92,98 ----
    # search path to reflect this.

    if test "$TCL_EXEC_PREFIX" != "$exec_prefix"; then
  !     LIB_RUNTIME_DIR="${LIB_RUNTIME_DIR}:${TCL_EXEC_PREFIX}/lib"
    fi

    #--------------------------------------------------------------------
  ***************
  *** 249,255 ****
    # variable LIB_RUNTIME_DIR.

    eval "TK_CC_SEARCH_FLAGS=\"$TCL_LD_SEARCH_FLAGS\""
  ! TK_LD_SEARCH_FLAGS=`echo ${TK_CC_SEARCH_FLAGS} |sed -e "s|-Wl,||g" -e "s|,| |g"`

    #--------------------------------------------------------------------
    #Check for the existence of various libraries.  The order here
  --- 249,262 ----
    # variable LIB_RUNTIME_DIR.

    eval "TK_CC_SEARCH_FLAGS=\"$TCL_LD_SEARCH_FLAGS\""
  ! case $SHLIB_LD in
  !     *ld*)
  ! TK_LD_SEARCH_FLAGS=`echo ${TK_CC_SEARCH_FLAGS} |sed -e "s|-Wl,||g" -e "s|,| |g"`
  ! ;;
  !     *)
  ! TK_LD_SEARCH_FLAGS="${TK_CC_SEARCH_FLAGS}"
  ! ;;
  ! esac

    #--------------------------------------------------------------------
    #Check for the existence of various libraries.  The order here

  PatchFiles:
  configure.in



  2) and 3) are already solved in the plus-patches for a long time. These
  fixes are required to turn Tk into a dynamical loadable package tclsh.
  Because 8.0.4 is especially aimed at bug solving, it would be
  valuable to fix at least these 3 small bugs in the core now.


tkt_uuid: 220452ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: tk_getOpenFile doesn't work
comment:
  OriginalBugID: 1490 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-11'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Other
  OSVersion: SCO5.0.4
  Machine: NA
  FixedDate: '1999-08-20'
  FixedInVersion: 8.0.5


  Name:
  Luca

  ReproducibleScript:
      Try the following code under Tcl/Tk 8.0.4 (I'm working on a SCO5.0.4
      machine).
      
      #!/bin/sh
      # The next line restarts using wish8.0  exec wish "$0" ${1+"$@"}
      
      wm withdraw .
      tk_getOpenFile -title "I don't work" -initialdir / 
      exit
      



  ObservedBehavior:
      Wherever you click the selected entry is the top-left one!!!!
      
      





      It works under Tcl/Tk 8.0.3
      
  --
  This works as expected under 8.0.5 and 8.2.0. 
  -- 08/20/1999 hobbs


tkt_uuid: 220484ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 2
foundin: obsolete: 8.1b3
resolution: Fixed
title: Widget tour error: The file lib\tk8.1\demos\twind.tcl is missing
comment:
  OriginalBugID: 1754 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-08'
  LastModified: '1999-10-30'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: X86
  FixedDate: '1999-10-30'
  FixedInVersion: 8.2.2


  Name:
  Ingemar Hansson

  Comments:
  Widget tour error:
      The link to "A text widget with embedded windows" doesn't work. 
      The file lib\tk8.1\demos\twind.tcl is missing



  This is missing in the Windows distrib for 8.2.1 as well. 
  -- 10/22/1999 hobbs
  For some reason this was set to be installed in demos\twin\released.tcl
  (where it can be found).  This was changed back to the expected value. 
  -- 10/30/1999 hobbs


tkt_uuid: 705567ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: unixWm.test failed
comment:
  after configuring tk 8.5 with enable 64 bit on a sparc
  solaris 8 system and sun's c compiler, I did a make all
  and then a make test.
  The test suite halted early with this error:
  unixWm.test
  Error in startup script: wrong # args: should be "test
  name desc ?options?"
      while executing
  "test unixWm-41.2 {ConfigureEvent procedure, menubars}
  {nonPortable testmenubar}
   unix {
      catch {destroy .t}
      toplevel .t -width 300 -height 200 -..."
      (file "/vol/tclsrcsol/tcl85/tk/tests/unixWm.test"
  line 1368)
      invoked from within
  "::source /vol/tclsrcsol/tcl85/tk/tests/unixWm.test"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list ::source $file]"
      (procedure "tcltest::runAllTests" line 57)
      invoked from within
  "tcltest::runAllTests"
      (file
  "/vol/tclsrcsol/tcl85/tk/unix/../tests/all.tcl" line 19)
  *** Error code 1
  make: Fatal error: Command failed for target `test'


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

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

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

  thx


tkt_uuid: 220244ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: dde command is not supported
comment:
  OriginalBugID: 3170 Bug
  Version: 8.1.1
  SubmitDate: '1999-10-25'
  LastModified: '1999-10-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 with Service patch 3
  Machine: X86
  ClosedDate: '1999-10-29'


  Name:
  Ramon Gallo

  Extensions:
  Tcl 8.1a2, Tk 8.1a2

  ReproducibleScript:
  My code was originally written under Tcl 8.1a2 and Tk 8.1a2 utlizing the
      "dde request" command line. When I attempted to run the same code under
      version 8.1.1, this command was not supported. According to the help
      file, the syntax had not changed from the version I had used.



  The dde command still exists, with the 'dde request' method
  still there.  The user is perhaps missing
      package require dde
  before using the dde command. 
  -- 10/29/1999 hobbs


tkt_uuid: 539903ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Doc error for "-message"
comment:
  The option -message takes an argument, the message to 
  be set. This is not specified in the manpage.


tkt_uuid: 2473120fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Fixed
title: Error popup from tk_chooseDirectory: bad option "warning"
comment:
  Trying to navigate to a directory without the proper permissions (e.g.: /root as a regular user) with tk_chooseDirectory results in an error popup window:
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
      while executing
  "error "bad option \"$cmdsw\": must be [tclListValidFlags cmd]""
      (procedure "tclParseConfigSpec" line 36)
      invoked from within
  "tclParseConfigSpec $w $specs "" $args"
      (procedure "tk::MessageBox" line 24)
      invoked from within
  "tk::MessageBox {*}$args"
      (procedure "tk_messageBox" line 2)
      invoked from within
  "tk_messageBox -type ok -parent $w -message -icon warning  [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]"
      (procedure "::tk::dialog::file::ListInvoke" line 14)
      invoked from within
  "::tk::dialog::file::ListInvoke $w [list $filenameFragment]"
      (procedure "::tk::dialog::file::chooseDir::DblClick" line 8)
      invoked from within
  "::tk::dialog::file::chooseDir::DblClick .__tk_choosedir"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 $data(-command)"
      (procedure "IconList_Invoke" line 5)
      invoked from within
  "IconList_Invoke $w"
      (procedure "tk::IconList_Double1" line 5)
      invoked from within
  "tk::IconList_Double1 .__tk_choosedir.contents.icons 204 11"
      (command bound to event)


tkt_uuid: 220178ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Docs missing for Tk_CancelIdleCall API
comment:
  OriginalBugID: 1892 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-28'
  Severity: MED
  Status: Closed
  Submitter: surles
  ChangedBy: kenj
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-28'




  04/28/1999 14:00 - kenj - Former Tk function now incorporated in Tcl. Tcl API documented in the Tcl man pages. Tk usage deprecated.


tkt_uuid: 800178ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: tk scaling -displayof wrong
comment:
  tk scaling -displayof sets/returns the wrong value e.g.

  # open a toplevel on another display
  % toplevel .remote -screen remote:0.0
  .remote

  # set scaling on default display
  % tk scaling -displayof . 1
  # check value
  % tk scaling -displayof .
  1.00078802206

  # set scaling on remote display
  % tk scaling -displayof .remote 2
  # check value
  % tk scaling -displayof .remote
  2.00157604413
  # check local display again (should still be 1.00078802206)
  % tk scaling -displayof .
  2.00157604413

  Consequently, winfo fpixels (and winfo pixels) does not
  calculate measurements correctly e.g. check DPI for
  each display:

  % winfo fpixels . 1i
  144.113475177
  % winfo fpixels .remote 1i
  100.036923077

  The last value equates to a tk scaling value of
  1.3894017094 which just happens to be the default
  scaling value as set by the X server on the remote
  display. It seems that 'tk scaling' always sets and
  reports values for the default screen.

  Linux 2.4.21 / KDE 3.1


tkt_uuid: 434205ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: itemconfigure doesn't work on Win2000
comment:
  When trying to use itemconfigure with a listbox on 
  windows 2000, TK reports that it isn't a valid 
  option.  i.e. "bad option "itemconfigure": must be 
  active,bbox...." etc. Tried this under TCL 8.4 as well 
  and got same result.  Same script works fine on 
  Windows 95 and 98.

  #######  this was the proc that failed
  proc writeLine {} {
      # Writes out one line of data to the list box
      incr g::lineNo
      .listb insert end $g::line
      # If more than 7 days old then put line item in 
  yellow
      if {$g::testTime > 7} {
          .listb itemconfigure $g::lineNo -background 
  yellow
      }
  }


tkt_uuid: 721514ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: tk:tkWinMenuKey is redundant name
comment:
  A recent commit to the HEAD revised
  Win menu bindings to bind to a new
  private command exposed at the
  script level by the name tk::tkWinMenuKey.

  This is a very good change, placing more
  configurability at the script level.  Good work.

  My only quibble is that the string "tk" doesn't
  need to be in the command name twice.

  How about tk::WinMenuKey ?

  That alternative would also follow Style
  Guide conventions for private command
  names.


tkt_uuid: 220595ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: tk tests need to use LIBPATH under AIX as well
comment:
  OriginalBugID: 2797 Bug
  Version: 8.2
  SubmitDate: '1999-09-16'
  LastModified: '1999-09-20'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.3.2
  Machine: RS6000
  FixedDate: '1999-09-20'
  FixedInVersion: 8.2.1


  Name:
  Nick Kisseberth

  Comments:
  This patch also includes a line to include the definition of
      SHLIB_LD_LIBS, this is needed to work with the configuration patches
      I will post shortly.

  ObservedBehavior:
  tk's tests also need to set LIBPATH in addition to LD_LIBRARY_PATH in
      order
      to work as designed under AIX

  Patch:
  *** tk8.2.0/unix/Makefile.in    Fri Aug 13 17:06:14 1999
  --- tk8.2.0-AIX/unix/Makefile.in        Sat Sep 11 17:40:15 1999
  ***************
  *** 197,202 ****
  --- 197,203 ----
    # The values of the symbolis normally set by the configure script.

    SHLIB_LD = @SHLIB_LD@
  + SHLIB_LD_LIBS = @SHLIB_LD_LIBS@

    # Additional search flags needed to find the various shared libraries
    # at run-time.  The first symbol is for use when creating a binary
  ***************
  *** 396,401 ****
  --- 397,403 ----
    test: tktest
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  +       LIBPATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH}; export LIBPATH;  SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH};  export SHLIB_PATH;  TCL_LIBRARY=@TCL_SRC_DIR@/library; export TCL_LIBRARY;  ***************
  *** 406,411 ****
  --- 408,414 ----
    runtest:
          LD_LIBRARY_PATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH};  export LD_LIBRARY_PATH;  +       LIBPATH=`pwd`:${TCL_BIN_DIR}:${LD_LIBRARY_PATH}; export LIBPATH;  SHLIB_PATH=`pwd`:${TCL_BIN_DIR}:${SHLIB_PATH};  export SHLIB_PATH;  TCL_LIBRARY=@TCL_SRC_DIR@/library; export TCL_LIBRARY;  
  PatchFiles:
  unix/Makefile.in



  Added to 8.2.1 (note small bug in patch - LD_LIBRARY_PATH should
  be LIBPATH for the LIBPATH lines). 
  -- 09/20/1999 hobbs


tkt_uuid: 220395ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: hidemargin broken in tk8.1a2 under UNIX
comment:
  OriginalBugID: 859 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1998-11-25'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-25'
  FixedInVersion: 8.1b1


          the -hidemargin option for menu items is broken in tk8.1
  under UNIX.  Menu items have a margin added to them even when
  '-hidemargin 1' is used on all items in a menu.

  Patch included in patches page


tkt_uuid: 1191895fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Fixed
title: text widget hang on <Control-Key-Up>
comment:
  I have found a hang condition in the text widget easily
  reproducible using wish (or tclsh after "package
  require Tk"):

  $ wish
  % text .t
  .t
  % .t insert end " Text"
  % pack .t

  Note that the inserted text begins with a space.

  Then click in the displayed text widget (so that it
  will get focus) and press <Control-Key-Up> twice. On
  the first keypress the cursor moves to the start of the
  word "Text" (just after the initial space); on the
  second keypress wish hangs consuming 100% CPU and no
  longer responds to any input, including closing its
  window from the window manager (I need to kill it with
  Control-C from terminal).

  Reproducible in:
  - system-installed Tcl/Tk 8.4.8  on Linux x86
  - tclkit-linux-x86 8.4.9
  - tclkit-linux-x86 8.5a2
  - tclkit-win32.upx.exe 8.4.9


tkt_uuid: 917631ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: None
title: Grid information in wm may be incorrect (patch included)
comment:
  The grid information provided to the window manager if
  -setgrid is used may be incorrect. The window manager
  is given information based on the requested size, not
  the actual size. It may also become confused by resizes
  if the gridded window does not get all the size-change.

  The consequences may be serious since if the window
  actually becomes much bigger than requested then it may
  be impossible to scale it down to a reasonable size
  since minsize is based on when tk thinks the window
  will be 1x1.

  I have attached a compressed tarfile which contains two
  demostration scripts and a patch.  The demonstration
  scripts each puts up a paned window (implemented with
  pack and panedwindow) containing a listbox and a text
  widget. Radiobuttons allows one to switch the widget
  controlling the grid. Try resizing the window and
  notice that the grid information in the window manager
  often is completely wrong.

  I have tested this on Unix (ctwm). The patch includes
  code for Mac and Windows(empty functions) but I have
  not been able to test these parts. The patch defines a
  new function Tk_UpdateGrid() which the listbox and text
  widgets calls whenever they are resized. I also
  modified the internal UpdateSizeHints() function to
  either use the requested size or the actual size.


tkt_uuid: 220695ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: extra / in SCRIPT_INSTALL_DIR path
comment:
  OriginalBugID: 4265 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: QNX
  Machine: PIII 500 MHz 128 MB
  FixedDate: '2000-03-01'
  FixedInVersion: 8.3.1


  Name: Bruce Edge

  ReproducibleScript:
  make; make install

  ObservedBehavior:
  Can't create dirs for installing libs as there are 2 "/" in start of path.

  DesiredBehavior:
  A single / so dir can be created.

  Patch:
  # //8/usr/local/src/tk8.3.0/unix> diff Makefile Makefile.orig
  45c45
  < SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)$(TK_LIBRARY)
  ---
  > SCRIPT_INSTALL_DIR =  $(INSTALL_ROOT)/$(TK_LIBRARY)

  PatchFiles:
  Whatever is used to gen Makefile, Makefile.in?



  Fixed in Makefile.in for 8.3.1. 
  -- 03/01/2000 hobbs


tkt_uuid: 220771ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Windows performance problems with widget rendering
comment:
  OriginalBugID: 580 RFE
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '2000-04-11'
  Severity: LOW
  Status: Assigned
  Submitter: hershey
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  When I talked on the phone last week with John Vella of Mentor Graphics,
  he mentioned that they had had performance problems with widget rendering
  under Windows.  The way they solved this problem was to compile Tk using
  the Xlib interfaces for Unix, even though it would run on Windows.  Then
  they used the Hummingbird X emulator to run the application on Windows.
  With this arrangement, they got much better rendering performance.  This
  means that the Hummingbird code must be emulating X libraries calls
  differently than Tk does, and it must have a more efficient way of doing
  this.

  When we eventually get around to tuning the Tk performance under Windows,
  we should see if we can learn more about how Hummingbird does things.

  ________________________________________________________________________
  John Ousterhout                                650-843-6902 tel

  Changed to RFE, this is something to consider, but at least Tk works. 
  -- 08/20/1999 hobbs
  Should consider patch from Leo Schubert for 8.4 for Windows speedups. 
  -- 04/11/2000 hobbs


tkt_uuid: 560679ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 6
foundin: None
resolution: Fixed
title: Missing -container crashes wish
comment:
  Embedding in a toplevel that has not set -container causes
  a crash. (At least on Win98, where I have seen it.)

  Script:

  toplevel .real 
  toplevel .embd -use [winfo id .real]

  Stack trace:

  Tk_GeometryRequest(Tk_Window_ * 0x00000000, int 0x000000c8,
    int 0x000000c8) line 154 + 6 bytes
  EmbedGeometryRequest(Container * 0x00beed00, int
  0x000000c8,
    int 0x000000c8) line 444 + 17 bytes
  TkWinEmbeddedEventProc(HWND__ * 0x00000498, unsigned
  int 0x00000401,
    unsigned int 0x000000c8, long 0x000000c8) line 400 +
  17 bytes
  TkWinChildProc(HWND__ * 0x00000498, unsigned int
  0x00000401,
    unsigned int 0x000000c8, long 0x000000c8) line 650 +
  21 bytes
  TopLevelEventProc(int * 0x00beef00, _XEvent *
  0x00bee988) line 3601


  The crash happens because Tk_GeometryRequest is called
  with a
  NULL pointer by EmbedGeometryRequest.
  My guess is that EmbedGeometryRequest should check if
  containerPtr->parentPtr is NULL.


tkt_uuid: 2075285fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Wont Fix
title: grid column not visible
comment:
  In the script below, the column containing canvas .c is not visible. OTOH if the entry .e is created with '-width 4' evrything looks fine. 

  I'm using ActiveTcl 8.5.4 on Windows XP, but I also see this with Tclkit 8.5a4 on Linux.

  #entry .e -width 4
  entry .e -width 40
  grid .e -columnspan 9 -sticky e
  text .t1 -width 10 -height 20
  grid .t1 -row 1 -column 0 -columnspan 3 -sticky ewns
  grid columnconfigure . 1 -weight 1
  canvas .c -width 9 -height 1 -relief raised -bg black 
  grid .c -row 1 -column 3 -columnspan 3 -sticky ns
  text .t2 -width 10 -height 20
  grid .t2 -row 1 -column 6 -columnspan 3 -sticky ewns
  grid columnconfigure . 7 -weight 1
  wm deiconify .


tkt_uuid: 220184ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: tk_getOpenFile command
comment:
  OriginalBugID: 1943 Bug
  Version: 8.0p2
  SubmitDate: '1999-04-27'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: SunOS
  Machine: Sparc
  ClosedDate: '1999-08-20'


  Name:
  Teresa

  ReproducibleScript:
  We keep getting the error:
      
      bgerror failed to handle background error.
          Original error: cannot auto-load command "tkFDialog"
          Error in bgerror: invalid command name "bgerror"
      when we use the tk_getOpenFile command



  This appears to be a Tk installation problem.  Please ensure that
  Tk was fully installed and that it is version correct against the
  libraries you are using. 
  -- 08/20/1999 hobbs


tkt_uuid: 3604346fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 8
severity: Minor
foundin: None
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: 1080198fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: tag -wrap should be checked
comment:
  Reported in comp.lang.tcl

  Please, do
    pack [text .t -width 10 -height 5 -wrap word -font fixed]
    .t tag configure toolong -wrap char
    .t insert end "a wa" {} "ytoolonglinetofitanywhe"
  toolong "re"
  and convince me I get exactly what I asked for.

  The line is wrapped after the 'a', because the wrap
  attribute is taken from the beginning of the line, when
  it should probably be wrapped somewhere much further along.

  i.e. the above gives

  a
  waytoolongli
  netofitanywh
  ere

  when it should give:

  a waytoolon
  glinetofitany
  where


tkt_uuid: 2513753fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: --with-tk is missing from SVN.
comment:
  Hello, I was trying to build tkImg for windows, and I noticed that it was trying to load the include files from a fixed path. I tried to run ./configure --with-tcl=PATH --with-tk=PATH, but --with-tk simply isn't supported by the current configuration file. 

  Mjanssen said I should file a bug report in the TCL irc channel, because this feature should be supported. According to his own words (in the tcl irc channel):

  "<ijchain> <mjanssen> Megabyte file a bug for the missing --with-tk option, the README refers to it"

  The lack of this option means that I'm having to do some black magic to get TkImg compiled within Windows (using MSYS + Mingw).


tkt_uuid: 219844ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Insert in entries on Windows
comment:
  OriginalBugID: 609 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Closed
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-30'
  FixedInVersion: NA
  ClosedDate: '1998-08-05'



   Tom Tromey <tromey@creche.cygnus.com>
  Tk 8.0 on NT 4.0.

  On Windows, the <Insert> key should do nothing in entries.
  Right now it inserts the contents of the selection.
  It also shadows the Shift-Insert key sequence (which should generate
  the <<Paste>> virtual event).

  I fixed it by removing the <Insert> binding from entry.tcl when on
  Windows.

  Tom



  duplicate of bug 52


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: 863271ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: TIP Implementation
resolution: Accepted
title: Patch implements TIP #110 in 8.5
comment:
  The attached files implement the feature described in TIP 
  #110.  All but the -triimage option have been implemented.

  Since this TIP is still in draft, this implementation is subject 
  to change.


tkt_uuid: 895082ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 4
foundin: obsolete: 8.4.5
resolution: None
title: TkAqua: -use option to wish not implemented on OS X
comment:
  The -use option to wish appears to not have been implemented in 
  the OS X port of Tcl/Tk. A small sample script:

  frame .f -container 1
  update idletasks
  exec $argv0 -use [winfo id .f]

  This script always errors with a message about the id not being a 
  valid Tk window. This message is a bit of a red-herring, as it 
  appears that in actual fact, no handler is registered to deal with 
  embedding the root window of wish (i.e. 
  Tk_MacOSXSetEmbedHandler is never called - in macosx/
  tkMacOSXEmbed.c).

  As -use/-container appear to be implemented and working 
  correctly for toplevels in a single wish app, I suspect it should be a 
  small amount of work to add to code to implement the -use option 
  to wish. I'll have a look, and see if I can come up with a patch.


tkt_uuid: 2108391fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: None
title: entry -validate set to none incorrectly
comment:
  #
  # This bug MAY be related to bug 1520118.
  #
  # This should be the minimal test script to repro 
  # the problem:
  #
  set foo ""

  pack [entry .foo -validate key -validatecommand [list regexp -- {^[A-Z]*$} %P] -textvariable ::foo]

  bind . <F1> [list doStuff]
  bind . <F2> [list .foo configure -show ""]

  proc doStuff {} {
    set ::foo "ABCD        "; # <-- has invalid chars
    .foo configure -show *
  }


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: 220016ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Rotating Text in Canvas Widget
comment:
  OriginalBugID: 2652 RFE
  Version: 8.0p2
  SubmitDate: '1999-08-31'
  LastModified: '2000-01-12'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 971
  OS: Windows NT
  OSVersion: 4.0 SP-4
  Machine: X86
  ClosedDate: '2000-01-12'


  Name:
  Burl Goree

  DesiredBehavior:
  I would like the ability to rotate test and have it displayed
      vertically.  The only way I'm able to accomplish this currently is to
      create a trasparent gif (using other software) of the text I would want
      to rotate.  Are there any plans to add the ability to display text
      vertically or rotate a text object?


tkt_uuid: 1032941fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Duplicate
title: menu bar menus sometimes in wrong place under aqua
comment:
  On MacOS X, using aqua tcl/tk 8.4.7 or earlier, create a 
  menu bar using the old technique of creating a frame and 
  packing menubuttons into it. I observe that menus are 
  sometimes posted at very much the wrong location on the 
  screen (e.g. 1/4 to 1/2 screen away from where it should 
  be).

  I see the problem intermittently on my tcl/tk application and 
  haven't found any way to force it to misbehave or to 
  behave. Once it starts it seems to persist, so I have to quit 
  and start over. It also appears that once it starts, bringing a 
  different application to the front and then bringing my tcl/tk 
  application to the front seems to make the offset worse.

  -- Russell


tkt_uuid: 1461650fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: TkAqua text font metrics wrong
comment:
  Benny,

  There's still a problem with font metrics. The following example (which 
  uses a monospaced font):

      toplevel .tt
      set font "monaco 9"
      # font metrics $font claims it is "fixed" i.e. monospace
      pack [text .tt.t -font $font] -fill both -expand 1
      set w .tt.t
      $w configure -tabstyle wordprocessor
      
      # tab size 8 fails
      $w insert 1.0 "11111111222222223333333344444444\n"
      $w insert 1.0 "\ta\tb\tc\td\n"
      
      # tab size 4 fails
      $w tag configure tab4 -tabs "[expr {4 * [font measure $font 0]}] left"
      $w insert 1.0 "11111111222222223333333344444444\n"
      $w insert 1.0 "\ta\tb\tc\td\n"
      $w tag add tab4 1.0 3.0

  should display those lines with 'a' 'b' 'c' 'd' aligned at each 8th or 4th 
  character in the long lines with numbers only.

  But they are laid out shorter than that. The 'a' in the first example is 
  about 1.5 characters too far to the left (and cumulatively the same for 
  the rest). The tabsize 4 example has everything about 0.75 characters 
  too far to the left.

  So it seems the calculation of '4 * [font measure $font 0]' is wrong (too 
  low) as is the internal calculation made in tkText.c:

     Tk_TextWidth(textPtr->tkfont, "0", 1) * 8;

  for the default tabsize of 8.

  This means one can't use the text widget to do decent layout of 
  programming code, since the tabstops are all wrong. [Note: this all 
  works fine on Windows, and used to work ok on MacOS X]

  Vince.


tkt_uuid: 1676770fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: grid-21.7 breaks other tests
comment:
  The test failures in reports

  1676685 
  1676682
  1676680
  1676677
  1676675 
  1676673
  1676672 

  all go away if test grid-21.7
  is skipped.


tkt_uuid: 1572743fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 8
foundin: obsolete: 8.5a4
resolution: None
title: Tk hangs on <KeyPress> Events when executed in command pipe
comment:
  Key press events make Tk hung and not responding
  anymore on windows. This happens when a Tclsh/Wish is
  executed in a command pipeline (via [open "|"]).

  It can be easily reproduced in a Tclsh on windows (e.g.
  in ActiveTcl's Tclsh84 or Tclsh85):

  % set backend [open "| [info nameofexe]" r+]
  % fconfigure $backend -buffering line
  % puts $backend "package re Tk"

  Then, click in the appearing wish main window and press
  any key. The window hangs forever and the only way out
  there is by

  % puts $backend "exit"

  in the Tclsh console from where the pipe was opened

  I don't know about other platforms, just tried it out
  on Windows.


tkt_uuid: 1908284fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Duplicate
title: Aqua: SetPortPenPixPat() Leak in TkPhotoPutBlock
comment:
  My TclTk extension calls TkPhotoPutZoomedBlock. On Linux and Windows, when I call the routine 10,000 times, I get no significant increase in memory consumption. I can say with confidence that the leakage per call is less than 50 bytes (and is most likely zero).

  On MacOS, however, I see a roughly 650-byte (+-50 bytes) increase in memory consumption per call to TkPhotoPutZoomedBlock. When I switch to TkPhotoPutBlock, the increase drops to around 300 bytes (+-50 bytes).

  I get the same leak with TclTk 8.4.16 and TclTk 8.5.1. 

  The following script, which I believe calls TkPhotoPutBlock or TkPhotoPutZoomedBlock, generates a 525-byte (+-50 bytes) leak per iteration.

  -------------
  set p [image create photo]
  label .l -image $p
  pack .l
  for {set i 1} {$i <= 1000} {incr i} {
  $p read ~/Desktop/An_Image.gif -format GIF
  }
  image delete $p
  destroy .l
  --------------

  I conclude that the MacOS implementation of both routines is leaky. The result is that my MacOS code will crash after three days of continuous data-taking.

  Kevan Hashemi


tkt_uuid: 787065ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: scale widget error
comment:
  Hello.

  I've used Tcl/Tk8.4.4 on Windows XP.
  If the following codes are performed and button-3 is 
  pushed on the scale widget, an error will occur.
  Is it bug?

  set var 50
  pack [scale .s -width 12 -from 0 -to 100 -variable var -
  orient horizontal]

  -----
  Satoshi Imai
  s-imai@japan.interq.or.jp


tkt_uuid: 1737288fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Text segfault with Modified event after delete
comment:
  8.4 text widget has problems when processing <<Modified>> event caused by delete. This segfaults once the widget gets focus (sorry, I cannot test 8.5):

  #!/usr/bin/wish8.4
  text .t
  .t insert insert x
  bind .t <<Modified>> update
  .t edit modified 0
  pack .t

  update
  after 4000
  .t delete 1.0 1.1

  Alternatively, use just the first 6 lines, click in the left halve of the window and press Backspace to get Segmentation fault as well.

  This is a minimalistic example and rather strange one, doing "update" does not make much sense. However it ilustrates likely data corruption which has other symptoms as well.

  I wanted to invoke procedure after every text change and I found that after delete and <<Modified>> event, this procedure still reports text as it was BEFORE delete (while inserting chars is fine). Example:

  proc modified {} {
    if {![.t edit modified]} {
      # invoked by itself
      return
    }
    .t edit modified 0
    puts text:[.t get 1.0 end]
  }
  text .t
  bind .t <<Modified>> modified
  pack .t

  Now type "A" in text widget, delete it and type "X". Response is:

  text:A    <-- OK
  text:A    <-- WRONG! Text is empty now!
  text:X    <-- OK

  Text widget itself looks as it should ("A" appears, disappears, "X" appears). Things also look OK when inspected outside of the event processing procedure. Just after delete, while processing <<Modified>>, data structures seem to be inconsistent, leading to slight errors or even segfaults.

  Vaclav Hanzl

  hanzl (at) noel dot feld dot cvut dot cz


tkt_uuid: 220924ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: Incorrect multibyte characters are displayed
comment:
  OriginalBugID: 5850 Bug
  Version: 8.2.1
  SubmitDate: '2000-06-07'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: Digital Unix
  Machine: Compaq Alpha machine


  Name:

  Wai-man Long


  Comments:

  In the FontMapLoadPage() routine, an assumption is made that the

      character being tested has the same number of byte as the font being

      checked against. This is simply not true. In case, a one-byte font

      covering the 0x80-0xff range is put in front of the 2-byte font, as in

      the case of the SJIS locale, a 2-byte value will falsely match

      character in the one-byte font because of the dropping of the second

      byte in the hi/lo assignment code.


      To fix this problem, we need to look at the actual size of the

      multibyte string generated instead of whether the current font is a

      1-byte or 2-byte font. The byte length of the converted string can be

      retrieved from the second last argument of the Tcl_UtfToExternal()

      call.


  ReproducibleScript:

  This problem happens when multiple fonts are used by the Tcl/Tk

  application to display characters, as in the case for most Asian

  languages. In my case, the font list contains


  1. A single-byte PCF font containing glyphs for ASCII and SJIS narrow kana

     characters.

  2. A 2-byte fonts containing JISX0208 characters.


  ObservedBehavior:

  When a button containing 2-byte SJIS characters are displayed, some

  narrow kana and control characters are displayed instead.


  DesiredBehavior:

  I expected the 2-byte SJIS characters to be displayed correctly.


  Patch:

  [ ./Tcl/tk8.2/unix/tkUnixFont.c ]

   Diffs between Tcl/tk8.2/unix/tkUnixFont.c and Tcl/tk8.2/unix/tkUnixFont.c (Chec

  kout branch)

  *** 1906,1918 ****

  --- 1906,1939 ----

        end = (row + 1) << FONTMAP_SHIFT;

        for (i = row << FONTMAP_SHIFT; i < end; i++) {

          int hi, lo;

  + #ifndef       NO_DEC_I18N

  +       /*

  +        * QAR 80235 is caused by the presence of a one-byte font covering

  +        * the 0x80-0xff range in front of the 2-byte font, as in the case

  +        * of the SJIS locale. In this case, a 2-byte value will falsely

  +        * match character in the one-byte font because of the dropping of

  +        * the second byte in the hi/lo assignment code. To fix this problem,

  +        * we need to look at the actual size of the multibyte string

  +        * generated instead of whether the current font is a 1-byte or

  +        * 2-byte font.

  +        */

  +       int len;        /* Length of the destination multibyte string */

  + #endif


          if (Tcl_UtfToExternal(NULL, encoding, src, Tcl_UniCharToUtf(i, src),

                  TCL_ENCODING_STOPONERROR, NULL, buf, sizeof(buf), NULL,

  + #ifndef       NO_DEC_I18N

  +               &len, NULL) != TCL_OK) {

  + #else

                  NULL, NULL) != TCL_OK) {

  + #endif

              continue;

          }

  + #ifndef       NO_DEC_I18N

  +       if (len > 1) {

  + #else

          if (isTwoByteFont) {

  + #endif

              hi = ((unsigned char *) buf)[0];

              lo = ((unsigned char *) buf)[1];

          } else {


  PatchFiles:

  tk8.2/unix/tkUnixFont.c


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: 220075ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Duplicate
title: 1-dimension resizable toplevel shrinks in other dimension
comment:
  OriginalBugID: 4464 Bug
  Version: 8.3
  SubmitDate: '2000-03-22'
  LastModified: '2000-04-07'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4353
  OS: Macintosh
  OSVersion: MacOS S-9.0 (Swedish)
  Machine: G3/350 (B/W), iMac 233
  ClosedDate: '2000-04-07'


  Name:
  Johan Dahl

  ReproducibleScript:
  toplevel .w
  wm resizable .w 1 0

  ObservedBehavior:
  If I resize a toplevel window which is restricted in one dimension it shrinks one pixel in the other dimesion. This is related to the bug that causes a window to shrink one pixel in each dimension as soon as I click in the resize control

  DesiredBehavior:
  It should only resize in one dimension


tkt_uuid: 1905656fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Asking the width of a textwidget don't work like expected.
comment:
  The following code returns allways the same value (80) for '.t cget -width' even after resizing the window:

   text .t
   pack .t -fill both -expand 1
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   .t insert end [string repeat a 200]
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80


   # resize window with mouse
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   wm geometry . 1000x500
   update
   wm geometry .       ;# returns 1000x500
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

  On the other side: Modifying the width with -width works:

   text .t
   pack .t -fill both -expand 1
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   .t insert end [string repeat a 200]
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   .t configure -width 120
   update
   wm geometry .       ;# returns 964x388 ...
   .t cget -width      ;# returns 120
   .t configure -width ;# returns -width width Width 80 120

   .t configure -width 80
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80


  I tried this with ActiveTcl 8.5.1.0, ETcl 1.0-rc25 und Etcl 1.0-rc23. This means this happens on Tcl 8.4 and 8.5.
   


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


tkt_uuid: 220593ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Mac: focus-frame drawn wrongly
comment:
  OriginalBugID: 2728 Bug
  Version: 8.0.5
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-10'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 8.5
  Machine: Power PC
  FixedDate: '1999-09-10'
  FixedInVersion: 8.2


  Name:
  Andreas Leitgeb

  Comments:
  I only have irregular access to a Mac, and I'm not very much into Mac's
      either.  Usually I develop under Linux with unix/X11-variant of Tcl/Tk.

  ReproducibleScript:
  frame .f  -takefocus 1 -highlightthickness 2   -bd 5 -relief sunken
      label .f.l  -highlightthickness 2 -bd 5 -relief raised -text foo
      # the reliefs are only there to separate the highlightborders visually
      pack .f.l; pack .f
      focus -force .f.l

  ObservedBehavior:
  On Mac-Tk,  the highlightborder on the label is not drawn black at all
      (but the frame is there, just white), and the highlightborder on the
      frame is only one pixel thick. it is always one pixel thinner than
      specified to the option, and the remaining one-pixel-rectangle is not
      drawn at all.  if a window
      is placed above it, and then withdrawn, then that one-pixel-rectangle
      will remain "dirty"

  DesiredBehavior:
  Whether or not  Mac's native-look  allows for focus-rectangles,  that
      "dirty"-one-pixel-rectangle
      is definitely a bug.  However, I'd prefer highlighting of widgets, whose
      -highlight...-options are set appropriately, even on Mac's.



  Fixed in 8.2.0. 
  -- 09/10/1999 hobbs


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: 220362ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Typo in tkWinMenu.c causes bad window geoms
comment:
  OriginalBugID: 618 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1998-08-03'
  Severity: LOW
  Status: Released
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: 8.0.3
  ClosedDate: '1998-08-03'



  Found a typo bug in tkWinMenu.c that causes incorrect geometry
  calculations for toplevels that have system menubars.  Symptoms of
  the bug are flickering size changes during mapping a toplevel.

  File: tkWinMenu.c
  Line: 541
  Routine: ReconfigureWindowsMenu
  Code:

      if ((menuPtr->menuType == MENUBAR)
              && (menuPtr->parentTopLevelPtr != NULL)) {
          width = Tk_Width(menuPtr->parentTopLevelPtr);
  //BUG   height = Tk_Width(menuPtr->parentTopLevelPtr);
          height = Tk_Height(menuPtr->parentTopLevelPtr);
      }


tkt_uuid: 469670ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk_get*File doesn't filter w/ motif
comment:
  When tk_strictMotif is set, tk_getOpenFile and tk_getSave file fail to filter if more than one pattern 
  is provided for a filetype.

  For example:

  With a .o file in the current directory:

     tk_getOpenFile -filetypes {{"Foo" {.f .o}} {"Bar" {.b .p}} {"Tcl" {.tcl}}}

  will show no files to choose from.

  xmfbox.tcl was missing a foreach to iterate over patterns in the filter spec.  The foreach was in 
  tkfbox.tcl.


tkt_uuid: 861839ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Unicode support in Dialog title and message
comment:
  Disposed of Unicode->Pascal String->Unicode loop in Dialog 
  Manager that was causing title and message of Open and 
  Save dialogs to become "??????" when using complex 
  scripts.


tkt_uuid: 621241ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Grid size becomes incorrect
comment:
  A grid keeps track of the number of rows and columns,
  but this count
  is not updated when you remove (either by destroying or
  forgetting) a child. However the count is recalculated
  when the 'grid size' function is called.  This gives
  some very strange effects, the following program gives
  a different result depeding on if the call to 'grid
  size' is done or not.

  label .l1 -text l1
  grid .l1
  grid forget .l1

  # The output differs depending on if the following line
  # is commented or not
  #grid size .

  label .l2 -text l2
  grid .l2
  puts "Result [grid size .]"
  destroy .


  I have attached a patch which solves the bug and also
  includes two new test-cases for it.


tkt_uuid: 1440417fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 3 Low
foundin: obsolete: 8.5a4
resolution: Fixed
title: Xft segfaults if fontconfig cannot find any font
comment:
  on SunOS 5.8 wish8.5 gets a segmentation fault.
  Interactive it
  could be reprocuded by 

  $ wish
  % listbox .lb

  signal SEGV (no mapping at the fault address) in
  Tk_AllocFontFromObj at line
  1094 in file "tkFont.c"
   1094       fontPtr->resourceRefCount = 1;
  (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
  =>[1] Tk_AllocFontFromObj(interp = 0x29eb8, tkwin =
  0x760b8, objPtr =
  0x70558), line 1094 in "tkFont.c"
    [2] DoObjConfig(interp = 0x29eb8, recordPtr = 0x767b8
  "", optionPtr =
  0x77a98, valuePtr = 0x70558, tkwin = 0x760b8,
  savedOptionPtr = (nil)), line
  775 in "tkConfig.c"
    [3] Tk_InitOptions(interp = 0x29eb8, recordPtr =
  0x767b8 "", optionTable =
  0x779b0, tkwin = 0x760b8), line 556 in "tkConfig.c"
    [4] Tk_ListboxObjCmd(clientData = (nil), interp =
  0x29eb8, objc = 2, objv
  = 0x2abc4), line 561 in "tkListbox.c"
  dbx: warning: can't find file
  "/projekte/backup/tools/unix/build/tcl/tcl/unix/suns8/tclBasic.o"
  dbx: warning: see `help finding-files'
    [5] TclEvalObjvInternal(0x29eb8, 0x2, 0x2abc4, 0x0,
  0x0, 0x0), at
  0xfefdf2a4
  dbx: warning: can't find file
  "/projekte/backup/tools/unix/build/tcl/tcl/unix/suns8/tclExecute.o"
    [6] TclExecuteByteCode(0x29eb8, 0x67378, 0xff3e79ec,
  0x0, 0x673e4,
  0x2abc8), at 0xff041d18
    [7] TclCompEvalObj(0x29eb8, 0x9c6a0, 0x0, 0x7efefeff,
  0x67378, 0x29eb8),
  at 0xff03eb74
    [8] Tcl_EvalObjEx(0x29eb8, 0x9c6a0, 0x20000, 0x0,
  0xa, 0x29eb8), at
  0xfefe0814
  dbx: warning: can't find file
  "/projekte/backup/tools/unix/build/tcl/tcl/unix/suns8/tclHistory.o"
    [9] Tcl_RecordAndEvalObj(0x29eb8, 0x9c6a0, 0x20000,
  0x7efefeff,
  0x81010100, 0x37a30), at 0xff062334
    [10] Tcl_RecordAndEval(0x29eb8, 0x34c78, 0x20000,
  0x5ab78, 0x22304,
  0x9c6a0), at 0xff062168
    [11] StdinProc(clientData = 0x5ab78, mask = 2), line
  376 in "tkMain.c"
  dbx: warning: can't find file
  "/projekte/backup/tools/unix/build/tcl/tcl/unix/suns8/tclIO.o"
    [12] Tcl_NotifyChannel(0x5ab78, 0x2, 0xfef1a000, 0x0,
  0x38780, 0x0), at
  0xff077384
  dbx: warning: can't find file
  "/projekte/backup/tools/unix/build/tcl/tcl/unix/suns8/tclUnixNotfy.o"
    [13] FileHandlerEventProc(0x43000, 0xfffffffd, 0x0,
  0x1, 0x29dac,
  0xffbeece0), at 0xff105c00
  dbx: warning: can't find file
  "/projekte/backup/tools/unix/build/tcl/tcl/unix/suns8/tclNotify.o"
    [14] Tcl_ServiceEvent(0xfffffffd, 0xfffffffd,
  0xff390018, 0xff3e7fe8, 0x0,
  0x2), at 0xff0a21ec
    [15] Tcl_DoOneEvent(0x0, 0x59b78, 0x0, 0x1, 0x1,
  0x37a18), at 0xff0a28d4
    [16] Tk_MainLoop(), line 2143 in "tkEvent.c"
    [17] Tk_MainEx(argc = -1, argv = 0xffbef1a0,
  appInitProc = 0x11510 =
  &Tcl_AppInit(Tcl_Interp *interp), interp = 0x29eb8),
  line 308 in "tkMain.c"
    [18] main(argc = 1, argv = 0xffbef19c), line 68 in
  "tkAppInit.c"

  wish cannot load a font. in tkFont.c

  (1090)    fontPtr = TkpGetFontFromAttributes(NULL,
  tkwin, &fa);

  The Nullpointer comes from here:

  tkUnixRFont.c: 143
      set = FcFontSort(0, pattern, FcTrue, &charset,
  &result);

      if (!set) {
  FcPatternDestroy(pattern);
  ckfree((char *) fontPtr);
  return NULL;
      }

  here set is NULL.


tkt_uuid: 616986ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: Wish won't 'Hide'
comment:
  Tkaqua ignores the MacOS X 'Hide' operation (either 
  through hide others, or hide self).

  When hiding, Tkaqua should withdraw all of its 
  windows, etc.


tkt_uuid: 220130ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: ld.so.1: ./wish8.0: fatal: libX11.so.6.1: open failed: No such file or directory
comment:
  OriginalBugID: 1371 Bug
  Version: 8.0.3
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-16'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: stanton
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-04-16'


  Name:
  Ron Forrester

  ReproducibleScript:
  ./wish8.0

  ObservedBehavior:
  ld.so.1: ./wish8.0: fatal: libX11.so.6.1: open failed: No such file or directory

  DesiredBehavior:
  Expect to see the shell prompt for tk...



  Brand new install.
  installed packages tcl.8.0.3.sparc.solaris.2.6.pkg.tgz and tk.8.0.3.sparc.solaris.2.6.pkg.tgz with no problems.
  ./tclsh8.0 shell works fine.

  Could it be a PATH problem?

  Sounds like  a version problem. The solaris packages were built on Solaris 2.5 and possibly the new solaris has a different X11.  The user should check the LD_LIBRARY_PATH.  

  There is nothing to be done here, so I am closing the bug.
  04/16/1999 13:26 - stanton -


tkt_uuid: 1994880fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Duplicate
title: tk_getOpenFile can't handle multiple files
comment:
  Using tk_getOpenFile with -multiple 1:

  I get an error popup saying 'File "/dir/file1 file2" 
  does not exist' when I try to open two files (file1 and file1) from the same directory (dir).

  Clearly the many elements in the multiple selection are not correctly handled but interpreted as a single file name.

  The problem seems to be that, after selecting multiple files in the icon list, clicking the OK button (Open) immediately **clears** the Icon selection. Because the multiple file counting relies on the selected icons, the program doesn't notice a multiple selection but considers that all the concatenated names is a single file name string...

  This didn't happen in 8.4. Do this test: select multiple files, and click-and-hold the "Open" button (do not release the mouse button). Notice the difference:

  In 8.4, clicking okBtn didn't clear the icon selection.

  In 8.5, clicking okBtn triggers ::tk::IconList_FocusOut too early. That clears the icon selection!


tkt_uuid: 220734ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: Tcl/Tk 8.3 documentation errors
comment:
  OriginalBugID: 5396 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: '2000-05-22'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  FixedDate: '2000-05-22'
  FixedInVersion: 8.4a1


  Name:
  Colin McDonald

  Comments:
  Although mostof these points are minor, the quality of the Tcl
      documentation has been one of its major strengths, and I would not like
      to see that diminished.  It is extremely important as regards the
      impression given to new users. In particular I found the updated photo
      command documentation confusing at first.

  ReproducibleScript:
  I have found the following documentation errors introduced in Tcl/Tk 8.3

  scan
  ====

  The scan synopsis should be:

  scan string format ?varName varName ...? 

  in order to indicate that no variable names are specified for inline mode.

  array unset
  ===========

  This command always returns an empty string, which is not the impression given by the documentation.  Could be reworded as follows:

  Unsets all of the elements in the array that match pattern (using the matching rules of string match).  If arrayName isn't the name of an array variable or there are no matching elements in the array, then the command completes without erroring.  If pattern is omitted and arrayName is an array variable, then the command unsets the entire array. The command result returns an empty string.

  listbox
  =======

  The new option name is -listvariable, not -listvar.

  Canvas DASH PATTERNS
  ====================

  "position" not "posibion"

  Last paragraph should be:

  On systems which support only a limited set of dash patterns, the dash pattern will be displayed as the closest dash pattern that is available. For example, on Windows only the first 4 of the above examples are available. The last 2 examples will be displayed identically to the first one. 

  Canvas COMMON ITEM OPTIONS
  ==========================

  -disableddash indicates the dash options apply only to arcs.  Should be:

  This option specifies dash patterns for an item's outine in its normal, active and disabled states.

  How is -dashoffset specified - Pixels? Index into the dash list?  And how does it affect the resulting dash pattern?

  -offset - "instead" not "in stead".

  -disabledwidth description contains "For arcs, wide outlines will be drawn centered on the edges of the arc's region".  What about the other item types?  I think that there used to be information about wide outline handling included in the individual item descriptions, which has now been lost.  Generally wide outlines are centered on the requested coordinates.

  Bind MODIFIERS
  ==============

  Support for <Quadruple> clicks has been added, but not documented in the bind modifier list.

  photo
  =====

  The data sub-command -format and -from options mention writing the image to a file - all references for this sub-command should be to returning the image data in a string.

  The put sub-command description and options repeatedly describe reading image data from a file, whereas this sub-command actually obtains the data from a string argument.

  Entry VALIDATION
  ================

  "possible" not "posible"

  label
  =====

  The -disabledforeground and -state options have been added to the label widget in Tk 8.3.1, but the manual page has not been updated.

  The "last change" version number has not been updated for some man pages.



  Docs updated for 8.4a1. 
  -- 05/22/2000 hobbs


tkt_uuid: 1423459fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Win msgbox and listbox binding problem?
comment:
  The reaction of the following script seems to be
  incorrect, at least under Win XP Pro | SP2 and
  ActiveTcl 8.4.11.

  It creates a listbox containing multiple entries and
  allows for "extended" selections, so that multiple
  records can be selected at once.  As soon as multiple
  records are selected, a tk_messageBox is opened.

  Shouldn't the opening of the messagebox block any
  further action in the listbox?  If the action that
  triggered the messagebox was a "drag" operation in the
  listbox, (to select multiple records) the drag
  operation is allowed to continue, and in fact, opens a
  new messagebox for each additional record that's added
  to the selection list.

  Though I'm unable to test it, I'm told the script
  reacts differently (and, more correctly) under both
  Linux and MacOS X.  That is, once the msgbox is opened,
  the drag operation is blocked until the dialog is
  responded to.

  Jeff

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

  proc count {} {
      if {[llength [.l1 curselection]] > 1} {
          tk_messageBox -title "Warning" -message
  "Multiple records" -type ok
      }
  }

  console show
  listbox .l1 -width 20 -height 15 -selectmode extended
  .l1 insert end a b c d e f g h i
  bind .l1 <<ListboxSelect>> count

  pack .l1


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

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

  thx


tkt_uuid: 1913251fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 7 High
foundin: None
resolution: Works For Me
title: default menu keyboard binding Aqua inconsistencies
comment:
  The default bindings for Tk menus include the use of arrow keys to navigate menus and return or the space bar to invoke the selected item 9http://www.tcl.tk/man/tcl8.5/TkCmd/menu.htm#M77). These bindings do not seem to work with Tk Aqua on Mac OS X 10.5 (I cannot confirm whether this applies to Mac OS X 10.4 as well).

  Attached is a simple script which creates a pair of menus containing dummy items and a submenu. In X11 and Windows, I can change the selected menu item with the up and down arrows and change menus with the left and right arrows. (If the submenu item is selected, the right arrow shows the cascade menu.) Pressing the space bar or return selects the items and unposts the menu.

  These commands do not seem to do anything with Tk Aqua. This is noticeable because most Mac OS X applications do permit keyboard navigation with the arrows.

  The specific versions I've tested are listed here. Keyboard navigation does not work as expected in the Aqua combinations but does in the other two.

  8.5.0  Aqua Mac OS X 10.5.2
  8.4.17 Aqua Mac OS X 10.5.2
  8.5.1  X11 Mac OS X 10.5.2
  8.5.1  Windows Server 2003


tkt_uuid: 219982ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Duplicate
title: tcl_trace* variables don't work
comment:
  OriginalBugID: 2045 Bug
  Version: 8.1
  SubmitDate: '1999-05-10'
  LastModified: '1999-08-24'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2597
  OS: All Windows
  Machine: X86
  ClosedDate: '1999-08-24'


  Name:
  Christopher Nelson

  ReproducibleScript:
  # In wish on W98
      set tcl_traceCompile 1
      set tcl_traceExec 1
      proc foo { s } {
          puts $s
      }
      foo asdf

  ObservedBehavior:
  No compile or exec trace shown

  DesiredBehavior:
  Compile and exec traces



  The problem is that the tcl_trace* output goes to 'stdout', which
  doesn't really exist in the wish console.  Dupping this to 2597
  as that points the problem out better. 
  -- 08/24/1999 hobbs


tkt_uuid: 852269ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Grow box drawn even for non-resizable windows
comment:
  Set a window to be non-resizable:

  wm resizable .foo 0 0

  On Mac OS X (and perhaps other environments), the grow 
  box is nonetheless drawn onthe window.

  Tim Monroe
  monroe@apple.com


tkt_uuid: 220118ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Grid "-sticky" option seems to misbehave
comment:
  OriginalBugID: 946 Bug
  Version: 8.0p2
  SubmitDate: '1998-12-14'
  LastModified: '2000-01-18'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: ericm
  OS: Linux
  Machine: Other
  ClosedDate: '2000-01-18'


  Name:
  David Skoll

  Extensions:
  Linux daw1 2.0.36 #1 Fri Nov 20 13:25:52 EST 1998 i586

  CustomShell:
  Stock Tcl/Tk -- no patches.

  ReproducibleScript:
  set n 0

  proc packit { how } {
      global n
      incr n
      set w .test$n
      toplevel $w
      wm title $w "Test: $how"

      frame $w.short -relief sunken -border 2
      frame $w.long -relief sunken -border 2
      grid $w.short -sticky ew
      grid $w.long -sticky ew

      label $w.longlab -text "This is a rather long label"
      grid $w.longlab -in $w.long -sticky ew

      label $w.how -text "short"
      if {$how == "grid"} {
  grid $w.how -in $w.short -sticky w
      } else {
  pack $w.how -in $w.short -expand 0 -fill none -anchor w
      }
  }

  wm withdraw .
  packit pack
  packit grid

  ObservedBehavior:
  When I run the script above, I expect the two top-level windows "pack" and "grid" to look identical.  Instead, the "grid" version centers the "short" label rather than left-justifying it.

  DesiredBehavior:
  I expect to see "short" left-justified in both windows.



  This is actually how the grid geometry manager is defined to behave.  The misunderstanding stems from confusing the parent widget with the slave cavity.

  When using grid, a cavity space is set up for each widget.  If no non-zero weights are specified for the columns and rows of the parent widget, the cavity will be "shrink-wrapped" around the slave widget.  The slave widget is actually sticky within its cavity, but because the cavity is exactly big enough to contain the widget, it doesn't look like it.  And the grid manager is defined to center layouts within the parent, if no weights are set.  So the widget appears centered in the parent, but really the cavity is centered, and the widget is sticky.

  If you alter the size of the cavity by setting its column width to a non-zero value (like 1), you will see the widget move to the spot you originally expected.

  - eric

  -- 01/18/2000 ericm


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: 1209431fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 12. Unix Menus
priority: 7 High
foundin: None
resolution: Fixed
title: Change sticky behavior of tk_popup
comment:
  As discussed in c.l.t, this patch changes (fixes) the
  behavior of menus posted by tk_popup so that they
  "stick" after the initial <ButtonRelease> following the
  post, that is not over an active menu entry.

  The supplied patch is against core-8-4-9, but this area
  of the code is no different on the trunk, so the patch
  should apply there without problem.

  -Brian


tkt_uuid: 578165ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Fixed
title: testthread used.
comment:
  Note that the testthread command shows up
  a few places in the Tk test suite.  These
  should migrate to use the Thread extensions.


tkt_uuid: 971724ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Make disabled buttons look "more natively" on MS Windows
comment:
  This patch makes disabled *buttons and labels look like
  the "native" ones: with the "white shadow" below the
  text, exactly as it's now done for disabled menu
  entries (code is almost the same, too).


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


tkt_uuid: 458162ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: request for additional versions
comment:
  tk_chooseColor on non window systems is aesthetically
  "alright," but I would love to see additional versions
  (improvements) such as the different pickers available
  under the gimp (gyroscopic wheel, triangle, etc.) 


tkt_uuid: 444458ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: Can't build Tk 8.4a3 (from 2001-07-23)
comment:
  Two Tk modules define static routines that conflict with 'Windows API routines:

  generic/tkCanvBmap.c

      --  static routine CreateBitmap()

  generic/tkCursor.c

      --  static routine GetCursor()

  In each case, I stuck an X in front of the name to get past the problem for now but there's 
  something wrong here.


tkt_uuid: 220580ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: None
resolution: Fixed
title: Support line styles in Windows X emulation layer
comment:
  OriginalBugID: 2578 RFE
  Version: 8.0.4
  SubmitDate: '1999-08-18'
  LastModified: '1999-12-13'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-12-13'
  FixedInVersion: 8.3b1


  Name:

  Brian Griffin


  CVS:

  tkWinDraw.c 1998/09/14 18:24:00     1.2


  CustomShell:

  I have several patches; don't recall them all.  Some are my own which I've submitted previously.


  Comments:

  I have only tested LineOnOffDash of signle pixel wide lines.  Lines

      wider than 1 pixel uses different code.


  ReproducibleScript:

  Using these emulated X calls on Windows:

      XSetLineAttributes( display, gc, line_width, line_style, cap_style,

      join_style);

      XDrawLine( display, d, gc, x1, y1 , x2, y2 );


      You'll find that the line_style argument is ignored.  All lines are draw

      as LineSolid (a.k.a. PS_SOLID).


  DesiredBehavior:

  LineOnOffDash and LineDoubleDash should also be supported.


  Patch:

  cvs diff -c tkWinDraw.c

  Index: tkWinDraw.c

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

  RCS file: /cvsroot/tk/win/tkWinDraw.c,v

  retrieving revision 1.2

  diff -c -r1.2 tkWinDraw.c

  *** tkWinDraw.c 1998/09/14 18:24:00     1.2

  --- tkWinDraw.c 1999/08/12 19:21:21

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

  *** 743,748 ****

  --- 743,750 ----

        RECT rect;

        HPEN oldPen;

        HBRUSH oldBrush;

  +     int oldBkMode;

  +     COLORREF oldBkColor;

        POINT *winPoints = ConvertPoints(points, npoints, mode, &rect);


        if ((gc->fill_style == FillStippled

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

  *** 838,843 ****

  --- 840,847 ----


          SetPolyFillMode(dc, (gc->fill_rule == EvenOddRule) ? ALTERNATE

                  : WINDING);

  +       oldBkMode = SetBkMode(dc, TRANSPARENT);

  +       oldBkColor = SetBkColor(dc, gc->background);


          (*func)(dc, winPoints, npoints);


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

  *** 913,921 ****

                  style |= PS_JOIN_BEVEL;

                  break;

          }

          pen = ExtCreatePen(style, gc->line_width, &lb, 0, NULL);

        } else {

  !       pen = CreatePen(PS_SOLID, gc->line_width, gc->foreground);

        }

        RenderObject(dc, gc, points, npoints, mode, pen, Polyline);

        DeleteObject(pen);

  --- 917,939 ----

                  style |= PS_JOIN_BEVEL;

                  break;

          }

  +       switch (gc->line_style) {

  +       case LineSolid:      style |= PS_SOLID; break;

  +       case LineOnOffDash:  style |= PS_DOT; break;

  +       case LineDoubleDash: style |= PS_DASH; break;

  +       default:             style |= PS_SOLID; break;

  +       }

          pen = ExtCreatePen(style, gc->line_width, &lb, 0, NULL);

        } else {

  !       int style;

  !       switch (gc->line_style) {

  !       case LineSolid:      style = PS_SOLID; break;

  !       case LineOnOffDash:  style = PS_DOT; break;

  !       case LineDoubleDash: style = PS_DASH; break;

  !       default:             style = PS_SOLID; break;

  !       }

  !

  !       pen = CreatePen(style, gc->line_width, gc->foreground);

        }

        RenderObject(dc, gc, points, npoints, mode, pen, Polyline);

        DeleteObject(pen);


  PatchFiles:

  tkWinDraw.c




  Changed to RFE, because at the moment we don't require this in Tk
  (which doesn't mean we won't include it after further analysis). 
  -- 08/20/1999 hobbs
  8.3b1 has the dash part of the dash patch. 
  -- 12/13/1999 hobbs


tkt_uuid: 546586ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Widgets
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: labelframe label options
comment:
  I would like to see the new labelframe widget take more
  of the label options. For instance:

  -textvariable
  -state
  -activebackground
  -activeforeground
  -disabledforeground
  -wraplength
  -anchor
  -image
  -compound

  If indeed the labelframe is a combination of the label
  and frame widgets, this would make sense to me.

  Of course, you can work around this, by creating a
  second label widget and using the -labelwidget option,
  but this seems clunky.


tkt_uuid: 220411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: add the itemconfigure command to listboxes
comment:
  OriginalBugID: 936 RFE
  Version: 8.1a2
  SubmitDate: '1998-12-04'
  LastModified: '1999-11-19'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: ericm
  OS: All
  Machine: Other
  FixedDate: '1999-11-19'
  FixedInVersion: 8.3b1


  Name:

  Wayne Christopher


  CVS:

  1.1.4.2 /cvsroot/tk/generic/tkListbox.c,v


  DesiredBehavior:

  I added a itemconfigure command that allows individual entries of listboxes to

  have their own foreground and background colors.


  Patch:

  *** tkListbox.c.orig    Fri Dec  4 18:07:33 1998

  --- tkListbox.c Fri Dec  4 18:18:40 1998

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

  *** 18,23 ****

  --- 18,25 ----

    #include "default.h"

    #include "tkInt.h"


  + #define ITEMCONFIGURE

  + 

    /*

     * One record of the following type is kept for each element

     * associated with a listbox widget:

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

  *** 33,38 ****

  --- 35,44 ----

                                   * it isn't. */

        struct Element *nextPtr;  /* Next in list of all elements of this

                                   * listbox, or NULL for last element. */

  + #ifdef ITEMCONFIGURE

  +     Tk_3DBorder selBorder;    /* Background color for selected element. */

  +     Tk_3DBorder normalBorder; /* Background color for normal element. */

  + #endif

        char text[4];             /* Characters of this element, NULL-

                                   * terminated.  The actual space allocated

                                   * here will be as large as needed (> 4,

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

  *** 263,268 ****

  --- 269,285 ----

          (char *) NULL, 0, 0}

    };


  + #ifdef ITEMCONFIGURE

  + static Tk_ConfigSpec itemConfigSpecs[] = {

  +     {TK_CONFIG_BORDER, "-background", "background", "Background",

  +       NULL, Tk_Offset(Element, normalBorder), TK_CONFIG_COLOR_ONLY},

  +     {TK_CONFIG_BORDER, "-selectbackground", "selectBackground", "Foreground",

  +       NULL, Tk_Offset(Element, selBorder), TK_CONFIG_COLOR_ONLY},

  +     {TK_CONFIG_END, (char *) NULL, (char *) NULL, (char *) NULL,

  +       (char *) NULL, 0, 0}

  + };

  + #endif

  + 

    /*

     * Forward declarations for procedures defined later in this file:

     */

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

  *** 274,279 ****

  --- 291,301 ----

    static int            ConfigureListbox _ANSI_ARGS_((Tcl_Interp *interp,

                              Listbox *listPtr, int argc, char **argv,

                              int flags));

  + #ifdef ITEMCONFIGURE

  + static int            ConfigureListboxItem _ANSI_ARGS_((Tcl_Interp *interp,

  +                           Listbox *listPtr, Element *elPtr, int argc,

  +                           char **argv, int flags));

  + #endif

    static void           DeleteEls _ANSI_ARGS_((Listbox *listPtr, int first,

                              int last));

    static void           DestroyListbox _ANSI_ARGS_((char *memPtr));

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

  *** 281,288 ****

  --- 303,316 ----

    static int            GetListboxIndex _ANSI_ARGS_((Tcl_Interp *interp,

                              Listbox *listPtr, char *string, int endIsSize,

                              int *indexPtr));

  + #ifdef ITEMCONFIGURE

  + static void           InsertEls _ANSI_ARGS_((Tcl_Interp *interp,

  +                           Listbox *listPtr, int index,

  +                           int argc, char **argv));

  + #else

    static void           InsertEls _ANSI_ARGS_((Listbox *listPtr, int index,

                              int argc, char **argv));

  + #endif

    static void           ListboxCmdDeletedProc _ANSI_ARGS_((

                              ClientData clientData));

    static void           ListboxComputeGeometry _ANSI_ARGS_((Listbox *listPtr,

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

  *** 671,677 ****

  --- 699,744 ----

                  != TCL_OK) {

              goto error;

          }

  + #ifdef ITEMCONFIGURE

  +       InsertEls(interp, listPtr, index, argc-3, argv+3);

  + #else

          InsertEls(listPtr, index, argc-3, argv+3);

  + #endif

  + #ifdef ITEMCONFIGURE

  +     } else if ((c == 'i') && (strncmp(argv[1], "itemconfigure", length) == 0)

  +           && (length >= 2)) {

  +         int itemnum, i;

  +       Element *elPtr;

  +         if (argc < 3) {

  +           Tcl_AppendResult(interp, "wrong # args: should be \"",

  +                   argv[0], " itemconfigure item [ name value ... ]\"",

  +                   (char *) NULL);

  +           goto error;

  +       }

  +       if (Tcl_GetInt(interp, argv[2], &itemnum) != TCL_OK) {

  +           goto error;

  +       }

  +       for (elPtr = listPtr->firstPtr, i = 0; i < itemnum;

  +               i++, elPtr = elPtr->nextPtr) {

  +           /* Empty loop body. */

  +       }

  +       if (!elPtr) {

  +           Tcl_AppendResult(interp, "item number \"",

  +                   argv[1], " out of range",

  +                   (char *) NULL);

  +           goto error;

  +       }

  +       if (argc == 3) {

  +           result = Tk_ConfigureInfo(interp, listPtr->tkwin, itemConfigSpecs,

  +                   (char *) elPtr, (char *) NULL, 0);

  +       } else if (argc == 4) {

  +           result = Tk_ConfigureInfo(interp, listPtr->tkwin, itemConfigSpecs,

  +                   (char *) elPtr, argv[3], 0);

  +       } else {

  +           result = ConfigureListboxItem(interp, listPtr, elPtr,

  +                                         argc-3, argv+3, TK_CONFIG_ARGV_ONLY);

  +       }

  + #endif

        } else if ((c == 'n') && (strncmp(argv[1], "nearest", length) == 0)) {

          int index, y;

          char buf[TCL_INTEGER_SPACE];

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

  *** 930,935 ****

  --- 997,1005 ----

                  "\": must be activate, bbox, cget, configure, ",

                  "curselection, delete, get, index, insert, nearest, ",

                  "scan, see, selection, size, ",

  + #ifdef ITEMCONFIGURE

  +               "itemconfigure, ",

  + #endif

                  "xview, or yview", (char *) NULL);

          goto error;

        }

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

  *** 1058,1063 ****

  --- 1128,1176 ----

        return TCL_OK;

    }


  + #ifdef ITEMCONFIGURE

  + /*

  +  *----------------------------------------------------------------------

  +  *

  +  * ConfigureListboxItem --

  +  *

  +  *    This procedure is called to process an argv/argc list, plus

  +  *    the Tk option database, in order to configure (or reconfigure)

  +  *    a listbox item.

  +  *

  +  * Results:

  +  *    The return value is a standard Tcl result.  If TCL_ERROR is

  +  *    returned, then interp->result contains an error message.

  +  *

  +  * Side effects:

  +  *    Configuration information, such as colors, border width,

  +  *    etc. get set for elPtr;  old resources get freed,

  +  *    if there were any.

  +  *

  +  *----------------------------------------------------------------------

  +  */

  + 

  + static int

  + ConfigureListboxItem(interp, listPtr, elPtr, argc, argv, flags)

  +     Tcl_Interp *interp;               /* Used for error reporting. */

  +     Listbox *listPtr;         /* Information about widget;  may or may

  +                                * not already have values for some fields. */

  +     Element *elPtr;           /* Information about item;  may or may

  +                                * not already have values for some fields. */

  +     int argc;                 /* Number of valid entries in argv. */

  +     char **argv;              /* Arguments. */

  +     int flags;                        /* Flags to pass to Tk_ConfigureWidget. */

  + {

  +     if (Tk_ConfigureWidget(interp, listPtr->tkwin, itemConfigSpecs,

  +           argc, argv, (char *) elPtr, flags) != TCL_OK) {

  +       return TCL_ERROR;

  +     }

  + 

  +     ListboxWorldChanged((ClientData) listPtr);

  +     return TCL_OK;

  + }

  + #endif

  + 


    /*

     *---------------------------------------------------------------------------

     *

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

  *** 1201,1211 ****

                  + listPtr->inset;

          gc = listPtr->textGC;

          if (elPtr->selected) {

              gc = listPtr->selTextGC;

              width = Tk_Width(tkwin) - 2*listPtr->inset;

              Tk_Fill3DRectangle(tkwin, pixmap, listPtr->selBorder, x, y,

                      width, listPtr->lineHeight, 0, TK_RELIEF_FLAT);

  ! 

              /*

               * Draw beveled edges around the selection, if there are visible

               * edges next to this element.  Special considerations:

  --- 1314,1332 ----

                  + listPtr->inset;

          gc = listPtr->textGC;

          if (elPtr->selected) {

  + #ifdef ITEMCONFIGURE

  +           Tk_3DBorder col = listPtr->selBorder;

  +           if (elPtr->selBorder) col = elPtr->selBorder;

  + #endif

              gc = listPtr->selTextGC;

              width = Tk_Width(tkwin) - 2*listPtr->inset;

  + #ifdef ITEMCONFIGURE

  +           Tk_Fill3DRectangle(tkwin, pixmap, col, x, y,

  +                   width, listPtr->lineHeight, 0, TK_RELIEF_FLAT);

  + #else

              Tk_Fill3DRectangle(tkwin, pixmap, listPtr->selBorder, x, y,

                      width, listPtr->lineHeight, 0, TK_RELIEF_FLAT);

  ! #endif

              /*

               * Draw beveled edges around the selection, if there are visible

               * edges next to this element.  Special considerations:

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

  *** 1244,1249 ****

  --- 1365,1382 ----

                          TK_RELIEF_RAISED);

              }

          }

  + #ifdef ITEMCONFIGURE

  +       else {

  +           if (elPtr->normalBorder) {

  +               gc = listPtr->selTextGC;

  +               width = Tk_Width(tkwin) - 2*listPtr->inset;

  +               Tk_Fill3DRectangle(tkwin, pixmap, elPtr->normalBorder, x, y,

  +                                  width, listPtr->lineHeight, 0,

  +                                  TK_RELIEF_FLAT);

  +           }

  +       }

  +       gc = listPtr->textGC;

  + #endif

          Tk_GetFontMetrics(listPtr->tkfont, &fm);

          y += fm.ascent + listPtr->selBorderWidth;

          x = listPtr->inset + listPtr->selBorderWidth - elPtr->lBearing

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

  *** 1394,1400 ****

  --- 1527,1538 ----

     */


    static void

  + #ifdef ITEMCONFIGURE

  + InsertEls(interp, listPtr, index, argc, argv)

  +     Tcl_Interp *interp;               /* Used for error reporting. */  

  + #else

    InsertEls(listPtr, index, argc, argv)

  + #endif

        register Listbox *listPtr;        /* Listbox that is to get the new

                                   * elements. */

        int index;                        /* Add the new elements before this


  PatchFiles:

  tkListbox.c




  I added itemconfigure and itemcget commands to the listbox.  These allow you to change, for each item in the listbox, the foreground, background, selectforeground and selectbackground.

  - eric

  -- 11/19/1999 ericm


tkt_uuid: 1942785fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: -default active on Aqua fails
comment:
  When I specifiy -default active for a button I expect it to be blue but it isn't. Moreover, the focus ring is not drawn either, see script:

  toplevel .t
  wm title .t "Press Tab"
  pack [ttk::frame .t.f -padding 40]
  set w .t.f
  ttk::button $w.b1 -text "Plain"
  ttk::button $w.b2 -text "-default normal" -default normal
  ttk::button $w.b3 -text "-default active" -default active
  ttk::button $w.b4 -text "-default disabled" -default disabled

  grid $w.b1 $w.b2 $w.b3 $w.b4 -padx 10


